Vary Inspect

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

状態

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

使い方

Vary を貼り付けて「解析」。分岐に使われるリクエストヘッダーを一覧表示します（Vary: のヘッダー行や、レスポンスヘッダー全体の貼り付けもOK）。

注意（このツール）

  • Vary は「分岐ルール」です。キャッシュ可否は Cache-Control 等の設定も合わせて確認してください。

このページについて

何をするツール？

Vary ヘッダーを解析して、レスポンスが「どのリクエストヘッダーで分岐しているか」を一覧で表示します。

キャッシュが効かない/効きすぎる、CDNで表示が混ざる、CORSの挙動が不安定などの原因切り分けに向きます。

Varyの基本（最短）

  • Vary は「このレスポンスは特定のリクエストヘッダーにより内容が変わる」ことを示します。
  • キャッシュ（ブラウザ/プロキシ/CDN）は Vary を見て、分岐ごとに別キャッシュとして扱います。
  • Vary の設計は「キャッシュキー（Cache Key）」の設計そのものです。

構文（読み方）

Vary はカンマ区切りのヘッダー名のリスト、または特別値 * を取ります。

  • Vary: Accept-Encoding
  • Vary: Origin
  • Vary: Accept-Encoding, Origin
  • Vary: *

例（コピペでイメージする）

トラブル対応では、レスポンスヘッダー全体を貼り付けて「Varyだけ取り出す」形が早いです。

  • 静的アセット（圧縮あり）: Vary: Accept-Encoding
  • CORS（Originに応じて許可）: Vary: Origin
  • 言語別HTML: Vary: Accept-Language（キャッシュ割れに注意）

逆に、Vary: * が出ていると「共有キャッシュがほぼ効かない」サインになりやすいので、まずここを疑います。

なぜ重要？（キャッシュキーの事故を防ぐ）

Vary が足りないと、別条件で作ったレスポンスが同じURLに対して再利用され、表示混在やセキュリティ事故につながることがあります。

逆に Vary を増やしすぎると、分岐が増えてキャッシュが割れ（キャッシュヒット率が下がり）、遅延やコストが増えます。

設計の考え方（Varyは最小で、URLで分ける）

Vary は便利ですが、増やすほどキャッシュが割れてヒット率が落ちます。分岐が恒常的なら「URLやパスで分ける」ほうが運用が安定しやすいです。

  • 言語: /ja/ /en/ に分ける（Accept-LanguageでVaryしない）
  • デバイス差分: レスポンシブ/同一HTMLに寄せる（User-AgentでVaryしない）
  • 認証: Authorization/Cookieで変わるなら、共有キャッシュ前提を外す（private/no-store等）

Vary: Accept-Encoding の典型パターン

同じURLでも、圧縮方式（br/gzip/identity）によりレスポンスのバイト列が変わります。圧縮を使うなら Vary: Accept-Encoding は基本セットです。

  • 無い場合: キャッシュが圧縮版/非圧縮版を取り違えて壊れることがある
  • ある場合: キャッシュはエンコーディング別に保持する（ヒット率は落ちるが正しい）

User-Agent ではなく Client Hints を使う？

UA差分が必要なケースでも、User-Agent でVaryするのは分岐が多すぎてキャッシュが割れがちです。Client Hints（例: Sec-CH-UA-Platform）を使う設計もありますが、やはり分岐増によるコストには注意が必要です。

まずは「URLで分けられないか」「同一HTMLに寄せられないか」を検討して、最後の手段としてVaryの追加を考えるのが安全です。

用語（このページの前提）

  • Variant（バリアント）: 同じURLでも、リクエスト条件によって変わるレスポンスの「別版」。
  • Cache Key（キャッシュキー）: キャッシュが「同一とみなす条件」の組み合わせ。Vary や CDN のキー設定で決まる。
  • Shared Cache（共有キャッシュ）: CDN/プロキシなど複数ユーザーで共有されるキャッシュ。混在すると事故になりやすい。
  • Fragmentation（キャッシュ割れ）: 分岐が増えてキャッシュが細分化し、ヒット率が下がる現象。

よくあるVary（代表例）

  • Accept-Encoding：gzip/br など圧縮の違いを分ける（静的アセットで重要）
  • Origin：CORSのレスポンスが Origin によって変わる場合
  • Accept-Language：言語で内容が変わる場合（キャッシュが割れやすい）
  • User-Agent：デバイス差分（原則おすすめしない、割れが大きい）

セキュリティ/事故パターン（Vary不足が原因になる）

Vary はパフォーマンスだけでなく「誤配信（別条件のレスポンスが混ざる）」を防ぐ役割もあります。共有キャッシュを挟むほど、影響が大きくなります。

  • CORSヘッダーの混在: Origin により Access-Control-Allow-Origin を変えるのに Vary: Origin が無い
  • 認証/個人情報の混在: Cookie/Authorization で内容が変わるのに共有キャッシュが効いてしまう
  • 圧縮の取り違え: Accept-Encoding の分岐があるのに Vary が無い

対策は「Varyを足す」だけでなく、Cache-Control（private/no-store）やCDNのキャッシュキー/キャッシュ除外も含めて設計します。

CDN/共有キャッシュでの注意

