HTTP レスポンスヘッダーを確認する

課題

HTTP ヘッダーは多くの本番障害の原因を説明しますが、コピーしたヘッダーブロックには Set-Cookie の重複、CDN の Cache-Control、プロキシの CORS、ホスティングのリダイレクト、フレームワークが追加した保護用ヘッダーが混ざります。本文やステータスコードだけを見ると、ブラウザ動作を決める設定を見落としやすくなります。

使う場面

• CORS、credentials、preflight レスポンスヘッダーが原因でブラウザ要求が止まるときに使います。
• デプロイ後も CDN やブラウザが古い内容を返し続けるときに適しています。
• リダイレクト、API 要求、ログインコールバックが環境ごとに違って動くときに役立ちます。
• curl、DevTools、API クライアント、本番ログのレスポンスヘッダーを同じ基準で比較したいときに使います。
• ホスティングや CDN 設定で security、cache、cookie の変更をデプロイし、次の設定変更前に証拠が必要なときに使います。

手順

1. 手順 1

   生のヘッダーを取得

   ブラウザ DevTools、`curl -I`、API クライアント、CDN ログ、サーバーログからレスポンスヘッダー全体をコピーします。可能ならステータス行も残します。

2. 手順 2

   共有前に機密値を除く

   ヘッダーブロックをチケットやチャットに貼る前に、セッション Cookie、Bearer トークン、API key、ユーザー ID、内部ホスト名を削除します。

3. 手順 3

   設定変更前に解析

   `HTTP Header Parser` に貼り付け、名前を正規化し、cache、CORS、content、security、request、response のグループに分けます。

4. 手順 4

   重複ヘッダーを確認

   `set-cookie`、`vary`、`cache-control`、重複した `access-control-*` を確認します。正常な重複もありますが、意図しない重複はブラウザ挙動を分かりにくくします。

5. 手順 5

   症状に沿って追跡

   古い内容なら cache ヘッダー、ブラウザでブロックされる要求なら CORS、ログイン失敗なら redirect、cookie、token 関連ヘッダーから比較します。

6. 手順 6

   対象 URL と一緒に記録

   リダイレクトやコールバックの問題では `URL Parser` と `Query String Parser` で URL も確認し、解析したヘッダー要約をデバッグメモに残します。

例

HTTP/2 200
content-type: application/json; charset=utf-8
cache-control: public, max-age=3600
access-control-allow-origin: https://app.example.com
vary: origin, accept-encoding
strict-transport-security: max-age=31536000; includeSubDomains

Start line: HTTP/2 200
Total headers: 5
Cache headers: cache-control, vary
CORS headers: access-control-allow-origin
Security headers: strict-transport-security

よくあるミス

よくある質問