キャッシュされないレスポンスを調査する

キャッシュされる想定の URL が毎回オリジンから返される場合は、cf-cache-status レスポンスヘッダーで、Cloudflare がどのキャッシュ判断をしたかを特定します。URL を取得し、ヘッダーを確認して、表示された値に対応する節へ進みます。

DYNAMIC — Cloudflare は、キャッシュを調べる前に、リクエストがキャッシュ対象外と判断しました。DYNAMIC — リクエストがキャッシュ対象外を参照してください。
BYPASS — Cloudflare はレスポンスをキャッシュする準備がありましたが、オリジンのレスポンスまたは設定が妨げました。BYPASS — オリジンレスポンスがキャッシュ不可を参照してください。
同じクライアントからの連続した複数リクエストで MISS — レスポンスはキャッシュ対象ですが、キャッシュヒットしません。繰り返しの MISS — キャッシュ対象だがキャッシュにないを参照してください。

ほかのステータスは、一覧としてキャッシュレスポンスを参照してください。

始める前に

直近の Purge Everything、URL 指定のパージ、プレフィックス指定のパージ、タグ指定のパージ、ホスト名指定のパージはキャッシュを消去します。各データセンターでの次のリクエストがキャッシュを埋め直し、その後のリクエストが HIT になる前に MISS を返します。最近パージした場合は、キャッシュが埋まるまで待ってから続けてください。

DYNAMIC — リクエストがキャッシュ対象外

Cloudflare はリクエスト時点で、キャッシュを調べる前に「キャッシュしない」と判断しました。よくある原因は次のとおりです。

ファイル拡張子がデフォルトでキャッシュされるファイル拡張子の一覧にない — たとえば .html や JSON API レスポンス — かつ、キャッシュを有効にするルールもない。Eligible for cache を Yes にした Cache Rule を追加します。
ルールが Cloudflare にキャッシュのバイパスを指示している。 Bypass cache 設定の Cache Rule、またはレガシーの Cache Level: Bypass の Configuration Rule や Page Rule が URL に一致していないか確認します。どのルールが適用されるかは Rule Trace で確認できます。
リクエストメソッドが GET または HEAD ではない。 Cloudflare がキャッシュするのは、この 2 つのメソッドだけです。
ゾーンで Development Mode が有効になっている。 Development Mode は 3 時間キャッシュを停止し、すべてのレスポンスで DYNAMIC を返します。

リクエストがキャッシュ対象になると、その後のレスポンスはレスポンス時点の判断（HIT、MISS、BYPASS など）を反映します。

BYPASS — オリジンレスポンスがキャッシュ不可

リクエストはキャッシュ対象でしたが、オリジンのレスポンスまたは設定により、Cloudflare は格納できませんでした。よくある原因は次のとおりです。

