Varyヘッダは、HTTPレスポンスに付与され、「このレスポンスは特定のリクエストヘッダの値ごとに別物として扱ってほしい」という指示をキャッシュに与えます。Vary: Accept-Encodingなら「Accept-Encodingヘッダの値ごとに別キャッシュとして保管せよ」、Vary: User-Agentなら「User-Agentごとに分けよ」という意味で、CDN・ブラウザ・プロキシなどすべてのキャッシュ層がこの指示に従います。現在の仕様はRFC 9110（2022年、旧RFC 7234）で定義されており、コンテンツ交渉（Content Negotiation）の結果をキャッシュ整合性を保ちながら再利用するための鍵となるヘッダです。
この記事の目次
- Varyの動作モデル
- HTTP/1.1での導入と運用整備
- 現場で必須となる主な場面
- URLパスバリアント・no-cacheとの比較
- まとめ
Varyの動作モデル
通常のWebキャッシュは「URL」だけをキャッシュキーとしてレスポンスを保管します。しかしサーバが、リクエストヘッダ（Accept-Encoding、Accept-Language、User-Agentなど）に応じて異なるレスポンスを返す場合、URLが同じでも内容が違うため、単純なURLキャッシュでは別ユーザーに間違ったレスポンスを返す事故が起こります。これを防ぐためにサーバがVary: Accept-Encodingのように指示を返すと、キャッシュは「URL + Accept-Encoding値」の組み合わせをキャッシュキーとし、Accept-Encodingの値ごとに別バリアントを保管します。
クライアントAがAccept-Encoding: gzipで来ればgzip版を、クライアントBがAccept-Encoding: brで来ればBrotli版を、それぞれ別のキャッシュエントリから返す動作です。複数のヘッダを指定したい場合はVary: Accept-Encoding, Accept-Languageのようにカンマ区切りで列挙でき、全ての組み合わせごとに別キャッシュとして扱われます。Vary: *という特殊指定もあり、これは「ヘッダだけでなく要因を全て無視できないのでキャッシュしないでほしい」というニュアンスで、共有キャッシュは事実上保管しなくなります。
HTTP/1.1での導入と運用整備
Varyヘッダは1997年1月のRFC 2068（HTTP/1.1初版）で導入されました。HTTP/1.1ではAccept-Language、Accept-Encoding、Accept-Charsetなどによるコンテンツ交渉が機能として整備され、同じURLでもクライアントの要求に応じて異なるレスポンスを返す設計が普及しました。この交渉結果を中間キャッシュが安全に再利用するためには、「どの要素で差分が生じるか」を伝える仕組みが必要で、Varyヘッダがその役割を担いました。
1999年6月のRFC 2616でVaryの意味論が明確化され、特に共有キャッシュ（CDN・プロキシ）での適用ルールが整理されました。2014年6月のRFC 7234ではHTTPキャッシュ部分を独立した文書として再整理する中でVaryの取り扱いが詳述され、エッジケース（Vary: *、複数ヘッダ指定、変動性の評価）が明確化されました。2022年6月のRFC 9111でHTTPキャッシュセマンティクスの統合版として現代仕様になっています。Brotli・gzipの並存、デバイス別レスポンス、多言語サイトといった現代Webの実態に合わせて、Varyの重要度は時代とともに増してきました。
現場で必須となる主な場面
Vary: Accept-Encodingは現代Webで最も頻繁に使われるパターンで、gzip圧縮版とBrotli圧縮版と非圧縮版を別キャッシュとして保管します。これがないと、Brotli非対応の古いクライアントにBrotli圧縮されたレスポンスがCDNから返ってしまい、解凍できない事故が起こります。NginxやApacheのgzip/Brotliモジュール、CloudflareやFastlyなどのCDNも自動的にこのVaryを付与する設定が標準化されています。
Vary: Accept-Languageは多言語サイトで、/products/123を日本語版・英語版・中国語版で別キャッシュとして保管する用途に使われます。Vary: User-Agentは古い時代にモバイル版とデスクトップ版で別HTMLを返す設計で使われていましたが、現代ではレスポンシブデザインが主流で、User-Agentによる分岐は減ってきました。代わりにVary: Sec-CH-UA-MobileなどClient Hints系のヘッダが使われ始めています。Vary: Cookieは認証ユーザごとに別レスポンスを返す場合に使いますが、Cookieの値はユーザーごとに固有で組み合わせが膨大になるため、キャッシュ効率が落ちる注意点があります。Vary: OriginはCORS（Cross-Origin Resource Sharing）レスポンスで、Originヘッダごとに別Access-Control-Allow-Originを返す場合に必須です。
URLパスバリアント・no-cacheとの比較
Varyを使わない別の方法として、URLそのものを分けてしまう手があります。/products/123.ja.html・/products/123.en.htmlのように言語別パスを分けたり、cdn.example.com/images/photo.gz.jpgのように圧縮形式別ファイル名にしたりすることで、URLキャッシュキーだけで自然に分離できます。この方式はキャッシュ動作が分かりやすい反面、URL設計が複雑化し、Content Negotiationの透過性が失われます。
Cache-Control: no-cacheで毎回サーバに検証させる方法もありますが、これだとCDNのメリットがほぼなくなります。CDNによっては独自のキャッシュキー指定機能を持っており（CloudflareのCache Keysなど）、Vary以上に柔軟なバリアント管理ができる場合もあります。ただしCDN固有の機能に依存するため、移植性は下がります。標準仕様のVaryで完結する設計が最も汎用性が高く、ブラウザ・複数のCDN・プロキシすべてで同じ動作になります。ヘッダ指定は控えめに（多すぎるとキャッシュヒット率が下がる）、必要なものだけ的確に列挙するのが運用のコツです。
まとめ
VaryヘッダはHTTP/1.1（1997年RFC 2068）で導入され、現在はRFC 9111（2022年）で定義されたキャッシュバリアント指示ヘッダです。Accept-Encoding・Accept-Language・User-Agent・Cookie・OriginなどリクエストヘッダごとにキャッシュキーをURL以外にも拡張し、Content Negotiationの結果を安全にキャッシュ可能にします。Vary: Accept-Encodingはgzip/Brotli並存時の必須設定で、現代CDN・ブラウザ・プロキシのキャッシュ整合性確保の中核として欠かせないヘッダです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント