Edge Security Acceleration (ESA) は、オリジンサーバーの静的リソースを各クライアントに最も近いエッジノード (POP) にキャッシュすることで、レイテンシーを削減します。各 POP にはキャッシュコンポーネントが含まれています。リクエストまたはオリジン応答が POP を通過すると、コンポーネントはオリジンリソースをキャッシュし、生存時間 (TTL) を割り当てます。
グローバルな ブラウザキャッシュ TTL は、デフォルトでキャッシュされるファイルの拡張子で定義されたリソースタイプだけでなく、すべてのリクエストに適用されます。
デフォルトのキャッシュポリシー
キャッシュ設定は、ESA のキャッシュコンポーネントにルーティングされるリクエストにのみ適用されます。ESA は、以下の手順でリクエストがキャッシュに入るかどうかを判断します。
リクエストが GET または HEAD タイプであるかを確認します。
リクエストがキャッシュルールで指定された条件を満たしているかを確認します。リクエストが条件を満たす場合、グローバルキャッシュ設定ではなく、キャッシュルールがリクエストに適用されます。詳細については、「成功応答とリダイレクトのキャッシュルール」をご参照ください。
ファイルの拡張子が「デフォルトでキャッシュされるファイルの拡張子」にリストされているかを確認します。リストされている場合、グローバルキャッシュ設定がリクエストに適用されます。
デフォルトでキャッシュされるファイルの拡張子
デフォルトでは、ESA は、ファイルの拡張子が以下にリストされているものと一致する場合にのみファイルをキャッシュします。TTL は、一致するキャッシュルールによって決定されます。
キャッシュしたいリソースタイプが以下のリストにない場合は、そのようなタイプのリソースに対してキャッシュルールを作成してください。詳細については、「ルール」をご参照ください。
カテゴリ別のサポートされているファイルの拡張子：
ドキュメント：
DOCおよびDOCX：Microsoft Word ドキュメント。PPTおよびPPTX：Microsoft PowerPoint プレゼンテーション。PDF：ポータブルドキュメント。CSV：カンマ区切り値ファイル。
画像ファイル：
BMP：ビットマップ画像。GIF：グラフィックス交換形式 (GIF) 画像。ICO：アイコン画像。JPEGおよびJPG：Joint Photographic Experts Group (JPEG) 画像。PNG：Portable Network Graphics (PNG) 画像。SVGおよびSVGZ：Scalable Vector Graphics (SVG) 画像。TIFおよびTIFF：Tagged Image File Format (TIFF) 画像。WEBP：可逆圧縮と非可逆圧縮の両方をサポートする WebP 画像。
音声ファイル：
MP3：MPEG-1 Audio Layer III (MP3) ファイル。FLAC：Free Lossless Audio Codec (FLAC) ファイル。MIDおよびMIDI：Musical Instrument Digital Interface (MIDI) ファイル。
動画ファイル：
AVI：Audio Video Interleave (AVI) ファイル。MP4：MPEG-4 (MP4) ファイル。MKV：Matroska Video (MKV) ファイル。WEBM：ビデオとオーディオをサポートするオープンメディアコンテナフォーマット。
圧縮ファイル：
7Z：7-Zip ファイル。GZ：GNU Gzip ファイル。RAR：RAR ファイル。TAR：TAR ファイル。ZIP：ZIP ファイル。ZST：Zstandard ファイル。
実行可能ファイル (実行可能プログラム/インストールパッケージ)：
APK：Android パッケージファイル。BIN：ファームウェアの更新によく使用されるバイナリファイル。CLASS：Java バイトコードファイル。DMG：macOS ディスクイメージファイル。EXE：Windows 実行可能ファイル。JAR：Java アーカイブ (JAR) ファイル。MSI：Windows インストーラーファイル。ISO：ISO イメージファイル。
フォントファイル：
EOT：Embedded OpenType (EOT) フォントファイル。OTF：OpenType フォント (OTF) ファイル。TTF：TrueType フォント (TTF) ファイル。WOFFおよびWOFF2：Web Open Font Format (WOFF) ファイル。
スクリプトおよびコードファイル：
CSS：カスケードスタイルシート (CSS) ファイル。EJS：Embedded JavaScript (EJS) テンプレートファイル。JS：JavaScript (JS) ファイル。デザインおよびベクターグラフィックスファイル：
EPS：Encapsulated PostScript (EPS) ファイル。PICT：Apple PICT ファイル。PS：PostScript (PS) ファイル。SWF：Shockwave Flash (SWF) ファイル。
成功応答とリダイレクトのキャッシュルール
適用されるステータスコード：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ヘッダーが含まれている場合、ESA はオリジンサーバーのキャッシュポリシーを使用します。オリジンサーバーから返された応答にCache-Controlヘッダーが含まれていない場合、ESA はリソースをキャッシュしません。キャッシュしない：オリジンサーバーから取得されたすべてのリソースは、ESA POP にキャッシュされません。
カスタムキャッシュ有効期間を使用する：ESA は、オリジン応答のキャッシュポリシーにある
Cache-Control、Expires、Last-Modified、およびETagヘッダーを無視し、ESA で設定された TTL を使用します。
エラーステータスコードを持つ応答のキャッシュルール
ステータスコード 204、305、404、405、414、424、429、500、501、502、503、および 504 の場合、キャッシュルールは次のとおりです。
オリジンサーバーが
set-cookie応答ヘッダーを返す場合、応答はキャッシュされません。オリジンサーバーが
set-cookie応答ヘッダーを返さない場合、システムはコンソールでステータスコードの TTL が設定されているかどうかを確認します。TTL が設定されている場合、応答はコンソールの設定に基づいてキャッシュされます。複数のルールが設定されている場合、序数が最も小さいルールが有効になります。
TTL が設定されていない場合、応答はオリジンサーバーからの
Pragma、Cache-Control、またはExpires応答ヘッダーに基づいてキャッシュされます。
オリジンサーバーが
Pragma、Cache-Control、またはExpires応答ヘッダーを返さない場合、応答はデフォルトで 1 秒間キャッシュされます。
ステータスコード 302、307、および 403 の場合、キャッシュルールは次のとおりです。
オリジンサーバーが
set-cookie応答ヘッダーを返す場合、応答はキャッシュされません。オリジンサーバーが
set-cookie応答ヘッダーを返さない場合、システムはコンソールでステータスコードの TTL が設定されているかどうかを確認します。TTL が設定されている場合、応答はコンソールの設定に基づいてキャッシュされます。複数のルールが設定されている場合、序数が最も小さいルールが有効になります。
TTL が設定されていない場合、応答はオリジンサーバーからの
Pragma、Cache-Control、またはExpires応答ヘッダーに基づいてキャッシュされます。
オリジンサーバーが
Pragma、Cache-Control、またはExpires応答ヘッダーを返さない場合、応答はキャッシュされません。
400 などの他のエラーステータスコードの場合、キャッシュルールは次のとおりです。
オリジンサーバーが
set-cookie応答ヘッダーを返す場合、応答はキャッシュされません。オリジンサーバーが
set-cookie応答ヘッダーを返さない場合、システムはコンソールでステータスコードの TTL が設定されているかどうかを確認します。複数のルールが設定されている場合、序数が最も小さいルールが有効になります。その他すべての場合、応答はキャッシュされません。
Range オリジンフェッチを使用するリクエストの場合、POP がオリジンサーバーから 206 以外のステータスコードを持つ応答を受信すると、POP はキャッシュされたファイルシャードを削除します。オリジンフェッチのタイムアウトは、キャッシュファイルの削除を引き起こしません。
Range オリジンフェッチを使用する場合、オリジンサーバーは大きなファイルを複数の小さなファイルシャードに分割し、POP に送信します。たとえば、ファイルが 10 個のシャードに分割され、POP がこれらのシャードのうち 5 つをキャッシュしているとします。POP が 6 番目のシャードをリクエストし、オリジンサーバーが 5xx ステータスコードを返した場合、POP はキャッシュされている 5 つのシャードすべてを削除します。
キャッシュ応答情報
ESA POP は、以下の情報を含むキャッシュ関連の応答ヘッダーを返します。
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-storeである場合。
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 POP 上のキャッシュされたファイルが期限切れになると、ESA POP は次のクライアントリクエストでオリジンサーバーに検証リクエストを送信します。ファイルが変更されていない場合、オリジンサーバーは 304 not-modified を返し、ESA POP は再ダウンロードせずにキャッシュされたファイルを提供します。これにより、オリジントラフィックが削減され、応答速度が向上します。
特別なポリシー設定：ファイルは 0 秒間キャッシュされ、ESA POP は各リクエストをオリジンサーバーにリダイレクトして検証します。
[エッジキャッシュ TTL] が、ESA の [設定] ページで [オリジンの TTL に従うか、デフォルトのキャッシュルールを使用する] に設定されており、かつオリジン応答が以下の条件を満たす場合：
Cache-Control: no-cacheCache-Control: max-age=0
通常のポリシー設定：オリジンサーバーはキャッシュ検証に関連するポリシーに応答し、ESA POP は実際のポリシーを実行します。
ESA の [設定] ページで [エッジキャッシュ TTL] が [オリジンの TTL を優先、またはデフォルトのキャッシュルールを使用] に設定されており、かつオリジン応答が次のいずれかのキャッシュ検証ポリシーを満たしています：
must-revalidateproxy-revalidatestale-while-revalidate=secondsstale-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
説明：期限切れ後、キャッシュは指定された期間、古いコンテンツを提供しながら、バックグラウンドで非同期にオリジンと再検証します。これは、わずかに古いコンテンツを提供することよりもレイテンシーの削減が重要な場合に使用します。
例：
Cache-Control: max-age=3600, stale-while-revalidate=60は、リソースが最初に公開されてから 3,600 秒 (1 時間) 新鮮であると見なされることを示します。一度期限切れになると、リソースは次の 60 秒間ユーザーに提供され続けます。同時に、POP はオリジンサーバーから更新を取得しようとします。
stale-if-error=seconds
説明：オリジンに到達できない場合 (サーバーの機能停止、ネットワークエラー)、POP は指定された期間、期限切れのキャッシュコンテンツを提供します。これにより、フォールトトレランスが向上し、オリジンの停止中でも可用性が維持されます。
例：
Cache-Control: max-age=86400, stale-if-error=604800は、リソースが最初に公開されてから 86,400 秒 (24 時間) 新鮮であると見なされることを示します。86,400 秒後の再検証が失敗した場合でも、最後に正常にキャッシュされたリソースは、次の 604,800 秒 (1 週間) 提供され続けます。