すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:May 01, 2026

    HTTP リクエストの URI、クエリパラメーター、HTTP ヘッダー、カスタム変数などの異なる部分からキャッシュキーを生成するルールを定義するため、カスタムキャッシュキーを構成します。これにより、同一ファイルに対する類似したリクエストが単一のキャッシュキーにマップされ、キャッシュヒット率が向上し、オリジンフェッチレートが低下し、応答時間と帯域幅消費が削減されます。

    注意事項

    カスタムキャッシュキーとパラメーター無視

    カスタムキャッシュキーの パラメーター操作 機能と パラメーター無視 機能は、どちらも URL クエリパラメーターをキャッシュキーの生成に含めるかどうかを制御します。両方の機能を同時に有効にすると、キャッシュキー生成ルールに競合が発生し、キャッシュヒット率が低下したり、キャッシュされたコンテンツが異常になったりする可能性があります。

    重要

    カスタムキャッシュキーのパラメーター操作を使用する場合は、ルールの競合を防ぐためにパラメーター無視機能を無効にしてください。カスタムキャッシュキーのパラメーター操作には、パラメーター無視機能の機能（削除 または 予約 操作を使用）が含まれており、より柔軟なパラメーター制御が可能です。

    パラメーター無視機能を使用している場合、以下の表を参照して、カスタムキャッシュキーのパラメーター操作に切り替えるかどうかを判断してください。

    シナリオ

    パラメーター無視

    カスタムキャッシュキー

    キャッシュキー内のすべてのクエリパラメーターを無視する

    パラメーター無視 を はい に設定し、指定したパラメーターを保持 を空のままにします。

    クエリパラメーター の処理ルールを追加します。

    • 操作：保持

    • パラメーター名：example-argument など、存在しないパラメーター名を設定します。

    キャッシュキー内にクエリパラメーター key1 のみを保持する

    パラメーター無視 を はい に設定し、指定したパラメーターを保持 に key1 を設定します。

    クエリパラメーター の処理ルールを追加します。

    • 操作：保持

    • パラメーター名：key1

    キャッシュキーからクエリパラメーター key1 のみを削除する

    指定したパラメーターを削除 に key1 を設定します。

    クエリパラメーター の処理ルールを追加します。

    • 操作：削除

    • パラメーター名：key1

    説明

    パラメーターの無視または保持に加えて、パラメーター値のさらに詳細な変更や追加パラメーターの追加が必要な場合は、パラメーター無視機能ではなく、カスタムキャッシュキーのパラメーター操作を使用することを推奨します。

    ルールエンジンの実行順序

    説明

    この機能がルールエンジンのルール条件を参照する場合、実行順序はこの機能内で構成されたルールの優先度ではなく、ルールエンジンで設定されたルール条件の優先度に基づきます。

    キャッシュリフレッシュ

    カスタムキャッシュキーを構成すると、DCDN PoP は処理済みのキャッシュキーを使用してキャッシュされたファイルをインデックスします。URL でキャッシュをリフレッシュする際は、DCDN PoP 上のキャッシュキーと一致する URL を送信する必要があります。そうでない場合、リフレッシュ操作で対象コンテンツが見つかりません。

    説明

    たとえば、URI 置き換えルールを構成して /a/b/image.jpg を /c/image.jpg に置き換えた場合、DCDN PoP 上のファイルのキャッシュキーは http://aliyundoc.com/c/image.jpg になります。このファイルのキャッシュをリフレッシュするには、元のクライアントリクエスト URL ではなく、処理済みのキャッシュキーである http://aliyundoc.com/c/image.jpg を送信する必要があります。

    パラメーターの削除や変更などのパラメーター操作を構成した場合も、リフレッシュアドレスとして処理済みの URL を使用する必要があります。今後のキャッシュリフレッシュ操作を簡素化するために、カスタムキャッシュキールールを構成した後は、最終的なキャッシュキーのフォーマットを記録しておくことを推奨します。

    オリジン URL 書き換え

    カスタムキャッシュキー機能は、DCDN PoP 上でのキャッシュキーの生成方法にのみ影響します。オリジンフェッチに使用される実際の URL は変更しません。DCDN PoP がオリジンフェッチを実行する際は、オリジンからコンテンツを取得するために引き続き元のクライアントリクエスト URL を使用します。オリジンに送信されるリクエストのパラメーターやパスを書き換えるには、オリジン URL 書き換え機能を使用してください。

    説明

    たとえば、クライアントが http://example.com/image.jpg?key1=1&key2=2 をリクエストします。カスタムキャッシュキーを構成して key1 パラメーターを削除した場合、キャッシュキーは http://example.com/image.jpg?key2=2 になります。ただし、DCDN PoP がオリジンフェッチを実行する際は、引き続き元の URL http://example.com/image.jpg?key1=1&key2=2 をリクエストします。

    ユースケース

    重要

    カスタムキャッシュキー機能は、オリジンフェッチに使用される URL を変更しません。リクエストのキャッシュ識別子のみを変更します。オリジンに送信されるリクエストは、元のクライアントリクエストと同一です。

    キャッシュキーは、DCDN PoP 上にキャッシュされたファイルの一意の識別子です。デフォルトでは、このキーはクエリパラメーターを含む完全なリクエスト URL です。

    シナリオ 1

    同一ファイルに対するクライアントリクエストに異なる URL パラメーターが含まれる場合、DCDN PoP はそれらを異なるファイルに対するリクエストとして扱います。その結果、同一ファイルの複数のキャッシュコピーが作成され、オリジンフェッチが増加します。图一

    カスタムキャッシュキールールを使用して、類似したリクエストのキャッシュキーを統一できます。これにより、オリジンフェッチレートが低下します。图二

    シナリオ 2

    DCDN は、同じ URL を持つリクエストを同一ファイルに対するリクエストとして扱います。ただし、実際にはリクエストの HTTP ヘッダーにクライアントシステムを区別する client フィールドが含まれており、異なるファイルを取得することが目的です。Scenario 1

    このような場合、カスタム キャッシュキー を使用して、キャッシュキー に client フィールドの値を追加できます。これにより、2 つのリクエストは 2 つの異なるキャッシュキーとして識別されます。Scenario 2

    操作手順

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

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

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

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

    5. カスタムキャッシュキー タブで、キャッシュキーを構成します。

      説明

      最終的なキャッシュキーは、次の 4 つのコンポーネントの組み合わせです：URI、パラメーター操作、HTTP ヘッダー、カスタム変数。

      自定义Cachekey

      パラメーター

      説明

      ルール条件

      ルール条件は、リクエスト内のさまざまなパラメーターを評価することで、構成がリクエストに適用されるかどうかを決定します。

      重要

      機能がルールエンジンで構成されたルール条件を参照する場合、実行順序は関連付けられたルール条件の優先度に従い、機能構成の順序には従いません。

      • 条件を使用しない：条件付きルールを無効にします。

      • ルールエンジン で条件付きルールを追加または編集できます。

      URI

      クライアントリクエストの URI が構成済みの ソース URI に一致する場合、キャッシュキーの URI 部分を生成する際に、ソース URI を構成済みの ターゲット URI に置き換えます。

      複数の URI 置き換えルールを構成できます。複数のルールが存在する場合、上から下へ順に一致判定が行われます。一度 ソース URI が一致すると、対応する ターゲット URI が置き換えに使用され、以降のルールとの一致判定は停止します。

      • ソース URI：スラッシュ (/) で始まる URI で、http:// プレフィックスやドメイン名を含みません。 PCRE (Perl 互換正規表現) 正規表現をサポートします。

      • ターゲット URI：スラッシュ (/) で始まり、http:// プレフィックスやドメイン名を含まない URI です。

      パラメーター操作

      これらの操作は、元のリクエスト URL のクエリパラメーターに適用されます。パラメーターに対して 追加、削除、変更、または 予約 操作を実行できます。結果として得られるパラメーターがキャッシュキーのクエリ文字列部分を形成します。複数の操作を設定でき、上から下へ順に実行されます。

      • 追加：キャッシュキーに新しいクエリパラメーターを追加します。たとえば、元の URL が http://image.example.com/cat.jpg で、クエリパラメーター type=jpg を追加すると、キャッシュキーは http://image.example.com/cat.jpg?type=jpg になります。

      • 削除：キャッシュキーを生成する際に、元のリクエスト URL から指定されたクエリパラメーターを削除します。たとえば、元の URL が http://image.example.com/cat.jpg?type=jpg で、type パラメーターを削除すると、キャッシュキーは http://image.example.com/cat.jpg になります。

      • 変更：キャッシュキーを生成する際に、元のリクエスト URL の指定されたクエリパラメーターを変更します。たとえば、元の URL が http://image.example.com/cat.jpg?type=jpg で、パラメーターを type=png に変更すると、キャッシュキーは http://image.example.com/cat.jpg?type=png になります。

      • 予約：キャッシュキーを生成する際に、元のリクエスト URL から指定されたクエリパラメーターのみを保持します。たとえば、元の URL が http://image.example.com/cat.jpg?type=jpg&path=image で、type パラメーターを保持すると、キャッシュキーは http://image.example.com/cat.jpg?type=jpg になります。

      HTTP ヘッダー

      元のクライアントリクエストの指定された HTTP ヘッダーの値をキャッシュキーに追加します。スペースで区切って複数の HTTP ヘッダー名を構成できます。指定された各 HTTP ヘッダーの値が順にキャッシュキーに追加されます。

      たとえば、元の URL が http://image.example.com/cat.jpg で、クライアントリクエストに HTTP ヘッダー path: image が含まれており、HTTP ヘッダー 設定で path ヘッダーを含めるように設定した場合、キャッシュキーは http://image.example.com/cat.jpgimage になります。

      カスタム変数

      正規表現を使用して、元のクライアントリクエストの指定されたクエリパラメーター、HTTP ヘッダー、Cookie パラメーター、または URI の値をマッチングできます。マッチングが成功した場合、対応する値がキャッシュキーに追加されます。詳細については、「構成例」をご参照ください。

    6. OK をクリックして構成を完了します。

    構成例

    URI

    http://aliyundoc.com/a/b/image.jpg および http://aliyundoc.com/a/b/c/image.jpg へのリクエストは、同一ファイルに対するリクエストとして扱われます。このファイルのキャッシュキーは http://aliyundoc.com/c/image.jpg です。URI

    パラメーター操作

    http://aliyundoc.com/a/b/image.jpg?delete_par=1&modify_par=1 へのクライアントリクエストに対して、ルールにより add_par=1 が追加され、delete_par が削除され、modify_par の値が 2 に変更されます。最終的なキャッシュキーは http://aliyundoc.com/a/b/image.jpg?modify_par=2&add_par=1 です。

    重要

    パラメーター操作において、複数の操作が同一の変数に適用される場合、操作の優先度は次のとおりです：追加 > 削除 > 保持 > 変更。

    参数操作

    HTTP ヘッダー

    クライアントリクエストの User-Agent および Accept-Language HTTP ヘッダーの値がキャッシュキーに追加されます。http://aliyundoc.com/a/b/image.jpg へのリクエストで、User-Agent: Mozilla/5.0 (Linux; X11) および Accept-Language: en が含まれている場合、結果として得られるキャッシュキーは http://aliyundoc.com/a/b/image.jpgMozilla/5.0(Linux;X11)en です。HTTP Header

    カスタム変数

    例 1

    変数名は language、ソースは リクエストヘッダー、ソースフィールド名は Accept-Language、マッチングパターンは ([%w]+),([%w]+)、変数式は $1aa です。Custom Variables

    クライアントが http://aliyundoc.com/a/b/image.jpg へのリクエストを送信し、HTTP リクエストヘッダーに Accept-Language=en,ch が含まれている場合、マッチングパターンは en にマッチし、変数式内の $1 に割り当てられます。その後、変数式により aa が追加され、値 enaa が生成されます。この値は language というエイリアスで URL に追加され、最終的なキャッシュキーが生成されます：http://aliyundoc.com/a/b/image.jpgenaa。

    説明

    変数式において、$n はマッチングパターン内の n 番目の括弧ペアでキャプチャされた内容を表します。たとえば、例 1 では入力が Accept-Language=en,ch でマッチングパターンが ([%w]+),([%w]+) の場合、$1=en、$2=ch となります。

    例 2

    変数名は expired、ソースは リクエスト Cookie、ソースフィールド名は a、マッチングパターンは [%w]+:(.*)、変数式は $1 です。Custom variable

    クライアントが http://aliyundoc.com/a/b/image.jpg へのリクエストを送信し、Cookie に Cookie a=expired_time:12635187 が含まれている場合、マッチングパターンは 12635187 にマッチします。この値は変数式内の $1 に割り当てられ、expired というエイリアスで URL に追加され、最終的なキャッシュキーが生成されます：http://aliyundoc.com/a/b/image.jpg12635187。

    例 3

    URI ルールとカスタム変数の両方を構成します。

    • URI：

      /abc/.*/abc に一致するすべてのリクエスト URI を /abc に書き換えます。示例三

    • カスタム変数：

      変数名は testname、ソースは パス、マッチングパターンは /abc/xyz/(.*)、変数式は $1 です。Example 3

      URL が http://aliyundoc.com/abc/xyz/abc/image.jpg のクライアントリクエストの場合、キャッシュキーは URI 構成に基づいて http://aliyundoc.com/abc/image.jpg に正規化されます。その後、カスタム変数構成に基づき、この URL が /abc/xyz/(.*) にマッチし、この時点で $1 に値 abc が割り当てられ、キャッシュキーに追加されて最終的なキャッシュキーが生成されます：http://aliyundoc.com/abc/image.jpgabc。これにより、2 つのルールを組み合わせてより複雑なキャッシュロジックを実装できます。

      キャッシュキーのカスタム変数がマッチしなかった場合、変数式 $1 はキャッシュキーに連結されません。