Origin Cache Control は Cloudflare の機能です。Enterprise のお客様のサイトで有効にすると、オリジンサーバーから受け取った Cache-Control ディレクティブを Cloudflare が厳密に尊重することを示します。Free、Pro、Business のお客様では、この機能はデフォルトで有効です。
オリジンサーバーからの HTTP レスポンスにある Cache-Control ディレクティブは、Cloudflare のような中間サービスへ具体的な キャッシュ指示 ↗ を渡します。
Origin Cache Control が有効なとき、オリジンサーバーのレスポンスにある Cache-Control ディレクティブは、指定どおりに従われます。たとえばレスポンスに 3,600 秒の max-age ディレクティブがある場合、Cloudflare はその期間リソースをキャッシュしてから、更新確認のため再びオリジンサーバーを確認します。
Cloudflare の Cache Rules では、オリジンサーバーの Cache-Control ヘッダーや、Cloudflare が設定する デフォルトポリシー を補完または上書きできます。
以降のセクションでは、次を扱います。
- よく使う
Cache-Controlディレクティブ。 - Origin Cache Control の有効化方法。
- Origin Cache Control と
Cache-Controlディレクティブの動作。 - ほかの Cloudflare 製品と
Cache-Controlディレクティブの関係。
Cache-Control ヘッダーには複数のディレクティブを含められます。ディレクティブは、誰がリソースをキャッシュできるか、更新が必要になるまでどのくらいキャッシュできるかを決めます。
複数のディレクティブを一緒に渡す場合、各ディレクティブはカンマで区切ります。ディレクティブが引数を取る場合は、イコール記号のあとに続けます。例: max-age=86400。
ディレクティブは 4 つのグループに分けられます。キャッシュ可能性、有効期限、再検証、その他 です。
キャッシュ可能性は、リソースをキャッシュに入れるべきかどうかを指します。次のディレクティブが、リソースのキャッシュ可能性を示します。
public— 通常はキャッシュ不可、またはプライベートキャッシュでのみキャッシュ可能なレスポンスでも、任意のキャッシュがレスポンスを保存できることを示します。private— レスポンスメッセージがブラウザーキャッシュなど単一ユーザー向けであり、Cloudflare や社内プロキシのような共有キャッシュに保存してはならないことを示します。no-store— クライアントやプロキシキャッシュなど、任意のキャッシュが、直後のリクエストまたはレスポンスのいずれの部分も保存してはならないことを示します。
有効期限は、リソースをキャッシュに残すべき時間を指します。次のディレクティブが、リソースがキャッシュに残る時間に影響します。
max-age=seconds— 経過時間が指定秒数を超えると、レスポンスが古い（stale）ことを示します。経過時間は、アセットがオリジンサーバーから配信されてからの秒数です。seconds引数は引用符なしの整数です。s-maxage=seconds— 共有キャッシュでは、このディレクティブで指定した最長期間が、max-ageディレクティブまたはExpiresヘッダーフィールドで指定した最長期間を上書きすることを示します。s-maxageディレクティブは、proxy-revalidateレスポンスディレクティブの意味も含みます。ブラウザーは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ではサポートされません。詳細は Cache API の Workers ドキュメント を参照してください。
stale-if-error=<seconds>— エラーが起きたとき、ほかの鮮度情報に関係なく、キャッシュ済みの古いレスポンスでリクエストを満たしてよいことを示します。この動作を避けるには、オリジンから返すオブジェクトにstale-if-error=0ディレクティブを含めます。このディレクティブは、Cache API のcache.matchまたはcache.putではサポートされません。詳細は Cache API の Workers ドキュメント を参照してください。
Always Online が有効な場合、またはプロトコル上の明示的なディレクティブが渡された場合、stale-if-error ディレクティブは無視されます。プロトコル上の明示的なディレクティブの例は、no-store または no-cache cache ディレクティブ、must-revalidate cache-response-directive、適用される s-maxage または proxy-revalidate cache-response-directive です。
キャッシュ動作に影響する追加ディレクティブは、次のとおりです。
no-transform— キャッシュを実装しているかどうかに関係なく、中間者がペイロードを変換してはならないことを示します。vary— デフォルトでは、Cloudflare はキャッシュ判定で vary 値を考慮しません。vary 値が尊重されるのは、Cache Rules の Vary 設定 を構成した場合、Vary for Images を構成した場合、および vary ヘッダーがvary: accept-encodingの場合です。immutable— レスポンス本文が時間とともに変わらないことをクライアントに示します。期限切れでなければ、サーバー上のリソースは変わっていません。ユーザーがページを明示的に再読み込みしても、更新確認のための条件付き再検証リクエスト（If-None-MatchやIf-Modified-Sinceなど）を送るべきではありません。このディレクティブは Cloudflare のような公開キャッシュには影響しませんが、ブラウザーの動作は変わります。
Cache-Control: no-store と Cache-Control: no-cache のディレクティブは混同されがちです。とくに、ブラウザーキャッシュや Back-Forward Cache ↗（BFCache）への影響についてです。
- ブラウザーと中間者（CDN など）の両方に、いかなる場合もレスポンスのコピーを保存しないよう指示します。
- レスポンスはディスクにもメモリにも書き込まれないため、ブラウザーは毎回取得し直す必要があります。
- 多くのブラウザーでは、
no-storeは BFCache を無効にします。BFCache からページを復元するには、ブラウザーがページのメモリ状態のコピーを保持する必要があり、「保存しない」ディレクティブと矛盾するためです。 - このディレクティブは、銀行アプリ、個人情報、セキュアなダッシュボードなど、機密性の高い、または動的なデータに使います。
- レスポンスの保存（ブラウザーと中間キャッシュの両方）は許可しますが、使う前にオリジンサーバーでの再検証が必要です。
- コンテンツを常に最新にしつつ、BFCache やほかの性能最適化を使える可能性があります。
- このディレクティブは、頻繁に変わるが機密ではなく、再ダウンロードより検証の方が速く配信できるデータに使います。
Origin Cache Control の有効・無効時のこれらのディレクティブの動作は、ディレクティブ セクションを参照してください。
Origin Cache Control を有効にすると、Cloudflare は RFC 7234 ↗ に厳密に従うことを目指します。Enterprise のお客様は、ダッシュボード または API の Cache Rules で、サイトごとに Origin Cache Control を有効または無効にできます。Free、Pro、Business のお客様ではこのオプションはデフォルトで有効で、無効にはできません。
次のセクションでは、Origin Cache Control の有効・無効に関連するディレクティブと条件を扱います。
次の表は、Origin Cache Control が無効なときと有効なときの、各ディレクティブの動作です。
| ディレクティブ | Origin Cache Control 無効時の動作 | Origin Cache Control 有効時の動作 |
|---|---|---|
s-maxage=0 |
キャッシュしません。 | キャッシュし、常に再検証します。 |
max-age=0 |
キャッシュしません。 | キャッシュし、常に再検証します。 |
no-cache |
キャッシュしません。 | キャッシュし、常に再検証します。古いコンテンツは配信しません。 |
no-cache=<headers> |
キャッシュしません。 | no-cache=<headers> で挙げたヘッダーがなければキャッシュします。no-cache=<headers> で挙げたヘッダーのいずれかがあれば、常に再検証します。 |
Private=<headers> |
キャッシュしません。 | Private=<headers> ディレクティブで挙げた <headers> 値はキャッシュしません。 |
must-revalidate |
キャッシュディレクティブは無視され、古いコンテンツが配信されます。 | 古いコンテンツは配信しません。CDN とブラウザーの両方で再検証が必要です。 |
proxy-revalidate |
キャッシュディレクティブは無視され、古いコンテンツが配信されます。 | 古いコンテンツは配信しません。CDN では再検証が必要ですが、ブラウザーでは不要です。 |
no-transform |
Gzip の（解）圧縮、Polish、メールフィルターなどを行うことがあります。 | 本文を変換しません。 |
s-maxage=delta, delta>1 |
max-age と同じです。 |
Max-age と proxy-revalidate。 |
immutable |
下流へプロキシしません。 | 下流へプロキシします。ブラウザー向けであり、キャッシュプロキシには影響しません。 |
no-store |
キャッシュしません。 | キャッシュしません。 |
特定の状況でも、Origin Cache Control の有効・無効時の動作が変わります。
条件 | Origin Cache Control 無効時の動作 | Origin Cache Control 有効時の動作 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| コンテンツはキャッシュされることがあります。 |
| ||||||||||||
| ログでは | ログでは | ||||||||||||
オリジンレスポンスに |
| コンテンツはキャッシュされません。 | ||||||||||||
Browser Cache 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
この設定では、コンテンツがキャッシュに入ってから 3600 秒（1 時間）後に、Cloudflare はオリジンサーバーで再検証を試みます。サーバーが適切な再検証レスポンスではなくエラーを返した場合、Cloudflare はリソースの期限切れから合計 1 分間、古いリソースの配信を続けます。
Cloudflare 上と訪問者のブラウザーで、異なる時間だけアセットをキャッシュする。
Cache-Control: public, max-age=7200, s-maxage=3600
アセットをキャッシュし、再検証中も配信する。
Cache-Control: max-age=600, stale-while-revalidate=30
この設定は、アセットが 600 秒間新しい（fresh）ことを示します。Cloudflare がバックグラウンドでオリジンと再検証しているあいだ、アセットはさらに最大 30 秒、古い状態で配信できます。詳細は 再検証 を参照してください。
このセクションでは、ほかの Cloudflare 機能が Cache-Control ディレクティブとどう関わるかを説明します。
Edge Cache TTL の Cache Rules は s-maxage を上書きし、再検証ディレクティブがある場合は無効にします。Cloudflare で Origin Cache Control が有効なとき、Edge Cache TTL の上書きがあっても、元の Cache-Control ヘッダーはエッジから下流へ渡されます。一方、Cloudflare で Origin Cache Control が無効なときは、Cloudflare が Origin Cache Control を上書きします。
Browser Cache TTL の Cache Rules は、エッジから下流（通常は訪問者のブラウザー）へ渡される max-age 設定を上書きします。
no-transform ディレクティブがあるとき、Polish は無効になります。
no-transform ディレクティブがあるとき、圧縮は無効になります。オリジンから取得した元のアセットが圧縮済みなら、訪問者にも圧縮されたまま配信します。元のアセットが非圧縮なら、圧縮は適用しません。
no-transform ディレクティブがあるとき、JavaScript Detections の挿入は無効になります。影響を受けるリクエストでは、cf.bot_management.js_detection.passed フィールドは missing になります。