オリジンキャッシュコントロール
オリジンキャッシュコントロールはCloudflareの機能です。エンタープライズ顧客のウェブサイトで有効にすると、Cloudflareはオリジンサーバーから受け取ったCache-Controlディレクティブを厳密に尊重する必要があることを示します。無料、プロ、ビジネスの顧客は、この機能がデフォルトで有効になっています。
オリジンサーバーからのHTTPレスポンスに含まれるCache-Controlディレクティブは、Cloudflareのような中間サービスに特定のキャッシング指示 ↗を提供します。
オリジンキャッシュコントロール機能が有効な場合、オリジンサーバーのレスポンスに存在するCache-Controlディレクティブは指定された通りに従われます。たとえば、レスポンスに3,600秒のmax-ageディレクティブが含まれている場合、Cloudflareはその期間リソースをキャッシュし、再度オリジンサーバーを確認して更新を行います。
Cloudflareのキャッシュルールを使用すると、ユーザーはオリジンサーバーのCache-ControlヘッダーやCloudflareによって設定されたデフォルトポリシーを追加または上書きすることができます。
以下のセクションでは、次のことについて詳しく説明します：
- 最も一般的な
Cache-Controlディレクティブ。 - オリジンキャッシュコントロールを有効にする方法。
Cache-Controlディレクティブに対するオリジンキャッシュコントロールの動作。- 他のCloudflare製品が
Cache-Controlディレクティブとどのように相互作用するか。
Cache-Controlヘッダーにはいくつかのディレクティブを含めることができ、ディレクティブはリソースを誰がキャッシュできるか、またそのリソースが更新されるまでどのくらいの期間キャッシュされるべきかを指示します。
複数のディレクティブが一緒に渡される場合、各ディレクティブはカンマで区切られます。ディレクティブが引数を取る場合、それはディレクティブの後に等号で区切られて続きます。たとえば：max-age=86400。
ディレクティブは、キャッシュ可能性、有効期限、再検証、およびその他の4つのグループに分けることができます。
キャッシュ可能性は、リソースがキャッシュに入るべきかどうかを指し、以下のディレクティブはリソースのキャッシュ可能性を示します。
public— どのキャッシュでもレスポンスを保存できることを示します。たとえレスポンスが通常はキャッシュ不可であったり、プライベートキャッシュ内でのみキャッシュ可能であったりしても。private— レスポンスメッセージが単一のユーザー（ブラウザキャッシュなど）向けであり、Cloudflareや企業プロキシのような共有キャッシュによって保存されるべきではないことを示します。no-store— クライアントやプロキシキャッシュなど、どのキャッシュも即時のリクエストまたはレスポンスのいずれかの部分を保存してはならないことを示します。
有効期限は、リソースがキャッシュにどのくらいの期間残るべきかを指し、以下のディレクティブはリソースがキャッシュにどのくらいの期間留まるかに影響します。
max-age=seconds— 指定された秒数を超えた場合、レスポンスは古くなったことを示します。年齢は、アセットがオリジンサーバーから提供されてからの秒数として定義されます。seconds引数は引用符なしの整数です。s-maxage=seconds— 共有キャッシュ内では、このディレクティブによって指定された最大年齢が、max-ageディレクティブまたはExpiresヘッダーフィールドによって指定された最大年齢を上書きすることを示します。s-maxageディレクティブは、プロキシ再検証レスポンスディレクティブの意味も含みます。ブラウザはs-maxageを無視します。no-cache— レスポンスは、オリジンサーバーでの成功した検証なしに、後続のリクエストを満たすために使用できないことを示します。これにより、オリジンサーバーは、キャッシュがオリジンを使用してリクエストを満たすことを防ぐことができます。たとえキャッシュが古いレスポンスを送信するように設定されていてもです。
HTTP Expiresヘッダーがオリジンサーバーで設定されていることを確認し、RFC 2616 ↗で定められたようにグリニッジ標準時（GMT）を使用してください。
再検証は、リソースが期限切れになったときにキャッシュがどのように動作するかを決定し、以下のディレクティブは再検証の動作に影響を与えます。
must-revalidate— リソースが古くなった場合、キャッシュ（クライアントまたはプロキシ）は、オリジンサーバーでの成功した検証なしに、後続のリクエストを満たすためにレスポンスを使用してはならないことを示します。proxy-revalidate—must-revalidateレスポンスディレクティブと同じ意味を持ちますが、プライベートクライアントキャッシュには適用されません。stale-while-revalidate=seconds— HTTPレスポンスに存在する場合、キャッシュはリソースが期限切れになった後、指定された秒数までそのレスポンスを提供できることを示します。Always Onlineが有効な場合、stale-while-revalidateおよびstale-if-errorディレクティブは無視されます。このディレクティブは、Cache APIメソッドcache.matchまたはcache.putを使用する際にはサポートされていません。詳細については、WorkerのCache APIドキュメントを参照してください。stale-if-error=seconds— エラーが発生した場合、キャッシュされた古いレスポンスをリクエストを満たすために使用できることを示します。他の新鮮さ情報に関係なく。この動作を避けるには、オリジンから返されたオブジェクトにstale-if-error=0ディレクティブを含めてください。このディレクティブは、Cache APIメソッドcache.matchまたはcache.putを使用する際にはサポートされていません。詳細については、WorkerのCache APIドキュメントを参照してください。
stale-if-errorディレクティブは、Always Onlineが有効な場合や、明示的なプロトコル内ディレクティブが渡された場合には無視されます。明示的なプロトコル内ディレクティブの例には、no-storeまたはno-cache cacheディレクティブ、must-revalidateキャッシュレスポンスディレクティブ、または適用可能なs-maxageまたはproxy-revalidateキャッシュレスポンスディレクティブが含まれます。
キャッシュの動作に影響を与える追加のディレクティブは以下に示されています。
no-transform— 中間者がキャッシュを実装しているかどうかに関係なく、ペイロードを変換してはならないことを示します。vary— Cloudflareはキャッシュの決定においてvary値を考慮しません。それにもかかわらず、画像のためのVaryが設定されている場合や、varyヘッダーがvary: accept-encodingである場合には、vary値が尊重されます。immutable— クライアントに対して、レスポンスボディは時間とともに変わらないことを示します。リソースが期限切れでない場合、サーバー上で変更されていません。ユーザーは、ページを明示的に更新しても、更新を確認するために条件付き再検証リクエスト（If-None-MatchやIf-Modified-Sinceなど）を送信すべきではありません。このディレクティブは、Cloudflareのようなパブリックキャッシュには影響を与えませんが、ブラウザの動作を変更します。
オリジンキャッシュコントロールを有効にすると、CloudflareはRFC 7234 ↗を厳密に遵守することを目指します。エンタープライズ顧客は、Cloudflareがこの動作を遵守するかどうかを選択する能力があり、ダッシュボードのキャッシュルールやAPIを介して、ウェブサイトのオリジンキャッシュコントロールを有効または無効にできます。無料、プロ、ビジネスの顧客は、このオプションがデフォルトで有効になっており、無効にすることはできません。
以下のセクションでは、オリジンキャッシュコントロールを有効または無効にしたときのディレクティブと動作条件について説明します。
以下の表は、オリジンキャッシュコントロールが無効な場合と有効な場合のディレクティブとその動作を示しています。
ディレクティブ | オリジンキャッシュコントロール無効時の動作 | オリジンキャッシュコントロール有効時の動作 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
s-maxage=0 | キャッシュしません。 | キャッシュし、常に再検証します。 | ||||||||||||
max-age=0 | キャッシュしません。 | キャッシュし、常に再検証します。 | ||||||||||||
no-cache | キャッシュしません。 | キャッシュし、常に再検証します。古いレスポンスは提供しません。 | ||||||||||||
no-cache=<headers> | キャッシュしません。 |
| ||||||||||||
Private=<headers> | キャッシュしません。 |
| ||||||||||||
must-revalidate | キャッシュディレクティブは無視され、古いレスポンスが提供されます。 | 古いレスポンスは提供されません。CDNとブラウザの両方で再検証が必要です。 | ||||||||||||
proxy-revalidate | キャッシュディレクティブは無視され、古いレスポンスが提供されます。 | 古いレスポンスは提供されません。CDNでは再検証が必要ですが、ブラウザでは必要ありません。 | ||||||||||||
no-transform | (un)Gzip、Polish、メールフィルターなどが行われる可能性があります。 | 本文は変換されません。 | ||||||||||||
s-maxage=delta, delta>1 |
|
| ||||||||||||
immutable | 下流にプロキシされません。 | 下流にプロキシされます。ブラウザ向けであり、キャッシングプロキシには影響しません。 |
特定のシナリオも、オリジンキャッシュコントロールの動作に影響を与えます。
条件 | オリジンキャッシュコントロール無効時の動作 | オリジンキャッシュコントロール有効時の動作 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| コンテンツはキャッシュされる可能性があります。 | コンテンツは、 | ||||||||||||
| ログでは、 | ログでは、 | ||||||||||||
オリジンレスポンスに | コンテンツは、 | コンテンツはキャッシュされません。 | ||||||||||||
ブラウザキャッシュTTLが設定されている。 |
| オリジンが |
以下の例を確認して、特定のキャッシング動作を制御するためにCache-Controlヘッダーで使用するディレクティブを学びましょう。
静的アセットをキャッシュする。
Cache-Control: public, max-age=86400
秘密のアセットが決してキャッシュされないようにする。
Cache-Control: no-store
ブラウザではキャッシュするが、プロキシキャッシュではキャッシュしない。
Cache-Control: private, max-age=3600
クライアントとプロキシキャッシュでアセットをキャッシュするが、提供時に再検証を優先する。
Cache-Control: public, no-cache
プロキシキャッシュでアセットをキャッシュするが、提供時にプロキシによる再検証を要求する。
Cache-Control: public, no-cache, proxy-revalidate または Cache-Control: public, s-maxage=0
プロキシキャッシュでアセットをキャッシュするが、提供時に任意のキャッシュによる再検証を要求する。
Cache-Control: public, no-cache, must-revalidate
アセットをキャッシュするが、プロキシがそれを変更しないようにする。
Cache-Control: public, no-transform
この設定は、元のペイロードが未圧縮で提供された場合、gzipやbrotli圧縮などの変換を無効にします。
再検証を伴うアセットをキャッシュするが、オリジンサーバーに到達できない場合は古いレスポンスを許可する。
Cache-Control: public, max-age=3600, stale-if-error=60
この設定では、Cloudflareはキャッシュに3600秒（1時間）存在した後、オリジンサーバーでコンテンツの再検証を試みます。サーバーが適切な再検証レスポンスを返さずにエラーを返した場合、Cloudflareはリソースの有効期限を超えて1分間古いリソースを提供し続けます。
Cloudflareと訪問者のブラウザで異なる時間のアセットをキャッシュする。
Cache-Control: public, max-age=7200, s-maxage=3600
アセットをキャッシュし、アセットが再検証されている間に提供します。
Cache-Control: max-age=600, stale-while-revalidate=30
この設定は、アセットが600秒間新鮮であることを示しています。アセットは、初回の同期再検証が試みられている間、同じリソースへの並行リクエストのために最大30秒間古い状態で提供されることができます。
このセクションでは、他のCloudflare機能がCache-Controlディレクティブとどのように相互作用するかについての詳細を提供します。
Edge Cache TTL キャッシュルールはs-maxageを上書きし、存在する場合は再検証ディレクティブを無効にします。CloudflareでOrigin Cache Controlが有効になっている場合、元のCache-Controlヘッダーは、Edge Cache TTLの上書きが存在しても、当社のエッジから下流に渡されます。そうでない場合、CloudflareでOrigin Cache Controlが無効になっていると、CloudflareがOrigin Cache Controlを上書きします。
Browser Cache TTL キャッシュルールは、通常、訪問者のブラウザに下流に渡されるmax-age設定を上書きします。
Polish は、no-transformディレクティブが存在する場合に無効になります。
no-transformディレクティブが存在する場合、圧縮は無効になります。オリジンから取得された元のアセットが圧縮されている場合、訪問者には圧縮された状態で提供されます。元のアセットが非圧縮の場合、圧縮は適用されません。