Expires Inspect

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

状態

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

使い方

Expires（必要ならDateも）を貼り付けて「解析」。日時と「期限切れかどうか」の判定を表示します（ヘッダー行/複数行貼り付けOK、レスポンスヘッダー全体でもOK）。

注意（このツール）

  • 実際のキャッシュ挙動は Cache-Control が優先されることが多いので、Cache-Control Inspect も併用してください。

このページについて

何をするツール？

Expires / Date を解析して、期限切れ時刻（staleになる時刻）を読みやすく表示します。両方貼ると、Expires が Date より未来か/過去かも判定します。

「キャッシュが効かない」「効きすぎる」「いつまで古いまま？」といった問題の切り分けに向きます。

Expiresの基本

  • Expires は「このレスポンスの有効期限（日時）」を示します。
  • Date は「レスポンスが生成された時刻」を示します。
  • Expires が Date より過去なら、そのレスポンスはすでに期限切れ（stale）です。

Cache-Controlとの関係（最重要）

実務では Cache-Control が優先される場面が多く、Expires だけ見ても判断できないことがあります。まず Cache-Control の方針（max-age/no-store/no-cache 等）を確認してから Expires を見ます。

  • max-age がある：相対期限（秒）で管理されるため、Expiresは補助的になる
  • no-cache：期限の有無に関わらず再検証が必要になりやすい
  • no-store：保存されないため Expires を見ても意味が薄い

構文（日時の形式）

Expires は HTTP-date で指定されます。実務では IMF-fixdate がほぼ使われます（例: Wed, 21 Oct 2015 07:28:00 GMT）。

  • Expires: Wed, 21 Oct 2015 07:28:00 GMT
  • Date: Wed, 21 Oct 2015 07:00:00 GMT

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

  • Fresh / Stale: キャッシュが期限内（fresh）か期限切れ（stale）か。
  • Shared cache: CDN/プロキシのような共有キャッシュ。
  • Revalidation（再検証）: stale なキャッシュを使う前に確認する動作。

例（よくあるパターン）

  • Expires が過去: Expires: 0 / 既に過去日時 → 「基本はキャッシュさせない」意図
  • Expires が未来: 期限までは fresh になり得る（ただし Cache-Control 次第）
  • Date が無い: 実務ではDateもあるのが一般的だが、環境により欠けることもある

なぜ Date と一緒に見る？（時計ズレの検出）

Expires は絶対日時なので、サーバーやCDNの時刻がズレていると、意図と違う「過去/未来」に見えることがあります。Date と並べるとズレに気づきやすくなります。

  • Expires < Date：そもそも既に期限切れ（stale）扱いになりやすい
  • Expires が不自然に遠い未来：ヘッダー付け替え/バグ/意図しない設定の可能性

よくある落とし穴

  • Cache-Control と Expires が矛盾していて判断を誤る（max-age優先など）
  • サーバー時刻のズレで Expires が過去/未来に見える
  • CDNがヘッダーを付け替える/追加する（オリジンと一致しない）

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

CDNはオリジンの Expires/Cache-Control をそのまま通すとは限りません。キャッシュルールで上書きされたり、追加ヘッダーとして付与されることがあります。

  • オリジンとエッジで Expires が違う：CDNのキャッシュポリシーを確認
  • Vary やキャッシュキーの設計次第で「古いものが混ざる」こともある

確認のしかた（curlでExpires/Dateを見る）

まずはヘッダーだけ取得して Expires/Date/Cache-Control を確認します（URLは置き換えてください）。

  • 取得: curl -I https://example.com/asset.js
  • CDN経由/直オリジンで差がある場合は、両方のヘッダーを比較する

Expires を単体で見るのではなく、Cache-Control（max-age/no-cache/no-store）とセットで解釈します。

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

  • キャッシュが効かない: Expires が過去 / Vary: * / no-cache/no-store / CDNのバイパス設定を確認
  • 効きすぎて更新されない: Expires が遠い未来 / max-ageが大きい / immutable / ファイル名にhashが無い等を確認
  • 期限が変に見える: Date と比較して時計ズレ（サーバー/CDN）を疑う

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

  • Response Headers Parser にレスポンスヘッダーを貼り、Cache-Control/Expires/Date を確認
  • このツールで Expires/Date を解析して「過去か未来か」を整理
  • ETag/Last-Modified も確認し、stale時の再検証が成立するかを見る
  • Cache-Control Inspect
  • ETag Inspect
  • Last-Modified Inspect
  • Response Headers Parser
  • Vary Inspect

推奨（用途別）

  • 基本は Cache-Control を優先し、Expires は補助にする
  • HTML は短め Expires + validators が安全
  • 静的アセットは長期 Expires + versioned URL

このツールでできること

  • Expires / Date の日時解析（UTC/GMT）
  • Expires が Date より未来/過去か判定
  • レスポンスヘッダー全体から Expires/Date を抽出

注意（運用）

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

参照仕様

  • RFC 9110（HTTP Semantics）
  • RFC 9111（HTTP Caching）
  • MDN: Expires / Date

FAQ

Expires と max-age はどっちが優先？

実務では max-age（Cache-Control）が優先されることが多いです。Expires は後方互換や補助として使われます。

Expires: 0 はどう扱う？

環境によって解釈が異なる可能性があるため、明示的に Cache-Control を使う設計の方が安全です。

Date が無い/変なのは問題？

Date が無い/不正だと、Expires との比較や時計ズレ検出が難しくなります。まずはレスポンスの生成系（アプリ/プロキシ/CDN）のどこでヘッダーが付与されているかを確認してください。

参考リンク

  1. RFC 9110
  2. RFC 9111
  3. MDN: Expires
  4. MDN: Date
  5. MDN: HTTP caching

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

  1. Age Inspect — Age を解析して共有キャッシュ滞在時間を把握
  2. Last-Modified Inspect — Last-Modified / If-Modified-Since を解析
  3. If-Modified-Since Inspect — If-Modified-Since を解析して条件付き取得を確認
  4. Vary Inspect — Vary を解析してキャッシュ分岐条件を可視化
  5. Cache Not Working Troubleshooting — キャッシュが効かない症状をヘッダーから段階的に切り分け
  6. HTTP Cache Mismatch — キャッシュ不一致の原因候補を特定
  7. Cache Response Analyzer — レスポンスヘッダーからキャッシュ可否を判定
  8. Cache Key Inspect — URL/Vary/ヘッダーからキャッシュキー分岐を可視化

キャッシュ制御

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