Cache Diagnostic

キャッシュ関連ヘッダーを横断して判定します。入力はサーバーへ送信しません。再検証やCDN差分の一次切り分けに使えます。

状態

ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。

使い方

レスポンスヘッダーを貼り付けて「診断」。Summaryで方針を把握し、必要なら個別Inspectへ進みます。

注意（このツール）

  • 判定は貼り付けたヘッダー範囲に基づきます。CDN設定や配信経路の実挙動は別途確認してください。
  • no-cache と no-store は意味が異なります。再検証可否と保存可否を分けて確認してください。

このページについて

何をするツール？

Cache-Control / Expires / Age / ETag / Last-Modified / Vary / Range をまとめて評価します。

切り分け手順（おすすめ）

  • Response Headers を貼り付け
  • Summary でキャッシュ方針を把握
  • 必要なら各 Inspect で詳細を確認

症状別チェック（よくある相談）

  • 「更新したのに反映されない」: max-age / immutable / バージョン付与を確認
  • 「毎回304にならない」: ETag / Last-Modified と If-* の対応を確認
  • 「CDNでだけ挙動が違う」: s-maxage / Age / Vary を確認
  • 「Range配信が不安定」: Accept-Ranges / Content-Range / 圧縮有無を確認
  • Cache-Control Inspect
  • Cache Control Overview
  • Expires Inspect
  • ETag Inspect
  • Last-Modified Inspect
  • Vary Inspect
  • Range Request Builder

再検証の見方（ETag / Last-Modified）

一般に、ETag系（If-None-Match）が使える場合はそちらを優先し、補助として Last-Modified 系（If-Modified-Since）を使います。

  • 強い更新検知が必要: ETag を優先
  • 軽量運用: Last-Modified でも成立する場合あり
  • 両方出す場合は整合性維持が重要

推奨（用途別）

  • API(JSON): no-store か no-cache + validators
  • HTML: short max-age + validators / no-cache
  • 静的アセット: long max-age + immutable + versioned URL

よくある失敗

  • HTMLに長いmax-ageを付けてデプロイ反映が遅れる
  • Vary不足で言語/圧縮違いが混在キャッシュされる
  • ETagを配信経路ごとに変えて再検証が不安定になる
  • no-cache と no-store を混同して意図しない挙動になる

このツールでできること

  • キャッシュ可否/再検証/共有キャッシュ可否の判定
  • バリデータ/Range/圧縮の有無を一覧化

注意（運用）

  • キャッシュ挙動はブラウザ/CDN/プロキシの層で変わるため、同一点観測で比較してください。
  • ヘッダー診断だけでは不十分な場合があります。アプリ側の更新戦略とキー設計も確認してください。

参照仕様

  • RFC 9111（HTTP Caching）
  • RFC 9110（HTTP Semantics）

FAQ

304 が返らない時は何から見ますか？

ETag/Last-Modified と If-* の往復有無を先に確認してください。

CDN経由だけ挙動が違う理由は？

s-maxage、Vary、圧縮差分、再圧縮による validator 変化が主因です。

参考リンク

  1. RFC 9111
  2. RFC 9110
  3. MDN: HTTP Caching

症状別ケーススタディ（このページ向け）

複数ヘッダーを横断して、どの層（ブラウザ/CDN/オリジン）でキャッシュが破綻しているかを先に特定します。

  • Response Headers から Cache-Control / ETag / Last-Modified / Vary / Age を同時確認する
  • 同一URLでオリジン直とCDN経由のレスポンスを比較する
  • 再リクエスト時に If-None-Match / If-Modified-Since が送信されているか確認する

実装時チェックリスト（このページ向け）

  • HTML・API・静的アセットで別ポリシーを採用する
  • ETag生成ロジックを配信経路で統一する
  • 静的ファイルはバージョン付きURLを前提に長期キャッシュ化する
  • 本番では Age と Vary を監視項目に入れる

site_map ルールに基づいて、次に確認すべきページを表示しています。

  1. Cache Not Working Troubleshooting — キャッシュが効かない症状をヘッダーから段階的に切り分け
  2. HTTP Cache Mismatch — キャッシュ不一致の原因候補を特定
  3. Cache Response Analyzer — レスポンスヘッダーからキャッシュ可否を判定
  4. 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
  5. 更新したのに反映されない時の診断手順 — HTML/API/静的アセット別にキャッシュ方針を確認し、反映遅延を短時間で切り分ける
  6. Cache系ツールの使い分け — 「更新されない」「304が返らない」「CDNだけ違う」を症状別に最短で分岐
  7. Cache Key Inspect — URL/Vary/ヘッダーからキャッシュキー分岐を可視化
  8. キャッシュ制御まとめ — Cache-Control/Pragma/Expires の使い分けを整理

キャッシュ制御

Cache-Control/Expires/Age を横断して配信ポリシーを診断