HTTP Status Inspect

HTTPヘッダー/経路情報をブラウザ内で整理・診断します。入力はサーバーへ送信しません。観測差分の一次切り分けに使えます。

状態

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

使い方

HTTPステータス行やResponse Headersを貼り付けて「解析」。まずコード帯（2xx/3xx/4xx/5xx）を確認し、次に関連ヘッダーへ進みます。

注意（このツール）

  • 入力に複数のステータス行がある場合は最初のコードを基準に表示します。
  • 理由句（Reason Phrase）が無い場合は代表的な名称を表示します。
  • ステータス単体では原因確定できません。Location / WWW-Authenticate / Retry-After などを合わせて確認してください。

このページについて

何をするツール？

HTTPステータスコード（例: 200/301/404/500）を読み解き、意味や関連ヘッダーの確認ポイントを整理します。

「なぜ200なのに動かない？」「301/302でどこへ飛んでいる？」などの切り分けに向きます。

基本（ステータスの役割）

  • HTTPステータスは「リクエストの結果」を示す合図です。
  • コードは3桁で、最初の1桁が「分類（1xx〜5xx）」です。
  • 同じコードでも状況により意味が変わるため、関連ヘッダー確認が重要です。

ステータス分類（ざっくり）

  • 1xx: 情報（通信中）
  • 2xx: 成功（成功/処理済み）
  • 3xx: リダイレクト（別URLへ誘導）
  • 4xx: クライアント側の問題（リクエスト不正など）
  • 5xx: サーバー側の問題（処理失敗など）

入力の例

  • HTTP/1.1 404 Not Found
  • HTTP/2 301 Moved Permanently
  • Status: 503
  • Response Headers をまるごと貼り付け

リダイレクト系（3xx）の見どころ

  • Location ヘッダーが「次のURL」です。
  • 301/308 は恒久、302/307/303 は一時の意味合いです。
  • ループや多段リダイレクトは Redirect Chain Inspect で確認できます。

キャッシュ系（304/キャッシュ適用）

304 Not Modified は「内容は更新されていない」という合図です。ETag / Last-Modified とセットで使われます。

  • ETag/If-None-Match、Last-Modified/If-Modified-Since の一致を確認
  • Cache-Control/Expires の設定次第で 304 にならないこともある

ステータス行の見方（HTTP/1.1 404 Not Found）

  • HTTP/1.1: プロトコルのバージョン（表示上は HTTP/2 や HTTP/3 と出ることもあります）。
  • 404: ステータスコード（分類は先頭1桁）。
  • Not Found: 理由句（無い場合もあります）。

ヘッダー貼り付け時に Status: 404 のような行が混ざることがありますが、ここでは同じ「ステータス情報」として扱えます。

4xx と 5xx の切り分け（ざっくり）

4xx は「リクエスト側の問題」、5xx は「サーバー側の処理失敗」が基本ですが、プロキシ/ゲートウェイが挟まると見え方が変わります。

  • 4xx でも実はサーバー設定ミスが原因: CORSや認可設定で 403/401 を返すケースなど。
  • 5xx の 502/504 は「上流（upstream）」が怪しい: CDN/リバースプロキシ/アプリのどこで止まったかを疑う。

認証/認可（401/403）で見るポイント

  • 401: 認証が必要（または失敗）。WWW-Authenticate を確認。
  • 403: 認証はできているが許可されない（権限不足/ポリシー違反など）。
  • Cookie/JWT を使う場合は「ブラウザに送れているか」「期限切れ/署名エラーがないか」も切り分けポイントです。

メソッド周り（405/OPTIONS）で見るポイント

  • 405 Method Not Allowed は Allow ヘッダーに許可メソッドが列挙されるのが一般的です。
  • CORSの preflight（OPTIONS）が 4xx/5xx だと、本番リクエスト前にブラウザが止めます。

レート制限/一時停止（429/503）

  • 429 Too Many Requests は「短時間に多すぎる」を示すことが多いです。
  • 503 Service Unavailable は「一時的に処理できない」（メンテ/過負荷/上流停止など）。
  • Retry-After がある場合は再試行タイミングのヒントになります。

502/504（ゲートウェイ/上流）を疑う時

CDNやリバースプロキシが前段にあると、あなたが見ているステータスは「手前の機器」が返している場合があります。

  • 502: 上流から不正な応答（接続失敗/異常終了/プロトコル不一致など）。
  • 504: 上流の応答待ちでタイムアウト。
  • Via/Age/Server/Forwarded 系ヘッダーで「どこを通ったか」の手がかりを探す。

症状別チェック（検索から来た人向け）

  • 「APIは200なのに画面が壊れる」: Content-Type と本文（JSONエラー/HTMLエラー）を確認。
  • 「POSTだけ失敗」: 405/415/413 を疑い、Allow/Content-Type/Content-Length を確認。
  • 「本番だけ301ループ」: Location とリダイレクト連鎖（http↔https、www有無）を確認。
  • 「時々502/504」: 上流の負荷/タイムアウト、CDN経由の有無、Via/Age を確認。

