CDN:キャッシュの有効期限の設定

注意事項

• ドメイン名を追加した後、キャッシュ時間を変更できます。キャッシュ期間は、CDN back-to-origin トラフィックとコストに影響します。キャッシュの有効期限は、オリジンフェッチの頻度に影響します。ビジネスニーズに基づいてリソースのキャッシュ期間を設定してください。

  キャッシュの有効期限が短すぎると、CDN はオリジンから頻繁にデータをフェッチするため、オリジンサーバーのトラフィックが増加します。キャッシュの有効期限が長すぎると、データ更新が遅延します。

• アクセス頻度の低い (つまり、同じ CDN POP 上のリソースがクライアントから頻繁にリクエストされない) CDN POP にキャッシュされたリソースは、キャッシュの有効期限が切れる前に、CDN POP 上の他のより人気のあるリソースによって上書きされる可能性があります。

• デフォルトでは、POP (Point of Presence) がオリジンサーバーからの応答で静的ファイルリソースを受信すると、Alibaba Cloud CDN および DCDN のデフォルトのキャッシュルールと優先度に従ってリソースをキャッシュします。

• オリジンサーバー上のコンテンツを同じファイル名で更新しないでください。代わりに、同期にはバージョン番号を使用してください。

  更新前後のコンテンツを正確に区別するために、バージョン番号を使用してオリジンコンテンツを同期します。これは、コンテンツを更新するときに異なるファイル名を使用することを意味します。たとえば、img-v1.0.jpg や img-v2.1.jpg などの名前を使用できます。

手順

1. CDN コンソールにログインします。

2. 左側のナビゲーションウィンドウで、ドメイン名 をクリックします。

3. ドメイン名 ページで、ターゲットドメイン名を見つけ、操作 列の 管理 をクリックします。

4. ドメインのナビゲーションウィンドウで、キャッシュ設定 をクリックします。

5. キャッシュ有効期限 タブで、追加 をクリックします。

   

   パラメーター	説明
   タイプ	ディレクトリ または ファイル拡張子 によってリソースの範囲を指定します。 ディレクトリ: 特定のパス内のすべてのリソースに同じキャッシュルールを設定します。 ファイル拡張子: 特定の種類のファイルに同じキャッシュルールを設定します。
   アドレス	設定するリソースのフォルダまたはファイル名拡張子を指定します。 [タイプ] を [フォルダ] に設定した場合、次のルールに従います。 一度に追加できるフォルダは 1 つだけです。すべてのフォルダを照合するには、スラッシュ (/) を使用します。 フォルダの完全なパスを入力します。パスはスラッシュ (/) で始まる必要があります (例: /directory/aaa)。 [ファイルサフィックス] をタイプとして選択した場合、次のルールが適用されます。 1 つ以上のファイル名拡張子を入力します。複数の拡張子はコンマ (,) で区切ります (例: jpg,txt)。 入力では大文字と小文字が区別されます。 アスタリスク (*) を使用してすべてのファイルタイプを照合することはできません。
   有効期限	リソースが CDN POP にキャッシュされる時間。最大時間は 3 年です。次のルールに基づいてこのパラメーターを設定します。 イメージやアプリケーションのダウンロードなど、頻繁に更新されない静的ファイルの場合は、有効期限を 1 か月以上に設定します。 JS ファイルや CSS ファイルなど、頻繁に更新される静的ファイルの場合は、必要に応じて有効期限を設定します。 PHP、JSP、ASP ファイルなどの動的ファイルの場合は、有効期限を 0 秒に設定します。これにより、キャッシュが無効になります。
   オリジンキャッシュポリシーを優先	これが有効で、オリジンサーバーがキャッシュポリシーヘッダー (Cache-Control および Pragma を含む) で応答する場合、オリジンサーバーからのキャッシュポリシーが優先されます。
   オリジンの No-Cache ヘッダーを無視	これが有効な場合、CDN POP はオリジンサーバーの応答からの以下の no-cache ポリシーヘッダーを無視します。 Cache-Control: no-store Cache-Control: no-cache Cache-Control: max-age=0 Pragma: no-cache
   POP キャッシュポリシーに従う	これが有効な場合、CDN POP は最終的に有効なキャッシュポリシーをクライアントへの応答で送信します。
   強制的な再検証	このパラメーターは、キャッシュの有効期限が 0 に設定されている場合にのみ有効になります。効果は次のとおりです。 無効 (デフォルト): CDN のキャッシュ有効期限が 0 に設定されている場合、ファイルは CDN POP にキャッシュされません。各リクエストは、コンテンツをフェッチするためにオリジンサーバーにリダイレクトされる必要があります。 有効: CDN のキャッシュ有効期限が 0 に設定されている場合、ファイルは CDN POP にキャッシュできます。各リクエストは、キャッシュされたコンテンツを検証するためにオリジンサーバーにリダイレクトされる必要があります。
   重み	重みはキャッシュルールの優先度を示します。値は 1 から 99 の範囲で指定できます。値が大きいほど優先度が高くなります。優先度の高いルールが優先されます。 説明 複数のキャッシュルールがある場合は、各ルールに異なる重みを設定して、実行の優先度を制御します。 同じ重みを持つルールの場合、ルールタイプに関係なく、先に作成されたルールの方が優先度が高くなります。 複数のキャッシュポリシーを設定した場合、1 つのポリシーが有効になると、他のポリシーは照合されません。
   ルール条件	ルール条件は、リクエスト内のパラメーターを識別して、設定がリクエストに適用されるかどうかを判断できます。 条件を使用しない ルール条件を追加または編集する場合、詳細については、「ルールエンジン」をご参照ください。