レスポンスが、ご利用プランのキャッシュ可能な最大ファイルサイズを超えている。 オブジェクトを小さいアセットに分割するか、上限の高いプランへ移ります。R2 はオリジンストレージの代替です。CDN のキャッシュ可能なサイズ上限は上がりません。
オリジンが Cloudflare-CDN-Cache-Control または CDN-Cache-Control ヘッダーで no-store または単独の private を返した。 Cloudflare はこれらのヘッダーを Cache-Control より先に評価します。優先順位は Cloudflare-CDN-Cache-Control > CDN-Cache-Control > Cache-Control です。オリジンが Cache-Control: public, max-age=3600 と CDN-Cache-Control: no-store を同時に返すと BYPASS になります。Cloudflare は Cloudflare-CDN-Cache-Control をクライアントへ転送しないため、レスポンスには見えません。CDN-Cache-Control ヘッダーなしで BYPASS になる場合は、オリジンが実際に送った内容を確認するか、オリジンでヘッダーを外して再テストしてください。オリジンの cache-control を無視する Edge Cache TTL 設定の Cache Rule は、どちらのディレクティブも上書きします。優先順位のルールは CDN-Cache-Control を参照してください。
Cloudflare-CDN-Cache-Control または CDN-Cache-Control の no-cache、max-age=0、s-maxage=0 では BYPASS になりません。 最初のリクエストは MISS、その後は REVALIDATED または EXPIRED になります。
オリジンが Cache-Control: no-store または単独の private を返した。 これらのディレクティブは、どちらの Origin Cache Control モードでも、デフォルトではキャッシュを妨げます。例外は 2 つです。フィールド名付きの Cache-Control: private="<header>" はキャッシュ対象のままです。Cloudflare は指定したヘッダーだけを取り除きます。また、オリジンの cache-control を無視する Edge TTL の Cache Rule（Edge TTL → Ignore cache-control header and use this TTL または Status code TTL）は、どちらのディレクティブも上書きします。そのため、no-store とその Edge TTL 設定があるレスポンスはキャッシュされます。
オリジンが Cache-Control: no-cache、max-age=0、または s-maxage=0 を返し、Origin Cache Control が無効（Enterprise プランのデフォルト）である。Origin Cache Control が有効な場合（Free、Pro、Business プランのデフォルト）は、これらのディレクティブにより Cloudflare はレスポンスをキャッシュして再検証するため、REVALIDATED または EXPIRED になります。no-store と no-cache ディレクティブの理解と Conditions の表を参照してください。
オリジンが Set-Cookie ヘッダーを返した。 デフォルトでは、Cloudflare は Set-Cookie を含むレスポンスをキャッシュしません。レスポンスをキャッシュするには、次のいずれかを使います。
- Cache Rule で、Edge TTL → Ignore cache-control header and use this TTL または Status code TTL を使い、明示的な Edge TTL を設定します。Cloudflare はオリジンのディレクティブを無視し、Set-Cookie を取り除いてレスポンスをキャッシュします。
- オリジンに Cache-Control: private="Set-Cookie" または no-cache="Set-Cookie" を返させます。Cloudflare は指定したヘッダーを取り除き、残りをキャッシュします。
- Response Header Modification Transform Rule で、キャッシュ判断の前に Set-Cookie を取り除きます。
- Origin Cache Control が無効な Enterprise プランでは、Cloudflare は Set-Cookie を取り除き、デフォルトのキャッシュレベルでレスポンスをキャッシュします。Cache Level: Cache Everything の Page Rule、または Eligible for cache を Yes にした Cache Rule — どちらも明示的な Edge TTL なし — はこの動作を上書きし、BYPASS を返します。
全体の対応表は Set-Cookie レスポンスヘッダーとキャッシュの関係を参照してください。
オリジンが Vary: * を返した。 この値は、ほかの設定に関係なく常にキャッシュをバイパスします。
リクエストに Authorization ヘッダーがあり、Origin Cache Control が有効（Free、Pro、Business プランのデフォルト）である。このモードでは、Cache-Control に public、s-maxage、または must-revalidate も含まれる場合だけキャッシュ対象になります。Origin Cache Control が無効な Enterprise プランでは、Authorization だけではキャッシュを妨げません。

このステータスの定義は BYPASS を参照してください。

繰り返しの MISS — キャッシュ対象だがキャッシュにない

各データセンターでの最初のリクエストの MISS は想定どおりです。そのリクエストがキャッシュを投入します。同じ URL が連続リクエストで MISS を返し続ける場合は、次のいずれかが起きています。

キャッシュキーのばらつき

Cloudflare はデフォルトで、オリジンのスキーム、ホスト、パス、クエリ文字列からキャッシュキーを組み立てます。設定すれば、Cookie、ヘッダー、デバイスタイプも寄与します。キャッシュキーのスキームは、クライアントが使ったスキームではなく、Cloudflare がオリジンへ到達するときに使うスキームです。オリジンスキームが 1 つのゾーンでは、HTTP と HTTPS のクライアントリクエストは同じキャッシュエントリから返されます。

