Edge Security Acceleration:デフォルトのキャッシュルール

デフォルトのキャッシュポリシー

キャッシュ構成は、ESA のキャッシュコンポーネントに送信されるクライアントリクエストに対してのみ有効です。クライアントリクエストがキャッシュコンポーネントに送信されるかどうかを判断するために、ESA は次のプロシージャを実行します。

1. リクエストが GET または HEAD タイプであるかを確認します。

2. リクエストがキャッシュルールで指定された条件を満たしているかを確認します。リクエストが条件を満たす場合、グローバルキャッシュ設定ではなく、そのキャッシュルールがリクエストに適用されます。詳細については、「成功応答とリダイレクトのキャッシュルール」をご参照ください。

3. ファイル拡張子が「デフォルトでキャッシュされるファイルの拡張子」にリストされているかを確認します。リストされている場合、グローバルキャッシュ設定がリクエストに適用されます。

成功応答とリダイレクトのキャッシュルール

適用可能なステータスコード：200、203、206、300、301、410。

エッジキャッシュ TTL には 4 つのオプションがあり、それぞれ異なるロジックに基づいて適用されます。

• オリジンサーバーのキャッシュポリシーが存在する場合はそれを優先し、存在しない場合はデフォルトのキャッシュポリシーを使用する：オリジンサーバーから返された応答に、キャッシュポリシーを設定するための Cache-Control、Expires、Last-Modified、ETag ヘッダーが含まれている場合、ESA はオリジンサーバーのキャッシュポリシーを使用します。オリジンサーバーから返された応答に Cache-Control、Expires、Last-Modified、ETag ヘッダーのいずれも含まれていない場合、ESA は ESA のデフォルトのキャッシュポリシーに基づいてリソースをキャッシュします。

  キャッシュポリシーの詳細

  

  Cache-Control 応答ヘッダー

  オリジン応答の Cache-Control ヘッダーは、次のいずれかのポリシーを指定します。

  1. Cache-Control ヘッダーに次のいずれかのディレクティブがある場合、リソースはキャッシュされません。

     • no-cache

     • no-store

     • max-age=0

  2. Cache-Control ヘッダーに、3600 などの 0 より大きい値を持つ max-age または s-maxage ディレクティブが含まれている場合、そのディレクティブで指定された TTL が使用されます。max-age と s-maxage の両方のディレクティブが存在する場合、s-maxage ディレクティブの値が優先されます。

  応答に Cache-Control がない場合

  オリジン応答に Cache-Control ヘッダーが含まれていない場合、ESA のデフォルトのキャッシュポリシーが使用されます。オリジンサーバーからの応答ヘッダーは、Expires > Last-Modified > ETag の優先順位で処理されます。

  1. オリジン応答に Expires ヘッダー (例：Expires:Tue, 25 Nov 2031 17:25:43 GMT) が含まれている場合、ESA は Expires ヘッダーで設定された TTL を使用します。

  2. オリジン応答に Expires ヘッダーは含まれていないが、Last-Modified ヘッダーが含まれている場合、TTL は次のルールに基づいて計算されます。

     • TTL = (現在の時刻 - Last-Modified の値) × 0.1。計算結果が 10 秒から 3,600 秒の範囲内であれば、実際の値が使用されます。計算結果が 10 秒未満の場合は TTL は 10 秒になり、3,600 秒を超える場合は TTL は 3,600 秒になります。

  3. オリジン応答に ETag ヘッダーのみが含まれている場合、TTL は 10 秒です。

  4. オリジン応答に Cache-Control、Expires、ETag、または Last-Modified ヘッダーが含まれていない場合、リソースはキャッシュされません。