6. OK をクリックして設定を完了します。

Alibaba Cloud CDN のデフォルトのキャッシュルールと優先度

1. オリジンサーバーが pragma:no-cache、cache-control:no-cache (または no-store、または max-age=0) で応答した場合、CDN はリソースをキャッシュしません。

2. CDN コンソールで設定されたキャッシュの有効期限または状態コードの有効期限。

   説明

   CDN リクエストが複数のルールに一致する場合、1 つのルールのみが適用されます。優先度は、まず重み、次に作成時間によって決定されます。

   • 複数のキャッシュルールがある場合は、各ルールに異なる重みを設定して、実行の優先度を制御します。重みが大きいほど優先度が高くなります。

   • 同じ重みを持つルールの場合、ルールタイプに関係なく、先に作成されたルールの方が優先度が高くなります。

3. オリジンサーバーで設定されている他のキャッシュルール。優先度は高いものから順に、cache-control > expires > last-modified > ETag となります。

   1. オリジンサーバーからの応答の cache-control ヘッダーが 0 より大きい max-age または s-maxage 値を指定している場合、cache-control ヘッダーが生存時間の設定に使用されます。例: cache-control:max-age=3600。max-age と s-maxage の両方が存在する場合、s-maxage が優先されます。

   2. オリジンの応答に cache-control ヘッダーは含まれていないが、Expires ヘッダーが含まれている場合、キャッシュの有効期限は Expires ヘッダーによって決定されます。例: expires:Tue, 25 Nov 2031 17:25:43 GMT。

   3. オリジンの応答に cache-control または Expires は含まれていないが、last-modified が含まれている場合、キャッシュ時間は数式 (現在の時刻 - last-modified) × 0.1 を使用して計算されます。結果が 10 秒から 3600 秒の間の場合、その結果が使用されます。結果が 10 秒未満の場合、キャッシュ時間は 10 秒です。結果が 3600 秒より大きい場合、キャッシュ時間は 3600 秒です。

   4. オリジンの応答に cache-control、Expires、または last-modified は含まれていないが、ETag が含まれている場合、リソースは 10 秒間キャッシュされます。