Vary はブラウザだけでなく、CDNやプロキシのキャッシュヒット率に直結します。特に、Cookie/Authorization/Origin などは「混ざると事故」「分岐すると割れる」の両面があるため、慎重に扱います。

  • 共有キャッシュ前提のレスポンスは、ユーザー固有情報を含めない
  • CORSを動的に返すなら Vary: Origin を優先的に確認
  • Vary: * は「ほぼ共有キャッシュ不可」になりやすい

CORSとVary: Origin

Access-Control-Allow-Origin をリクエストの Origin に合わせて動的に返す場合、Vary: Origin が無いと、他オリジン向けのヘッダーがキャッシュから混ざることがあります。

CDNを挟むと影響が大きくなるので、CORS周りのトラブルでは優先的に確認します。

Vary: * はどういう意味？

Vary: * は「どのリクエストヘッダーが影響するかを明示できない」ことを意味し、共有キャッシュ（CDN/プロキシ）では基本的に再利用が難しくなります。

意図せず出ている場合、キャッシュが効かない原因になりやすいので注意です。

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

  • Response Headers Parser にレスポンスヘッダーを貼って Vary を確認
  • このツールで Vary を分解し、分岐ヘッダーの数/種類を把握
  • Cache-Control / ETag / Content-Type も合わせて確認し、意図したキャッシュ設計か見る

よくある落とし穴

  • Originに応じてCORSヘッダーを変えるのに Vary: Origin が無い
  • User-Agent / Accept-Language で Vary してキャッシュが割れすぎる
  • 圧縮（br/gzip）を返すのに Vary: Accept-Encoding が無い
  • Cookie/Authorization で分岐するのに共有キャッシュを想定してしまう

トラブル別チェックリスト

  • CDNで表示が混ざる: Vary不足（特に Origin / Accept-Encoding）を疑う
  • キャッシュが効かない: Vary: *、Vary過多、Cache-Controlの設定、CDNのキャッシュキー設定を確認
  • APIのCORSが不安定: Access-Control-Allow-Origin が動的なら Vary: Origin を優先
  • 言語が切り替わらない/混ざる: Accept-LanguageでVaryしていないか、URL分離できないかを確認

確認のしかた（curlで差分を見る）

Vary の理解は「実際にヘッダーを変えて同じURLを叩く」のが最短です。以下は例です（URLは置き換えてください）。

  • 圧縮差分: curl -I -H "Accept-Encoding: br" https://example.com/asset.js
  • 圧縮差分（比較）: curl -I -H "Accept-Encoding: gzip" https://example.com/asset.js
  • CORS差分: curl -I -H "Origin: https://a.example" https://example.com/api
  • 言語差分: curl -I -H "Accept-Language: ja" https://example.com/

結果の Vary と、実際に変えたヘッダーが噛み合っているか（足りない/多すぎないか）を確認します。

  • Response Headers Parser
  • Cache-Control Inspect
  • ETag Inspect
  • CORS Checklist
  • Content-Type Inspect

推奨（実務）

  • Vary は最小限に（キャッシュ分岐の爆発を防ぐ）
  • 圧縮は Accept-Encoding で分岐するのが基本
  • Vary: * は避ける（キャッシュ無効化に近い）

このツールでできること

  • Vary の値を分解して一覧化
  • 重複/大小文字差分を整理（正規化）
  • 危険な/割れやすい分岐（Cookie/Authorization/User-Agentなど）を見つける補助
  • Vary: * の検出

注意（運用）

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

参照仕様

  • RFC 9110（HTTP Semantics）
  • RFC 9111（HTTP Caching）
  • MDN: Vary

FAQ

Vary を付ければキャッシュが効く？

Vary は「分岐のルール」であり、キャッシュ可否は Cache-Control などで決まります。両方が必要です。

Vary: Origin は常に必要？

Access-Control-Allow-Origin を固定値（例: * や特定オリジン）で返すだけなら不要なこともあります。動的に変えるなら必須寄りです。

User-Agent で Vary するのはダメ？

技術的に可能ですがキャッシュが割れやすく、CDNでコスト/遅延が増えがちです。できるだけ別URLやレスポンシブで解決する方が安全です。

Vary と Vary: Accept-Encoding の違いは？

Vary はヘッダー名のリストを入れる「器」です。Accept-Encoding を入れると、圧縮方式の違いでレスポンスが分岐することをキャッシュに伝えます。

Vary に Cookie や Authorization を入れるべき？

「ユーザーごとに内容が変わる」なら混在事故を防ぐ意味はありますが、共有キャッシュのヒット率はほぼ出なくなります。基本は private/no-store などで共有キャッシュ前提を外すのが安全です。

参考リンク

  1. RFC 9110
  2. RFC 9111
  3. MDN: Vary
  4. MDN: HTTP caching
  5. MDN: CORS

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

  1. Last-Modified Inspect — Last-Modified / If-Modified-Since を解析
  2. ETag Inspect — ETag と If-None-Match の整合を解析
  3. Expires Inspect — Expires / Date を解析して期限挙動を確認
  4. Cache-Control Inspect — Cache-Control ディレクティブを分解・解釈
  5. Accept-Encoding Inspect — Accept-Encoding を解析して圧縮交渉を確認
  6. Content-Encoding Inspect — Content-Encoding を解析して実際の圧縮方式を確認
  7. Transfer-Encoding Inspect — Transfer-Encoding を解析して転送方式を確認
  8. Content-Length Inspect — Content-Length を解析してサイズ整合を確認

圧縮/転送

Accept/Content/Transfer-Encoding と Vary から圧縮不整合を切り分け