実際のクライアントリクエストごとにキーが違うと、キャッシュは繰り返しを見ず、毎回 MISS になります。よくあるパターンは次のとおりです。

リクエストごとに変わるクエリパラメーター — セッション ID、タイムスタンプ、utm_* などのマーケティングタグ。デフォルトでは、一意のクエリ文字列ごとに別のキャッシュエントリになります。Cache Rules または Cache Key Settings で、リクエストごとに値が変わるパラメーターを除外または無視します。ソートはパラメーターの順序を正規化するだけです。値が違う場合ではなく、パラメーターの順序だけが違うときに使います。
カスタム Cache Key に、ユーザーごとに値が変わる Cookie またはヘッダーが含まれる。 カスタム Cache Key の作成の節では、カスタムキーは「キャッシュヒット率を下げ、キャッシュのシャーディングを招くことがある」と注意しています。これが同じ動作です。
デバイスタイプ別キャッシュが、想定と違う分類をする。 特にボットや、珍しい User-Agent のクライアントで起きやすいです。
Cache Rules の Vary がヘッダー向けに設定され、オリジンがそのヘッダーを Vary レスポンスヘッダーに列挙し、アクションが normalize または passthrough である。各レスポンスバリアントは別のキーで格納されます。ヘッダーのカーディナリティが高い場合 — たとえば正規化されていない Accept-Language やユーザーごとのヘッダー — 実効ヒット率は下がります。bypass アクションはキャッシュを完全に防ぎます。

同一のリクエスト 2 件は同じキャッシュキーになり、ばらつきは見えません。切り分けには Rule Trace で、その URL に適用されたキャッシュキー設定と Vary アクションを確認し、実際のクライアントリクエスト間で違う属性（クエリ文字列、Cookie、ヘッダー、デバイスタイプ）と突き合わせます。

退避と低トラフィックのアセット

低トラフィックのアセットは、次のリクエストが届く前にキャッシュから退避されることがあります。同じデータセンターから同じ URL への連続 2 リクエストがどちらも MISS なら、Tiered Cache または Cache Reserve を有効にして、ロングテールのコンテンツをより長く保持します。

リクエストが別の Cloudflare データセンターに届くと、それぞれが最初のリクエストの MISS になります。同じデータセンターからのレスポンスかどうかを確認するには、データセンターコード（cf-ray ヘッダーの末尾 3 文字）を比較します。別のクライアントネットワークでも同じデータセンターに届くことがあるため、ネットワークの変更だけでは別の地点とは限りません。

レスポンスがキャッシュに届くことを確認する

設定を調整したあと、同じクライアントから URL を 2 回リクエストし、設定どおりの結果かを確認します。

新しい、正の Edge TTL: cf-cache-status: HIT と、後続リクエストで増える Age ヘッダー。Age は、Tiered Cache 経由で上位ティアからローカルデータセンターのキャッシュを埋めた最初のリクエストには付きません。HIT は上位ティアを反映しますが、ローカルデータセンターはまだキャッシュから返していません。後続リクエストには Age が付き、Tiered Cache では値がすでに大きいことがあります。Cloudflare のネットワーク全体のキャッシュにおけるオブジェクトの経過時間を表すためです。
オリジンが Cache-Control: no-cache を返し、Origin Cache Control が有効: オリジンがキャッシュ済みコピーが未変更だと確認した場合は cf-cache-status: REVALIDATED、オリジンが新しいコンテンツを返した場合は EXPIRED。どちらもレスポンスがキャッシュされていることを示します。must-revalidate だけでは、毎回の再検証は強制されません。鮮度 TTL の期限後に古いコンテンツを返すことだけを防ぎます。

これらの確認のあとでもレスポンスが MISS または BYPASS の場合は、2 件の完全なレスポンス（リクエストヘッダーとレスポンスヘッダー、cf-ray 値を含む）を取得し、サポートケースを開いてください。Cloudflare ネットワーク上でリクエストを追跡するには、cf-ray 値が必要です。