304が返らない時の診断手順

「ETagを返しているのに毎回200になる」ケースは、応答側と再リクエスト側の条件付きヘッダー連携が崩れていることが多いです。

症状の定義

診断ステップ

  1. 1) Cache Diagnostic で Response の validator 有無を確認する
  2. 2) If-None-Match Inspect で再リクエストに If-None-Match が乗っているか確認する
  3. 3) If-Modified-Since Inspect で日時系validatorの往復を確認する
  4. 4) ETag Inspect で弱/強ETagの扱い差を確認する
  5. 5) CDN経由の場合は HTTP Cache Mismatch で層差分を確認する

よくある原因

修正チェックリスト

使うツール

FAQ

ETag があるのに 304 にならないのはなぜですか？
再リクエスト時に If-None-Match が送られていない、または経路上で ETag が変わっている可能性が高いです。
Last-Modified だけでも 304 は使えますか？
はい。If-Modified-Since との往復が成立すれば可能です。可能なら ETag も併用すると安定します。

参照仕様

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

  1. Cache Diagnostic — キャッシュ関連ヘッダーを横断診断
  2. ETag Inspect — ETag と If-None-Match の整合を解析
  3. If-None-Match Inspect — If-None-Match を解析して再検証条件を確認
  4. If-Modified-Since Inspect — If-Modified-Since を解析して条件付き取得を確認
  5. Last-Modified Inspect — Last-Modified / If-Modified-Since を解析
  6. Cache Response Analyzer — レスポンスヘッダーからキャッシュ可否を判定
  7. 症状別診断ガイド（入口） — キャッシュ/CORS/JWT/MIME系の実運用トラブルを、症状起点で最短導線に振り分ける総合ハブ
  8. 更新したのに反映されない時の診断手順 — HTML/API/静的アセット別にキャッシュ方針を確認し、反映遅延を短時間で切り分ける

事例クラスタ一覧

実運用トラブル別に、最短の診断ルートへ入るためのシナリオ集