キャッシュキー
キャッシュキーは、Cloudflareがキャッシュ内のファイルを識別するために使用する識別子であり、キャッシュキーのテンプレートは特定のHTTPリクエストの識別子を定義します。
デフォルトのキャッシュキーには以下が含まれます:
- 完全なURL:
- scheme - HTTPまたはHTTPSのいずれか。
- host - 例えば、
www.cloudflare.com - クエリ文字列を含むURI - 例えば、
/logo.jpg
- クライアントから送信されたOriginヘッダー(CORSサポート用)。
x-http-method-override、x-http-method、およびx-method-overrideヘッダー。x-forwarded-host、x-host、x-forwarded-scheme(httpまたはhttpsでない場合)、x-original-url、x-rewrite-url、およびforwardedヘッダー。
カスタムキャッシュキーを使用すると、任意のリソースのキャッシュ可能性設定を正確に設定できます。これにより、より多くの制御が可能になりますが、キャッシュヒット率が低下し、キャッシュのシャーディングが発生する可能性があります:
- Cloudflareダッシュボード ↗にログインし、アカウントとドメインを選択します。
- キャッシング > キャッシュルールに移動します。
- ルールを作成を選択します。
- 受信リクエストが一致する場合の下で、ルール式を定義します。
- 次にの下で、キャッシュの適格性セクションでキャッシュの対象を選択します。
- ルールにキャッシュキー設定を追加し、適切なクエリ文字列設定を選択します。
- ヘッダー、クッキー、ホスト、およびユーザーの設定も選択できます。
- ルールを保存して展開するには、展開を選択します。ルールを展開する準備ができていない場合は、下書きとして保存を選択します。
キャッシュキーのテンプレートを変更する一般的な理由はいくつかあります。キャッシュキーのテンプレートを変更する理由は次のとおりです:
- キャッシュを断片化して、1つのURLが複数のファイルに保存されるようにする。例えば、URL内の特定のクエリ文字列に基づいて異なるファイルを保存するため。
- キャッシュを統合して、異なるHTTPリクエストが同じファイルに保存されるようにする。例えば、Cloudflareキャッシュキーによってデフォルトで追加されるOriginヘッダーを削除するため。
クエリ文字列を無視するキャッシュレベルは、URI内のクエリ文字列を含まないデフォルトのキャッシュキーのすべての要素を含むキャッシュキーを作成します。例えば、http://example.com/file.jpg?something=123へのリクエストとhttp://example.com/file.jpg?something=789へのリクエストは、この場合、同じキャッシュキーを持ちます。
以下のフィールドは、キャッシュキーのテンプレートを制御します。
クエリ文字列は、どのURLクエリ文字列パラメータがキャッシュキーに入るかを制御します。特定のクエリ文字列パラメータをincludeするか、該当するフィールドを使用してexcludeできます。クエリ文字列パラメータを含めると、そのクエリ文字列パラメータのvalueがキャッシュキーに使用されます。
URLがhttps://www.example.com/?foo=barのようにクエリ文字列fooを含めると、barがキャッシュキーに表示されます。includeまたはexcludeのいずれかが正確に1つ期待されます。
- すべてのクエリ文字列パラメータを含める(デフォルトの動作)には、include: ”*“を使用します。
- クエリ文字列を無視するには、exclude: ”*“を使用します。
- ほとんどのクエリ文字列パラメータを含めるが、いくつかを除外するには、excludeフィールドを使用し、他のクエリ文字列パラメータが含まれていると仮定します。
ヘッダーは、どのヘッダーがキャッシュキーに入るかを制御します。クエリ文字列と同様に、特定のヘッダーを含めるか、デフォルトのヘッダーを除外できます。
ヘッダーを含めると、そのヘッダーの値がキャッシュキーに含まれます。例えば、HTTPリクエストにX-Auth-API-key: 12345のようなHTTPヘッダーが含まれており、キャッシュキーのテンプレートにX-Auth-API-Keyヘッダーを含めると、12345がキャッシュキーに表示されます。
ヘッダーの実際の値を含めずに存在を確認するには、check_presenceオプションを使用します。
現在、Originヘッダーのみを除外できます。Originヘッダーは、明示的に除外されない限り常に含まれます。キャッシュキーにOriginヘッダー ↗を含めることは、CORS ↗を強制するために重要です。さらに、以下のヘッダーを含めることはできません:
- 高いカーディナリティを持ち、キャッシュのシャーディングのリスクがあるヘッダー
acceptaccept-charsetaccept-encodingaccept-datetimeaccept-languagerefereruser-agent
- キャッシュまたはプロキシ機能を再実装するヘッダー
connectioncontent-lengthcache-controlif-matchif-modified-sinceif-none-matchif-unmodified-sincerangeupgrade
- 他のキャッシュキー機能でカバーされるヘッダー
cookiehost
- Cloudflareに特有で、
cf-で始まるヘッダー(例:cf-ray) - カスタムキャッシュキーのテンプレートにすでに含まれているヘッダー(例:
origin)
ホストは、キャッシュキーに含めるホストヘッダーを決定します。
resolved: falseの場合、Cloudflareはオリジンに送信されるHTTPリクエストにHostヘッダーを含めます。resolved: trueの場合、Cloudflareはリクエストのorigin IPを取得するために解決されたHostヘッダーを含めます。このシナリオでは、Cloudflare Resolve Override機能が使用されている場合、Hostヘッダーは実際に送信されたヘッダーとは異なる場合があります。
query_stringやheaderと同様に、cookieはキャッシュキーに表示されるクッキーを制御します。クッキーの値を含めるか、特定のクッキーの存在を確認できます。
Cloudflareに特有のクッキーを含めることはできません。Cloudflareのクッキーは__cfで始まります(例:__cflb)。
ユーザー機能フィールドは、エンドユーザー(クライアント)に関する機能をキャッシュキーに追加します。
device_typeは、ユーザーエージェントに基づいてリクエストをmobile、desktop、またはtabletとして分類します。geoは、IPアドレスから派生したクライアントの国を含めます。langは、クライアントから送信されたAccept-Languageヘッダーに含まれる最初の言語コードを含めます。
| Free | Pro | Business | Enterprise | |
|---|---|---|---|---|
Availability | No | No | No | Yes |
プリフェッチ機能はカスタムキャッシュキーと互換性がありません。キャッシュルールを使用すると、カスタムキャッシュキーがすべてのアセットをキャッシュするために使用されます。ただし、プリフェッチは常にデフォルトのキャッシュキーを使用します。これにより、キーの不一致が発生します。