推奨（実務）

  • 4xxは入力/認可/ルーティングの順で確認し、5xxは上流/タイムアウトを先に疑う
  • ステータス単体で判断せず、Location/WWW-Authenticate/Retry-After などの関連ヘッダーを同時確認する
  • 同一リクエストをcurlやサーバーログでも再現し、ブラウザ依存の見え方を除外する

コード帯ごとの次アクション

  • 2xx: 本文とContent-Typeを確認し、意味的成功かを判定
  • 3xx: Location先・ループ・メソッド維持（301/302/307/308）を確認
  • 4xx: 入力値・認証情報・CORS/CSRF・許可メソッドを確認
  • 5xx: upstream疎通・タイムアウト・リトライ方針を確認

よくある落とし穴

  • 200 OK でも中身はエラー（HTMLでエラーページ）
  • 401 なのに認証ヘッダー（WWW-Authenticate）が無い
  • 405 なのに Allow ヘッダーが無い
  • 429/503 なのに Retry-After が無く再試行タイミングが不明
  • 404 は「URLが無い」以外にも、ルーティング/リライト/権限で発生します。
  • 502/504 はアプリというより「前段〜上流」の問題のことが多いです。

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

  • Response Headers Parser でヘッダー全体を抽出
  • このツールでステータスの意味と関連ヘッダーを整理
  • Location/Cache-Control/ETag などを個別ツールで深掘り
  • Response Headers Parser
  • Location Inspect
  • Redirect Chain Inspect
  • Cache-Control Inspect
  • ETag Inspect
  • Last-Modified Inspect
  • Expires Inspect
  • Vary Inspect
  • Content-Type Inspect
  • Via Inspect
  • Age Inspect
  • Forwarded Inspect
  • CORS Response Inspect

このツールでできること

  • HTTPステータスコードの分類と意味の整理
  • 関連ヘッダー（Location/ETag/Allow など）の確認ポイント提示
  • 複数ステータス行がある場合の一覧化

注意（運用）

  • 中継機器でヘッダーが書き換わることがあります。取得地点を揃えて比較してください。
  • 最終判断はサーバーログと設定（信頼プロキシ、ルーティング）で確認してください。

参照仕様

  • RFC 9110（HTTP Semantics）
  • RFC 9111（HTTP Caching）
  • MDN: HTTP response status codes

FAQ

200 OK なのに動かないのはなぜ？

アプリ内部でエラー画面を返している可能性があります。レスポンス本文や Content-Type を確認してください。

301/302 の違いは？

301 は恒久、302 は一時という意味合いです。実際の挙動はキャッシュやブラウザ実装にも依存します。

304 が出ないのは正常？

Cache-Control の方針や ETag/Last-Modified の有無で 304 が使われないことがあります。

401 と 403 はどう違う？

401 は「認証が必要/失敗」、403 は「認証できていても許可されない」です。WWW-Authenticate の有無も確認してください。

502 と 504 はどう違う？

502 は上流から不正な応答、504 は上流待ちのタイムアウトです。どちらもCDN/プロキシの関与を疑うのが近道です。

404 と 410 はどう使い分ける？

404 は見つからない、410 は恒久的に削除されたという意味合いです。削除を明示したい時に 410 を使うことがあります。

参考リンク

  1. RFC 9110
  2. RFC 9111
  3. MDN: HTTP response status codes
  4. MDN: Location
  5. MDN: WWW-Authenticate
  6. MDN: Retry-After
  7. RFC 6585（429 など追加ステータス）

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

  1. Retry-After Inspect — Retry-After を解析して再試行待機を確認
  2. Response Headers Parser — レスポンスヘッダーを構造化解析
  3. Location Inspect — Location ヘッダーを解析して遷移先URLを分解
  4. Redirect Chain Inspect — リダイレクト連鎖を解析してループ/無駄遷移を確認
  5. 429/503で再試行が止まらない時の診断手順 — Retry-After の秒/日時解釈とクライアント実装差を切り分け、過剰再試行を抑える
  6. nosniffでJS/CSSがブロックされる時の診断手順 — Content-Type と nosniff の不一致、404/302混入、配信経路の上書きを切り分ける
  7. Response Headers系ツールの使い分け — Retry-After / Server-Timing / Link / Content-Type / nosniff を症状別に切り分ける
  8. HTTP Header Parser — 生ヘッダーを構造化して一覧化

レスポンスヘッダー診断

生ヘッダーから Retry-After / Server-Timing / Link / Content-Type を段階的に解析

リダイレクト

HTTPステータスと Location 連鎖から遷移不具合を切り分け