• オリジンサーバーのキャッシュポリシーが存在する場合はそれを優先し、存在しない場合はキャッシュしない：オリジンサーバーから返された応答に、キャッシュポリシーを設定するための Cache-Control ヘッダーが含まれている場合、ESA はオリジンサーバーのキャッシュポリシーを使用します。オリジンサーバーから返された応答に Cache-Control ヘッダーが含まれていない場合、ESA はリソースをキャッシュしません。

  キャッシュポリシーの詳細

  

  オリジンサーバーのキャッシュポリシーの決定

  オリジンサーバーのキャッシュポリシーを決定するには、オリジン応答に Cache-Control ヘッダーが含まれているかどうかを確認します。ヘッダーが存在しない場合、リソースはキャッシュされません。ヘッダーが存在する場合、次のいずれかのキャッシュポリシーが適用されます。

  1. Cache-Control ヘッダーに no-cache、no-store、または max-age=0 ディレクティブが含まれている場合、リソースはキャッシュされません。

  2. Cache-Control ヘッダーに、3600 などの 0 より大きい値を持つ max-age または s-maxage ディレクティブが含まれている場合、そのディレクティブで指定された TTL が使用されます。max-age と s-maxage の両方のディレクティブが存在する場合、s-maxage ディレクティブの値が優先されます。

• キャッシュしない：オリジンサーバーから取得されたすべてのリソースは、ESA POP にキャッシュされません。

• カスタムキャッシュ有効期間を使用する：ESA は、オリジン応答のキャッシュポリシーにある Cache-Control、Expires、Last-Modified、ETag ヘッダーを無視し、ESA で設定された TTL を使用します。

エラーステータスコードを持つ応答のキャッシュルール

• ステータスコード 204、305、404、405、414、424、429、500、501、502、503、504 の場合、キャッシュルールは次のとおりです。

  1. オリジンサーバーが set-cookie 応答ヘッダーを返す場合、応答はキャッシュされません。

  2. オリジンサーバーが set-cookie 応答ヘッダーを返さない場合、システムはコンソールでそのステータスコードの TTL が設定されているかを確認します。

     1. TTL が設定されている場合、応答はコンソールでの設定に基づいてキャッシュされます。複数のルールが設定されている場合、序数が最も小さいルールが有効になります。

     2. TTL が設定されていない場合、応答はオリジンサーバーからの Pragma、Cache-Control、または Expires 応答ヘッダーに基づいてキャッシュされます。

  3. オリジンサーバーが Pragma、Cache-Control、または Expires 応答ヘッダーを返さない場合、応答はデフォルトで 1 秒間キャッシュされます。

• ステータスコード 302、307、403 の場合、キャッシュルールは次のとおりです。

  1. オリジンサーバーが set-cookie 応答ヘッダーを返す場合、応答はキャッシュされません。

  2. オリジンサーバーが set-cookie 応答ヘッダーを返さない場合、システムはコンソールでそのステータスコードの TTL が設定されているかを確認します。

     1. TTL が設定されている場合、応答はコンソールでの設定に基づいてキャッシュされます。複数のルールが設定されている場合、序数が最も小さいルールが有効になります。

     2. TTL が設定されていない場合、応答はオリジンサーバーからの Pragma、Cache-Control、または Expires 応答ヘッダーに基づいてキャッシュされます。

  3. オリジンサーバーが Pragma、Cache-Control、または Expires 応答ヘッダーを返さない場合、応答はキャッシュされません。

• 400 などの他のエラーステータスコードの場合、キャッシュルールは次のとおりです。

  1. オリジンサーバーが set-cookie 応答ヘッダーを返す場合、応答はキャッシュされません。

  2. オリジンサーバーが set-cookie 応答ヘッダーを返さない場合、システムはコンソールでそのステータスコードの TTL が設定されているかを確認します。複数のルールが設定されている場合、序数が最も小さいルールが有効になります。

  3. その他すべての場合、応答はキャッシュされません。

• レンジオリジンフェッチを使用するリクエストの場合、POP がオリジンサーバーから 206 以外のステータスコードを持つ応答を受信すると、POP はキャッシュされたファイルシャードを削除します。オリジンフェッチのタイムアウトでは、キャッシュファイルは削除されません。

  レンジオリジンフェッチを使用する場合、オリジンサーバーは大きなファイルを複数の小さなファイルシャードに分割して POP に送信します。たとえば、ファイルが 10 個のシャードに分割され、POP がこれらのシャードのうち 5 個をキャッシュしているとします。POP が 6 番目のシャードをリクエストし、オリジンサーバーが 5xx ステータスコードを返した場合、POP はキャッシュされている 5 個すべてのシャードを削除します。

