すべてのプロダクト
Search
ドキュメントセンター

Edge Security Acceleration:キャッシュ有効期限の設定

最終更新日:Nov 19, 2025

キャッシュの生存時間 (TTL) は、オリジンサーバーからのリソースが DCDN ノードにキャッシュされる期間を指定します。TTL の有効期限が切れると、DCDN ノードはこれらのリソースを期限切れとしてマークします。クライアントが DCDN ノードから期限切れのリソースをリクエストすると、DCDN はオリジンフェッチを実行してリソースの最新バージョンを取得し、それを DCDN ノードにキャッシュします。ビジネス要件に合わせて、ファイルディレクトリまたはファイル名拡張子に基づいて静的リソースのキャッシュ TTL を設定できます。

注意事項

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

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

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

  • DCDN の POP (point of presence) がオリジンサーバーからのレスポンスで静的ファイルリソースを受信すると、「Alibaba Cloud DCDN のデフォルトキャッシュルールと優先度」に従ってリソースをキャッシュします。動的ファイルリソースのキャッシュルールの詳細については、「動的および静的コンテンツの高速化ルールの概要」をご参照ください。

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

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

手順

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

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

  3. ドメイン名 ページで、管理するドメイン名を見つけて 設定 をクリックします。

  4. ドメイン名の左側のナビゲーションツリーで、キャッシング をクリックします。

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

  6. キャッシュ期間 ダイアログボックスでキャッシュルールを設定できます。

    image

    パラメーター

    説明

    タイプ

    リソースの範囲を指定するために ディレクトリ または ファイル名拡張子 をサポートします

    • ディレクトリ: 特定のパス内のすべてのリソースに同じキャッシュルールを設定します。

    • ファイル名拡張子: 特定のファイルタイプのリソースに同じキャッシュルールを設定します。

    コンテンツ

    リソースのディレクトリまたはファイル拡張子。

    • タイプを ディレクトリ に設定した場合は、次の点に注意してください:

      • 一度に 1 つのディレクトリのみを追加します。スラッシュ (/) を使用してすべてのディレクトリを照合します。

      • ディレクトリの完全なパスを入力します。パスはスラッシュ (/) で始まる必要があります。例: /directory/aaa

    • ファイル名拡張子 をタイプとして選択した場合は、次の点に注意してください:

      • 1 つ以上のファイル名拡張子を入力します。複数の拡張子はコンマ (,) で区切ります。例: jpg,txt。拡張子では大文字と小文字が区別されます。

        サポートされている静的ファイルタイプは次のとおりです:

        • イメージ: GIF、PNG、BMP、JPEG、および JPG。

        • Web ページ: HTML、HTM、および SHTML。

        • オーディオおよびビデオファイル: MP3、WMA、FLV、MP4、WMV、OGG、および AVI。

        • ドキュメント: DOC、DOCX、XLS、XLSX、PPT、PPTX、TXT、および PDF。

        • その他: ZIP、EXE、TAT、ICO、CSS、JS、SWF、APK、M3U8、TS、EJS、SVG、WOFF、および OTF。

      • アスタリスク (*) を使用してすべてのファイルタイプを照合することはできません。

    有効期限

    キャッシュされたリソースの生存時間 (TTL)。TTL は最大 3 年まで設定できます。次のルールに従ってください:

    • イメージやアプリケーションパッケージなど、頻繁に更新されない静的ファイルの場合は、TTL を 1 か月以上に設定します。

    • JS ファイルや CSS ファイルなど、頻繁に更新される静的ファイルの場合は、必要に応じて TTL を設定します。

    • PHP、JSP、ASP ファイルなどの動的ファイルの場合は、TTL を 0s に設定します。これにより、ファイルがキャッシュされるのを防ぎます。

    オリジン TTL に従う

    この機能が有効で、オリジンサーバーが Cache-Control や Pragma などのキャッシュポリシーヘッダーを返す場合、オリジンサーバーのキャッシュポリシーが優先されます。

    オリジンの No-Cache ヘッダーを無視

    有効にすると、DCDN ノードは、オリジンサーバーのレスポンスからの次のキャッシュポリシーヘッダー (これらのヘッダーはキャッシュを防ぐために使用されます) を無視します。

    • Cache-Control: no-store

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

    • Pragma: no-cache

    POP TTL に従う

    この機能を有効にすると、DCDN ノードは最終的に有効なキャッシュポリシーでクライアントに応答します。

    強制的な再検証

    このパラメーターは、キャッシュの有効期限が 0 の場合にのみ有効になります。効果は次のとおりです:

    • オフ (デフォルト): DCDN の生存時間 (TTL) が 0 に設定されている場合、ファイルは DCDN ノードにキャッシュされず、各リクエストはオリジンサーバーからコンテンツを取得する必要があります。

    • 有効: DCDN の生存時間 (TTL) が 0 に設定されている場合、ファイルは DCDN ノードにキャッシュされ、キャッシュされたコンテンツを検証するために各リクエストでオリジンフェッチが必要になります。

    重み

    キャッシュルールの優先度。有効な値: 1~99。値が大きいほど優先度が高くなります。優先度が最も高いルールが優先されます。

    説明
    • 複数のキャッシュルールが設定されている場合は、各ルールに異なる重みを設定して、実行の優先度を制御します。

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

    • 複数のキャッシュポリシーが設定されている場合、DCDN は 1 つのポリシーが有効になった後、他のポリシーの照合を停止します。

    ルール条件

    ルール条件は、リクエスト内のパラメーターを識別して、設定がリクエストに適用されるかどうかを判断できます。

    • 条件を使用しない

    • ルール条件を追加または編集する場合は、「ルールエンジン」をご参照ください。

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

    キャッシュルールを作成した後、キャッシュ期間 リストで 変更 または 削除 できます。

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

