HTTPヘッダーチェッカー
任意のURLのHTTPレスポンスヘッダーとセキュリティ状态を確認します。
🌐 sitekits fetches the URL server-side (private/internal addresses are blocked). Response body is not retrieved.
概要
レスポンスヘッダは、サイトの挙動の大半が実際に設定されている場所です。 キャッシュ・圧縮・セキュリティポリシー・CORS・リダイレクト。そしてブラウザ上では、 DevTools で正しいリクエストを開かないと見えない部分でもあります。
このツールはサーバー側で URL をリクエストしてレスポンスヘッダを返し、そこに 至るまでのリダイレクト連鎖も表示します。ブラウザ自身のセキュリティモデルが クロスオリジンのレスポンスヘッダを JavaScript から隠すため、このサイトで ページ内だけでは完結できない少数のツールの 1 つです。
使い方
- URL を入力します。スキームは省略できます（
example.comはhttps://example.comとして扱われます）。 - まずリダイレクト連鎖を読みます。各ホップに URL とステータスコードが出ます。
- 最終的なレスポンスヘッダを読みます。
答えは多くの場合リダイレクト連鎖にある
遅い、あるいは正規 URL が間違っているとき、それが見えるのは連鎖です。1 ホップ ごとに 1 往復かかり、よくあるパターンはいずれも避けられます。
http://example.com→https://example.com→https://www.example.comは、 1 回で済むところを 2 回リダイレクトしています。最終的なホストとスキームへ 1 ホップで直接送るべきです。301の着地先がまた301なのは、サイト移行の際の 2 世代のルールが両方とも 生きているという意味です。- 戻ってくる先へのリダイレクトはループで、このツールは無限に辿らず 5 ホップで 止めます。
301を意図した場所の302は、移動が一時的だとクローラーに伝えます。 古い URL が順位を保持し続け、新しい URL は何も蓄積しません。
301/302 と 307/308 の違いはリクエストメソッドです。歴史的にクライアントは
301 と 302 を辿るとき POST を GET に変えており、その挙動は今も広く残って
います。フォーム送信がリダイレクトの裏で妙な動きをするなら、最初に確認すべき点です。
注意して読む価値のあるヘッダ
| ヘッダ | 見るべき点 |
|---|---|
cache-control | 静的アセットの no-store は帯域の無駄、HTML の長い max-age はデプロイが見えなくなる |
etag / last-modified | 無いと、再検証のたびに本文全体を再転送する |
content-encoding | テキストレスポンスに gzip / br が無いのは、最も安価な性能改善の機会 |
vary | Vary: User-Agent は CDN のキャッシュを数百通りに分断する |
strict-transport-security | max-age が短い、includeSubDomains が無いと、初回リクエストを降格できる |
content-security-policy | 各ディレクティブの意味は CSP ビルダー を参照 |
x-content-type-options | nosniff が無いと、誤った content-type がスクリプトとして再解釈され得る |
access-control-allow-origin | fetch が失敗する理由はほぼ常にここか、あるいはヘッダ自体の欠落 |
set-cookie | セッションを運ぶものに Secure・HttpOnly・SameSite が付いているか |
server と x-powered-by は逆の理由で注目する価値があります。ソフトウェアの
バージョンを開示するだけで他に何もしません。消すことはセキュリティ対策では
ありませんが、残す理由もありません。
このツールが意図的にしないこと
ハンドラは接続の前に、プライベート・ループバック・リンクローカル・予約済みの
アドレス範囲のブロックリストで URL を検証し、その検査をリダイレクトの各ホップで
繰り返します。ホップごとの検査が無ければ、公開ホスト名が 127.0.0.1 や
クラウドのメタデータアドレスへリダイレクトしたときに追従してしまいます。
これが、ヘッダ確認サービスが「他人の内部ネットワークを外から探る手段」に
変わる経路です。
レスポンス本文も一切転送しません。接続はヘッダのために読んで破棄します。 任意の本文を返すサービスは、意図がどうであれオープンプロキシです。
URL に埋め込まれた資格情報（https://user:pass@host/）はリクエスト前に削除するので、
相手サーバーへ送られることも、リダイレクト連鎖として返ってくることもありません。
CDN の裏では「誰が返したヘッダか」が変わる
Cloudflare や Fastly のようなキャッシュ層を挟んでいる場合、ここで見えている ヘッダはオリジンが送ったものとは限りません。CDN はヘッダを追加し、書き換え、 削除します。設定ファイルと実際の応答が食い違う原因のほとんどがこれです。
見分けるための手掛かりがいくつかあります。cf-cache-status（あるいは相当する
ベンダー固有のヘッダ）が HIT なら、そのレスポンスはキャッシュから出ており、
オリジンは今回の往復に関与していません。age はキャッシュに入ってからの経過
秒数です。この 2 つが付いている応答の cache-control は、オリジンの設定では
なく CDN が上書きした後の値である可能性があります。
セキュリティヘッダはとくに注意が必要です。CDN の「自動 HTTPS 書き換え」や
WAF の機能が content-security-policy や strict-transport-security を
追加・変更することがあり、その結果アプリ側のコードを読んでも実際に配信されて
いる値が分かりません。稼働ホストに対してこのツールを当てるのが唯一の確認方法です。
使用例
- 再現できない CORS エラー — 実際のエンドポイントの
access-control-allow-originを、コードが期待する値と比べます。ヘッダが無い 場合と値が違う場合で、ブラウザのメッセージは同じです。 - デプロイが反映されない — HTML の
cache-controlとageを見ます。CDN が キャッシュ済みのドキュメントを配信している方が、ビルドの問題より頻繁です。 - セキュリティヘッダ導入の点検 — 設定ファイルではなく稼働ホストに対して
strict-transport-security・content-security-policy・x-content-type-optionsを確認します。CDN や WAF がどれでも追加・削除・ 上書きし得るためです。 - 正規リダイレクトの検証 — 連鎖が意図したホストとスキームで、ちょうど 1 ホップで終わることを確認します。
注意事項
リクエストはこのツールを示す固定の User-Agent を使い、5 秒でタイムアウトします。
未知のエージェントを拒否するサイトは 403 を返しますが、それはこのツールの
失敗ではなくそのサイトの設定についての本当の答えです。
ヘッダ名はサーバーが送ったまま表示します。HTTP/2 は通信路上で小文字の名前を
要求するため、HTTP/2 のレスポンスでは content-type、HTTP/1.1 では
Content-Type と見えることがあります。いずれにしても名前は大文字小文字を
区別しません。
独自のヘッダ・特定のメソッド・リクエスト本文を送る必要があるなら、 REST API テスター を使ってください。利用者自身のブラウザから 実行するので、共有サービスがしてはならないことができます。