キャッシュ応答情報

ESA POP は、HTTP リクエストを動的に調整できるように、標準的で明確な応答を提供します。キャッシュに関連する応答ヘッダーには、次の情報が含まれています。

• Ali-Swift-Global-Savetime：リソースが最初に ESA POP に入った時刻 (ウェブサイトのキャッシュアーキテクチャによって決定され、L2 POP または別のキャッシュ層の POP である場合があります)。

  • 値は UNIX タイムスタンプです。例：1745053111 は 2025年4月19日 16:58:31 を示します。

• Date：オリジンサーバーがリソースを ESA POP に返す日付。

  • ESA POP がリソースを再検証するために If-Modified-Since または If-None-Match ヘッダーを含むオリジンリクエストを開始し、オリジンサーバーが HTTP ステータスコード 304 を返すと、日付が更新されます。

  • 時刻は GMT 形式です。例：Sat, 19 Apr 2025 08:58:31 GMT。

• X-Site-Cache-Status：リクエストされたリソースの ESA POP 上のキャッシュステータス。次のリストは、リソースの状態を説明しています。

  • HIT：リソースが ESA POP キャッシュ内で見つかりました。

  • MISS：リソースが ESA POP キャッシュ内で見つかりませんでした。POP はオリジンサーバーからリソースを取得し、クライアントに返します。

  • NONE/UNKNOWN：次の理由により、リソースはキャッシュ対象外です。

    • エッジ関数が応答を生成したが、サブリクエストを送信しなかった場合。この場合、応答はキャッシュからのものではなく、キャッシュステータスは none/unknown として記録されます。

    • エッジ関数のメインリクエストがサブリクエスト (fetch) を開始すると、サブリクエストのキャッシュステータスが記録され、メインリクエストのキャッシュステータスは none/unknown として記録されます。これは、エッジ関数モジュールがキャッシュモジュールより前に実行されるため、メインリクエストがキャッシュを通過しないために発生します。

    • クライアントリクエストがカスタム WAF ルールにヒットし、WAF によってブロックされた場合。WAF はキャッシュモジュールより前に実行されるため、リクエストはキャッシュを通過せず、キャッシュステータスは none/unknown として記録されます。

    • クライアントリクエストがリダイレクトルールまたはHTTPS ルールにヒットした場合。POP は別の URL へのリダイレクト応答を送信します。これらのルールはキャッシュモジュールより前に実行されるため、キャッシュステータスは none/unknown として記録されます。

  • EXPIRED：リソースは ESA POP キャッシュ内で見つかりましたが、期限切れです。POP はオリジンサーバーからリソースを取得し、クライアントに返します。オリジンサーバーから返されるステータスコードは 200 または 206 です。

  • STALE：

    リソースは ESA POP キャッシュから提供されますが、期限切れです。これは次の場合に発生します。

    • キャッシュ設定が [オリジンサーバーの TTL に従う] で、オリジン応答に Cache-Control:stale-while-revalidate=<seconds> が含まれている場合。指定された時間内に、ESA はリソースを再検証するためにオリジンサーバーへのリクエストを開始し、期限切れのキャッシュをクライアントに提供します。

    • キャッシュ設定が [オリジンサーバーの TTL に従う] で、オリジン応答に Cache-Control:stale-if-error==<seconds> が含まれている場合。指定された時間内に、ESA が更新されたリソースを取得するためにオリジンサーバーに接続できない場合、ESA は期限切れのキャッシュをクライアントに提供します。

    • 応答キャッシュの有効期限を設定機能が有効になっている場合。この機能により、オリジン応答がタイムアウトした場合やオリジンサーバーに到達できない場合に、ESA POP は期限切れのキャッシュをクライアントに提供できます。

  • BYPASS

    リソースへのリクエストは ESA キャッシュをバイパスします。これは次の場合に発生します。

    • キャッシュ設定が [オリジンサーバーの TTL に従う] ではなく、ESA がカスタムキャッシュ TTL を 0 秒に設定している場合。

    • キャッシュ設定が [オリジンサーバーの TTL に従う] であるが、オリジンサーバーから返された Cache-Control ヘッダーの値が no-cache、no-store、または max-age=0 である場合。

  • REVALIDATED

    リソースは ESA キャッシュによって提供されますが、期限切れです。ESA は、リソースを再検証するために If-Modified-Since または lf-None-Match ヘッダーを含むオリジンリクエストをオリジンサーバーに開始します。オリジンサーバーは HTTP ステータスコード 304 を返します。

  • DYNAMIC

    ESA は、リソースが動的コンテンツであり、そのようなリクエストに適用される定義済みのキャッシュルールがないことを検出します。この場合、ESA はオリジンサーバーからリソースを取得し、クライアントに返します。

