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

Edge Security Acceleration:カスタムキャッシュキー

最終更新日:Dec 17, 2025

ユーザーリクエストのクエリ文字列、HTTP リクエストヘッダー、Cookie など、さまざまな部分に基づいてルールを作成し、カスタムキャッシュキーを生成できます。この機能は、同じファイルにアクセスする一連のリクエストのキャッシュキーを統一します。これにより、リクエストパラメーターが異なるために同じファイルへのリクエストが異なるファイルとしてキャッシュされるのを防ぎます。結果として、キャッシュヒット率が向上し、応答時間と帯域幅消費量の両方が削減されます。

背景情報

  • カスタムキャッシュキー機能は、back-to-origin URL を変更しません。リクエストのキャッシュ ID のみを変更します。これにより、back-to-origin リクエストがクライアントリクエストと一致することが保証されます。

  • キャッシュキーは、ESA の POP (Point of Presence) にキャッシュされたファイルの一意の識別子です。POP にキャッシュされた各ファイルには、一意のキャッシュキーがあります。デフォルトでは、キャッシュキーはパラメーターを含むクライアントリクエストの完全な URL です。

利用シーン

利用シーン 1:キャッシュキーの統一

お客様のリクエスト URL には複雑なパラメーターが含まれています。その結果、複数のリクエストが同じファイルにアクセスしている場合でも、ESA の POP は URL パラメーターが異なるため、それらを異なるファイルへのリクエストとして扱います。POP はそれらを複数のファイルとしてキャッシュするため、back-to-origin リクエストの数が増加します。

この問題を解決するには、カスタムキャッシュキー機能を使用してクエリ文字列を無視します。これにより、同じクラスのリクエストのキャッシュキーが統一され、back-to-origin 率が低下します。

image

利用シーン 2:キャッシュキーの区別

クライアントのリクエスト URL が同一の場合、ESA はそれらを同じファイルへのリクエストとして扱います。ただし、HTTP リクエストヘッダーの client フィールドは、異なるクライアントシステムを区別できます。これは、異なるファイルがリクエストされていることを示します。

この場合、カスタムキャッシュキー機能を使用して、クライアントタイプに基づいて異なるキャッシュキーを生成できます。これにより、2 つのリクエストが 2 つの異なるキャッシュキーで識別されるようになります。

image

操作手順

ルールを追加すると、ユーザーがリソースをリクエストしたときに、ESAルール実行の優先順位に基づいてルールを順番に照合し、実行します。

  1. ESA コンソールで、サイト管理 を選択します。[サイト] 列で、対象のサイトをクリックします。

  2. 左側のナビゲーションウィンドウで、ルール > キャッシュルール を選択します。

  3. [ルールを追加] をクリックし、[ルール名] を入力します。

  4. [リクエストが以下のルールと一致する場合...] セクションで、リクエストが一致する必要のある条件を設定します。詳細については、「ルール式の構成」をご参照ください。

  5. [キャッシュの適格性] セクションで、[キャッシュ可否] を [キャッシュ対象] に設定します。

  6. [カスタムキャッシュキー] セクションで、[設定] をクリックし、次のパラメーターを設定します。

    image

    パラメーター

    説明

    [クエリ文字列のソート]

    クエリ文字列のソート機能を有効にするかどうかを指定します。

    クエリ文字列

    リクエスト URL から ? とそれに続くクエリ文字列を削除するかどうかを指定します。

    [HTTP リクエストヘッダー]

    • [これらのヘッダー名とその値を含める]:指定された HTTP リクエストヘッダー名とその値をキャッシュキーに追加します。

    • [存在するかどうかをチェック]:指定された HTTP リクエストヘッダーが存在するかどうかをチェックします。存在する場合、その名前がキャッシュキーに追加されます。

    [Cookie]

    • [これらの Cookie 名とその値を含める]:指定された Cookie パラメーター名とその値をキャッシュキーに追加します。

    • [存在するかどうかをチェック]:指定された Cookie パラメーターが存在するかどうかをチェックします。存在する場合、その名前がキャッシュキーに追加されます。

    ユーザー

    • [デバイスのタイプ]:クライアントの User-Agent 情報に基づいてクライアントタイプを識別し、クライアントタイプに基づいてキャッシュキーを生成します。

    • [国 / 地域]:クライアントの IP アドレスに基づいてクライアントの国またはリージョンを識別し、国またはリージョンに基づいてキャッシュキーを生成します。

    • [言語]:クライアントリクエストの Accept-Language 情報に基づいてクライアントの言語を識別し、言語タイプに基づいてキャッシュキーを生成します。

    [Web キャッシュ詐欺からの保護]

    静的コンテンツのキャッシュを許可しながら、Web キャッシュ汚染攻撃から防御します。

  7. [OK] をクリックします。

設定例

シナリオ例

  • ユーザーリクエスト URL:http://www.example.com/image.jpg?key123=321&key456=654

  • ユーザーリクエストに含まれるリクエストヘッダー:

    • name123:321

    • name456:654

    • User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.X.X Safari/537.36

    • Accept-Language:zh-CN

  • クライアントは中国電信の IP アドレスを使用してサービスにアクセスします。

機能設定

  • [クエリ文字列]:パラメーター key456 を削除

  • [HTTP リクエストヘッダー]:

    • [これらのヘッダー名とその値を含める]:name123

    • [存在するかどうかをチェック]:name456

  • [ユーザー]:[デバイスのタイプ]、[国 / 地域]、[言語] のスイッチはすべてオンになっています。

image

生成されたキャッシュキー

各パラメーターに対して生成されるキャッシュキーの断片は次のとおりです:

  • http://www.example.com/image.jpg?key123=321

  • name123:321

  • name456

  • desktop

  • CN

  • Accept-Language:zh-CN

したがって、最終的なキャッシュキーはこれらの断片を連結したものです:http://example.com/image.jpg?key123=321name123:321name456desktopCNAccept-Language:zh-CN

関連ドキュメント

ルール関連の機能は、実行の優先順位ルールの動作設定範囲が異なります。詳細については、「ESA ルールの有効化の仕組み」をご参照ください。