ETag Inspect

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

状態

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

使い方

ETag/If-None-Match を貼り付けて「解析」。強い/弱いETagを一覧表示します。ETag と If-None-Match を両方貼ると一致判定（weak/strong）も表示します。

注意（このツール）

  • ETag: / If-None-Match: のヘッダー行でも解析できます（複数行の貼り付けもOK）。

このページについて

何をするツール？

ETag/If-None-Match を解析して、強いETag/弱いETagの一覧を表示します。ETag と If-None-Match を両方貼り付けると、weak/strong 比較の一致判定も出せます。

304が返らない/返りすぎるなどキャッシュ不具合の切り分けに向きます。

ETagの基本

  • ETag はリソースのバージョン識別子です。
  • If-None-Match はクライアントのキャッシュ確認用です。
  • W/ で始まる弱いETagは「意味的に同じ」判定向けです。

構文（読み方）

ETag は通常ダブルクォート付きの値で、弱いETagは先頭に W/ が付きます。If-None-Match はETagのリスト（カンマ区切り）または * を取ります。

  • ETag: "abc123"
  • ETag: W/"abc123"
  • If-None-Match: "a", "b", W/"c"
  • If-None-Match: *

304（Not Modified）とETag

ETag は「キャッシュが使えるか」を確認するための鍵です。クライアントが If-None-Match を送信し、サーバーが一致と判断すると 304 を返し、本文転送を省略できます。

  • 304にならない：ETagが変わっている/付いていない/条件付きリクエストが送られていない
  • 304になりすぎる：ETagが更新されていない/キャッシュ設計が意図と違う

Cache-Control と再検証の関係

ETag は「再検証（revalidation）」で使われます。Cache-Control の設計次第で、再検証が頻発したり、そもそも再検証が起きなかったりします。

  • max-age が短い：再検証が増えやすい（If-None-Match が送られやすい）
  • no-cache：毎回再検証（ただし本文は 304 で省略される可能性）
  • immutable：更新されない前提で再検証を抑える（ファイル名にhashを入れる設計と相性が良い）

ETagの一致判定だけでなく、Cache-Control / Expires / Vary も合わせて確認すると原因を絞れます。

強いETagと弱いETag

強いETagはバイト単位の同一性、弱いETagは意味的な同一性を表す用途があります。用途を誤ると、更新が反映されない/無駄に再取得する原因になります。

  • 圧縮（gzip/br）や変換（画像最適化）でETagが変わる場合がある
  • CDN配下でオリジンとETagが一致しないことがある

Vary: Accept-Encoding とETag

同じURLでも、圧縮（gzip/br）などでレスポンスのバイト列が変わります。強いETagを使う場合は、エンコーディング差分で「別物」扱いになりやすい点に注意が必要です。

  • Vary: Accept-Encoding が無いと、キャッシュが圧縮版/非圧縮版を取り違えることがある
  • 画像最適化やHTMLミニファイなど中間変換があると、オリジンとエッジでETagが揃わないことがある

CDN/プロキシ配下で起きがちなこと

CDNやリバースプロキシは、圧縮・最適化・キャッシュ再構成などでETagの意味を変えてしまうことがあります。ETagが「誰が付けた値か（オリジンか、エッジか）」も重要です。

  • オリジンがETagを付けていても、エッジで付け替え/削除されることがある
  • 複数サーバー間でETagの生成規則がズレると、更新していないのにETagが変わる

使いどころ

  • 304が返らず毎回200になる
  • キャッシュが効きすぎて更新が反映されない
  • プロキシ/ CDN 配下でETagが変わる

プライバシー/セキュリティ注意点

ETagはキャッシュ検証のための仕組みですが、実装次第では「ユーザー識別子」のように使えてしまうため、プライバシー観点の注意点もあります。

  • ユーザーごとに異なるETagを付けると、共有キャッシュやデバッグが難しくなる
  • 個人情報を含む値をETagに入れない（ログ/監視に残りやすい）

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

  • Response Headers Parser で ETag / Cache-Control を確認
  • リクエスト側の If-None-Match を Request Headers Parser で確認
  • ETag値をこのツールで分解して強/弱や複数値を整理

トラブルシューティング観点

  • ETag が毎回変わる：複数台/ビルド差分/圧縮差分/中間変換/CDNの付け替えを疑う
  • If-None-Match が送られていない：Cache-Control 設計、DevToolsの「Disable cache」、Service Worker を確認
  • 304なのに表示が更新されない：ブラウザの別キャッシュ層（SW/Memory）や、HTMLの参照先が古い可能性
  • Cache-Control Inspect
  • Response Headers Parser / Request Headers Parser

推奨（実務）

  • API/HTML は ETag か Last-Modified を必ず付与
  • Range 対応は If-Range とセットで運用
  • ETag が毎回変わる場合は生成ロジックや中間変換を点検

このツールでできること

  • ETag/If-None-Matchの分解表示（ヘッダー行/複数行貼り付けOK）
  • 弱い/強いETagの判定
  • ETag と If-None-Match の一致判定（weak/strong 比較）

注：If-None-Match の評価はHTTPメソッド等に依存します。このツールは比較結果の目安（weak/strong）を表示します。

注意（運用）

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

参照仕様

  • RFC 9110（HTTP Semantics）
  • RFC 9111（HTTP Caching）
  • MDN: ETag / If-None-Match

FAQ

ETagが無い場合はどうなる？

条件付きリクエストでの再検証ができず、毎回200で本文が返ることがあります（Last-Modified等を使う場合もあります）。

If-None-Match の * は何？

「どれか一致するなら」という特別値で、存在チェックに使われることがあります。

参考リンク

  1. RFC 9110
  2. MDN: ETag
  3. MDN: If-None-Match
  4. RFC 9111
  5. MDN: HTTP caching

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

  1. 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
  2. Vary Inspect — Vary を解析してキャッシュ分岐条件を可視化
  3. Cache-Control Inspect — Cache-Control ディレクティブを分解・解釈
  4. Last-Modified Inspect — Last-Modified / If-Modified-Since を解析
  5. キャッシュ制御まとめ — Cache-Control/Pragma/Expires の使い分けを整理
  6. Cache Validator Overview — ETag/Last-Modified 系バリデータの関係を整理
  7. ETag Builder — 用途に応じたETag値を生成
  8. If-None-Match Inspect — If-None-Match を解析して再検証条件を確認

キャッシュ検証

ETag/Last-Modified と If-* をつないで再検証フローを判断