• X-Swift-Cachetime：POP 上のリソースの TTL を秒単位で指定します。X-Swift-Cachetime の値は ESA で設定された TTL と同じではありません。次の数式を使用して計算されます：X-Swift-Cachetime = Ali-Swift-Global-Savetime + ESA で設定された TTL - X-Swift-SaveTime。次のシナリオが発生する可能性があります。

  • X-Swift-Cachetime の値が ESA で設定された TTL (例：3600 秒) と等しい。

  • X-Swift-Cachetime の値が ESA で設定された TTL よりわずかに小さい。たとえば、ESA で設定された TTL が 300 秒の場合、X-Swift-Cachetime の値は 295 秒になることがあります。この不一致は、次の理由で発生する可能性があります。

    • L1 ノードが L2 ノードからコンテンツをフェッチする際に高いレイテンシーが発生する。

    • L1 ノードと L2 ノードの時計が同期していない。

  • X-Swift-Cachetime の値が負になる。これは、リソースがキャッシュされた後に ESA の TTL 設定を変更した場合に発生する可能性があります。これは、L1 ノードのキャッシュが期限切れになった後、L2 ノードのキャッシュがまだ有効な間にクライアントリクエストが到着した場合に発生します。たとえば、ESA で TTL が最初に 3600 秒に設定され、後で 300 秒に変更されたとします。リソースがキャッシュされてから 600 秒後にクライアントがリクエストを送信すると、応答には X-Swift-Cachetime:-300 が含まれます。この問題を解決するには、キャッシュをリフレッシュします。

• X-Swift-Cachetime：

  ESA POP 上のリソースのキャッシュ TTL。単位：秒。

• X-Swift-SaveTime：

  • リソースがクライアントリクエストを受信する現在の POP (L1 POP) に最初に入った時刻。

  • 時刻は GMT 形式です。例：Sat, 19 Apr 2025 08:58:31 GMT。

キャッシュしないポリシー

ESA POP は、次の条件下ではファイルをキャッシュせず、すべてのファイルリクエストをパススルーします。

• エッジキャッシュの有効期間 は、ESA の [設定] ページで オリジンサーバーのキャッシュポリシーが存在する場合はそれを優先し、存在しない場合はキャッシュしない に設定されており、オリジン応答は Cache-Control: no-store です。

• ESA の [設定] ページの エッジキャッシュの有効期間 は、キャッシュしない に設定されています。

• ESA の [設定] ページの エッジキャッシュの有効期間 が カスタムキャッシュ有効期間を使用する に設定され、キャッシュ TTL が 0 秒に設定されています。

キャッシュの再検証

ESA POP 上のキャッシュされたファイルが期限切れになると、次にクライアントがそのファイルをリクエストしたときにキャッシュの再検証メカニズムが有効になります。ESA POP はオリジンサーバーに検証リクエストを送信します。ファイルが変更されていない場合、オリジンサーバーは 304 not-modified メッセージを返し、ESA POP はファイルを再ダウンロードすることなく、キャッシュされたファイルをクライアントに提供し続けます。これにより、クライアントリクエストの応答速度が効果的に向上し、オリジンサーバーからの応答トラフィックが削減されます。