HTTP ステータスコードが 200、203、206、300、301、308、または 410 のオリジンレスポンスの場合、キャッシュの有効期限は次のルールによって決定されます。

DCDN POP がオリジンサーバーからファイルリソースを受信すると、次の優先順位でキャッシュルールを適用します。数値が小さいほど、優先度が高くなります。缓存优先级

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

  2. DCDN コンソールで設定されたキャッシュ有効期限またはステータスコード有効期限。

    説明

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

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

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

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

    1. オリジンサーバーからのレスポンスの cache-control ヘッダーが 0 より大きい max-age または s-maxage 値を指定している場合、cache-control ヘッダーは生存時間を設定するために使用されます。例: cache-control:max-age=3600。max-ages-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-controlExpires、または last-modified が含まれておらず、ETag が含まれている場合、リソースは 10 秒間キャッシュされます。

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

キャッシュレスポンス情報の説明

  • Date:

    • オリジンサーバーが DCDN POP にレスポンスでリソースを送信した時刻を示します。

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

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

  • X-Cache:

    リクエストされたリソースが DCDN POP のキャッシュにヒットしたかどうかを示します。次の表に、指定できる値を示します。

    ステータス

    説明

    HIT

    リクエストされたリソースが DCDN POP のキャッシュにヒットしました。

    MISS

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

  • X-Swift-Cachetime:

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

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

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

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

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

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

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

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

  • X-Swift-SaveTime:

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

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

  • Ali-Swift-Global-Savetime:

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

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

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