4. オリジンサーバーから返されたデータにキャッシュ関連のレスポンスヘッダー (cache-control、expires、last-modified、または ETag) が含まれていない場合、リソースはデフォルトではキャッシュされません。

キャッシュ応答情報の説明

• Date:

  • オリジンサーバーが CDN POP への応答でリソースを送信した時刻を示します。

  • CDN POP が、オリジンリクエストに If-Modified-Since または If-None-Match ヘッダーを含めることでオリジンサーバーでリソースを再検証する場合、オリジンサーバーが 304 状態コードを返すと Date 情報が更新されます。

  • フォーマットはグリニッジ標準時 (GMT) です。例: Sat, 19 Apr 2025 08:58:31 GMT。

• X-Cache:

  リクエストされたリソースが CDN POP のキャッシュにヒットしたかどうかを示します。次の表に、考えられる値を示します。

  ステータス	説明
  HIT	リクエストされたリソースが CDN POP のキャッシュにヒットしました。
  MISS	リクエストされたリソースが CDN POP のキャッシュにヒットしませんでした。リソースはオリジンサーバーによって提供されました。

• X-Swift-Cachetime:

  • リソースの CDN POP 上での残りのキャッシュ時間 (秒単位) を示します。

  • X-Swift-Cachetime = Ali-Swift-Global-Savetime + CDN に設定されたキャッシュ有効期限 - X-Swift-SaveTime。

  • X-Swift-Cachetime は、CDN に設定されたキャッシュ有効期限と常に等しいとは限りません。次の 3 つの状況が発生する可能性があります。

    • X-Swift-Cachetime = CDN に設定されたキャッシュ有効期限 (例: 3600 秒)。

    • X-Swift-Cachetime が CDN に設定されたキャッシュ有効期限よりわずかに短い。たとえば、CDN のキャッシュ有効期限が 300 秒に設定されているのに、X-Swift-Cachetime が 295 秒である場合。これは、次の理由が考えられます。

      • レイヤー 1 POP がレイヤー 2 POP からデータをフェッチするときに高いレイテンシーが発生する。

      • レイヤー 1 とレイヤー 2 の POP の時計が同期していない。

    • X-Swift-Cachetime の値が負である。これは、CDN のキャッシュ有効期限が変更されたことが原因である可能性があります。クライアントがリクエストを送信すると、レイヤー 1 POP のキャッシュは期限切れになっていますが、レイヤー 2 POP のキャッシュは期限切れになっていません。たとえば、CDN のキャッシュ有効期限がもともと 3600 秒で、後で 300 秒に変更されたとします。クライアントが最初のリクエストから 600 秒後にリクエストを送信した場合、レスポンスヘッダーは X-Swift-Cachetime:-300 となります。この問題を解決するには、キャッシュをリフレッシュします。

• X-Swift-SaveTime:

  • クライアントが直接アクセスした CDN POP にリソースが最初にキャッシュされた時刻を示します。これは通常、レイヤー 1 POP です。

  • フォーマットはグリニッジ標準時 (GMT) です。例: Sat, 19 Apr 2025 08:58:31 GMT。

• Ali-Swift-Global-Savetime:

  • リソースが CDN POP に最初にキャッシュされた時刻を示します。これは、サイトのキャッシュアーキテクチャに応じて、レイヤー 2 POP または別のキャッシュレイヤーの POP である可能性があります。

  • フォーマットは UNIX タイムスタンプです。例: 1745053111 (これは 2025-04-19 16:58:31 を表します)。

HTTP キャッシュ制御メカニズム

設定例

関連 API

BatchSetCdnDomainConfig

よくある質問

• キャッシュ関連の FAQ

• CDN/DCDN キャッシュクリーンアップメカニズムはどのように機能しますか？

• CDN キャッシュヒット率の向上

• キャッシュされずにオリジンサーバーから直接フェッチされるようにファイルを構成するにはどうすればよいですか？