• 特別なポリシー設定：ファイルは 0 秒間キャッシュされ、ESA POP は各リクエストを検証のためにオリジンサーバーにリダイレクトします。

  • ESA の [設定] ページで、[エッジキャッシュ TTL] が [オリジンの TTL に従う、またはデフォルトのキャッシュルールを使用] に設定されており、かつオリジンの応答が以下の条件を満たします:

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• 通常のポリシー設定：オリジンサーバーはキャッシュ検証に関連するポリシーに応答し、ESA POP は実際のポリシーを実行します。

  • [エッジキャッシュ TTL] は、ESA の [設定] ページで [オリジンの TTL に従う、またはデフォルトのキャッシュルールを使用] に設定されており、かつオリジン応答が次のいずれかのキャッシュ検証ポリシーを満たしています：

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• キャッシュ検証ポリシー

  次のリストは、キャッシュ検証ポリシーを説明し、関連する例を提供します。

  • must-revalidate

    • 説明：このポリシーは、リソースが期限切れになった場合、キャッシュ (プロキシキャッシュやブラウザキャッシュを含む) が応答を返す前に、その鮮度を検証するためにリソースをオリジンサーバーに返す必要があることを示します。ユーザーがオフラインであるか、ネットワークが利用できない場合でも、リソースが変更されていないことが検証されない限り、キャッシュは期限切れのリソースを直接使用できません。

    • 例：Cache-Control: max-age=3600, must-revalidate は、リソースが期限切れになった後、その鮮度を検証するためにオリジンサーバーに返す必要があることを示します。

  • proxy-revalidate

    • 説明：must-revalidate ポリシーと同様に、このポリシーは CDN やプロキシサーバーキャッシュなどの共有キャッシュにのみ適用されます。このポリシーは、ブラウザキャッシュなどのプライベートキャッシュには適用されません。リソースが期限切れになった場合、共有キャッシュがキャッシュレプリカを提供する前に、検証のためにリソースをオリジンサーバーに返す必要があります。プライベートキャッシュはこの制限を受けません。

    • 例：Cache-Control: max-age=3600, proxy-revalidate は、リソースが期限切れになった後、その鮮度を検証するためにオリジンサーバーに返す必要があることを示します。

  • stale-while-revalidate=seconds

    • 説明：このポリシーは、リソースが期限切れになった後、指定された期間 (秒単位)、キャッシュが古いキャッシュされたリソースを提供し続けることができることを示します。同時に、POP はバックグラウンドでオリジンサーバーから最新のコンテンツを非同期にリクエストします。このポリシーは、待機時間を短縮し、短時間であれば最新でない可能性のあるコンテンツを受け入れられる場合に適用されます。

    • 例：Cache-Control: max-age=3600, stale-while-revalidate=60 は、リソースが最初に公開されてから 3,600 秒 (1 時間) は新鮮であると見なされることを示します。期限切れになると、リソースは次の 60 秒間ユーザーに提供され続けることができます。同時に、POP はオリジンサーバーから更新を取得しようとします。

  • stale-if-error=seconds

    • 説明：このポリシーは、サーバーの故障やネットワークエラーなどの理由で POP がオリジンサーバーから最新のコンテンツを取得できない場合に、POP がリソースが期限切れであるがまだキャッシュされていることを示す応答を返すことを許可します。エラーが発生した場合に期限切れのキャッシュコンテンツを使用できる期間 (秒単位) が定義されます。これにより、システムのフォールトトレランスが向上し、オリジンサーバーが利用できない場合でも以前にキャッシュされたコンテンツにアクセスできるようになり、ユーザーエクスペリエンスが向上し、サービス中断の影響が軽減されます。

    • 例：Cache-Control: max-age=86400, stale-if-error=604800 は、リソースが最初に公開されてから 86,400 秒 (24 時間) は新鮮であると見なされることを示します。86,400 秒後の再検証が失敗した場合、最後に正常にキャッシュされたリソースは、次の 604,800 秒 (1 週間) 提供され続けることができます。