HTTP プロトコルは、3 種類のキャッシュ制御メカニズムを定義しています:

  1. 有効期限検証メカニズム

    クライアントがサーバーにリソースをリクエストすると、そのリソースの有効期限が設定されます。この時刻より前は、リソースのキャッシュコピーは有効と見なされます。この時刻を過ぎると、キャッシュコピーは無効と見なされます。

    キャッシュの有効期限を制御する一般的な HTTP ヘッダーは次のとおりです:

    ヘッダー名

    プロトコルバージョン

    機能

    値の例

    タイプ

    Pragma

    HTTP/1.0

    Pragma は、コンテンツをキャッシュすべきでないかどうかを示します。一般的な値は no-cache で、これはファイルがキャッシュされないことを意味します。HTTP/1.0 のみをサポートするサーバーとの互換性のためにしばしば使用されます。

    Pragma:no-cache

    リクエスト/レスポンス

    Expires

    HTTP/1.0

    Expires レスポンスヘッダーには、キャッシュされたコンテンツの有効期限が切れる日時が含まれます。

    0 などの無効な日付が使用された場合、リソースはすでに期限切れであることを意味します。

    Expires: Wed, 21 Oct 2022 07:28:00 GMT

    応答

    Cache-Control

    HTTP/1.1

    Cache-Control レスポンスヘッダーは、柔軟なキャッシュ制御を実現するためにさまざまな命令で設定できます。これは、ブラウザなどの最新のクライアントがキャッシュを制御するために使用する主要なヘッダーです。

    次の 3 つの例は、ファイルをキャッシュすべきでないことを示しています:

    • Cache-Control:no-cache

    • Cache-Control:no-store

    • Cache-Control:max-age=0

    キャッシュの有効期間が 1 時間であることを示す例: Cache-Control:max-age=3600

    リクエスト/レスポンス

  2. リソースタグ検証メカニズム

    クライアントがサーバーに初めてリソースをリクエストすると、サーバーはレスポンスヘッダーにリソースタグを含めます。このタグは、同じリソースに対する後続のリクエストの検証識別子として機能します。クライアントがリソースを再度リクエストすると、リクエストヘッダーにタグが含まれます。サーバーがタグを検証し、リソースが更新されていないと判断した場合、HTTP 304 ステータスコードで応答します。これは、クライアントがローカルのキャッシュコピーを引き続き使用できることを示します。サーバーが不一致を検出した場合、リソースが変更されたことを示し、クライアントはリソースコンテンツを再度取得する必要があります。

    キャッシュバージョンを制御する一般的な HTTP ヘッダーは次のとおりです:

    ヘッダー名

    プロトコルバージョン

    機能

    値の例

    タイプ

    Last-Modified

    HTTP/1.0

    Last-Modified は、リソースの最終変更時刻を示します。

    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

    応答

    ETag

    HTTP/1.1

    ETag は、リソースの特定のバージョンの一意の識別子を提供します。

    ETag を比較することで、リソースが変更されたかどうかを判断できます。変更されていない場合、オリジンサーバーは完全なレスポンスを送信する必要はありません。

    ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

    応答

  3. 複数コピーネゴシエーションメカニズム

    キャッシュソフトウェアは、キーワードを使用してディスクにキャッシュされたオブジェクトにインデックスを付けます。HTTP/1.0 では、リソース URL がキーワードとして使用されます。ただし、異なるリソースが同じ URL を共有する場合があります。それらを区別するには、クライアントは Accept-Language や Accept-Charset ヘッダーなどの詳細情報を提供する必要があります。このコンテンツネゴシエーションメカニズムをサポートするために、HTTP/1.1 ではレスポンスメッセージに Vary ヘッダーが導入されました。このヘッダーは、リクエストメッセージのどのヘッダーがコンテンツネゴシエーションに使用されるかを指定します。

    複数コピーネゴシエーションメカニズムは、通常、HTTP Vary ヘッダーを使用して、異なるキャッシュコピーを区別します。これにより、同じリソースをリクエストする異なるクライアントが、そのリソースの異なるバージョンを受信できるようになります:

    ヘッダー名

    プロトコルバージョン

    説明

    値の例

    タイプ

    Vary

    HTTP/1.1

    一般的な例:

    • サーバーは Vary: Accept-Encoding を指定して、受信側 (DCDN POP など) に、このリソースに対して 2 つのバージョンのリソース (圧縮版と非圧縮版) をキャッシュする必要があることを通知します。クライアントが DCDN から同じリソースをリクエストすると、古いブラウザは (互換性の問題を避けるために) 非圧縮リソースを取得し、新しいブラウザは (データ転送トラフィックを削減するために) 圧縮リソースを取得します。

    • サーバーは Vary: User-Agent を指定して、リクエストを送信しているブラウザのタイプを識別し、受信側 (DCDN POP など) にブラウザのタイプに基づいて対応するバージョンのリソースをキャッシュするように通知します。

    Vary: Accept-Encoding

    Vary: Accept-Encoding,User-Agent

    応答

設定例

例 1: .txt ファイルを 7 日間キャッシュするには、DCDN コンソールで .txt ファイル名拡張子のキャッシュルールを追加し、キャッシュの有効期限を 7 日に設定します。

image.png

例 2: 高速化ドメイン名 demo.aliyun.com に次のキャッシュポリシーが設定されています。DCDN ノードがオリジンサーバーからリソース http://demo.aliyun.com/image/example.png を取得すると、両方のルールが照合されます。2 つのルールの重みが同じであるため、先に作成されたルールがより高い優先度を持ちます。/image ディレクトリのルールが先に作成されたため、有効になります。image.png

関連 API 操作

ドメイン名の一括設定