HTTPステータス一覧
HTTPステータスコード（1xx〜5xx）の意味を一覧表示し、番号やキーワードで絞り込めます。開発・デバッグ時の参照に。検索はブラウザ内だけで完結します。
番号・日本語名で絞り込む手順
検索欄に番号かキーワードを入力すると、一致する行だけが残ります。番号の判定は前方一致ではなく部分一致なので、40 と入れると 400・401・403・404・408・409 の6件、50 なら 500・502・503・504 の4件が並びます。例チップを押すとその番号で即フィルタし、「すべて表示」で解除します。入力はブラウザ内だけで処理され、外部へ送信されません。
この日本語版が表示するのはコード番号＋日本語の短い名称（例: 404 — 未検出）で、キーワード検索の対象もその日本語名です。リクエストと入れれば「400 — 不正リクエスト」と「429 — リクエスト過多」の2件に絞れます。Not Found のような英語の正式名で引きたい場合は英語版のほうが目的に合います。
1xx〜5xx の分類と、最初に見るべき場所
百の位だけで「どこを疑うか」がほぼ決まります。個別の番号を覚える前に、この5分類と一次情報の置き場所を押さえたほうが原因の切り分けが速く済みます。
| 分類 | 意味 | まず確認する場所 |
|---|---|---|
| 1xx | 情報（処理継続中の中間応答） | アプリのログにはほぼ現れない。大きなボディを送る前の Expect: 100-continue のやり取り程度 |
| 2xx | 成功 | HTTP層は成功している。それでも動かないならレスポンスボディ側のエラー表現を見る |
| 3xx | リダイレクト・キャッシュ | Location ヘッダの行き先と、恒久（301）か一時（302）か |
| 4xx | クライアントエラー | 送った側を疑う。URL・メソッド・認証ヘッダ・ボディの形式 |
| 5xx | サーバーエラー | 送った側では直せない。サーバーのログと、間に立つプロキシやゲートウェイ |
収録している19コードと典型的な原因
この一覧は実務で遭遇しやすい19件に絞っています。表示名は検索対象と同じ日本語なので、気になる語をそのまま検索欄に貼り付けても引けます。
| コード | 表示名 | 典型的な原因と次の一手 |
|---|---|---|
| 100 | 続行 | クライアントが Expect: 100-continue を付けたときの中間応答。ボディを送ってよいという合図 |
| 200 | 成功 | 正常。「200なのに失敗している」ときはボディ内のエラーフィールドを確認する |
| 201 | 作成 | POST でリソースが作られた。作成先は Location ヘッダに入る |
| 204 | 内容なし | 成功したがボディが無い。DELETE や設定更新で多く、JSON として解析しようとすると失敗する |
| 301 | 恒久的移動 | 恒久移転。ブラウザが強くキャッシュするため、誤設定を後から巻き戻しにくい |
| 302 | 一時移動 | 一時的な移動。元のURLが正のまま残る |
| 304 | 未変更 | 条件付きリクエスト（If-None-Match / If-Modified-Since）でキャッシュが有効だった。ボディが空なのが正常 |
| 400 | 不正リクエスト | 構文レベルで解釈できない。壊れた JSON、必須パラメータの欠落、不正なヘッダ |
| 401 | 認証必要 | 認証情報が無い・期限切れ・無効。WWW-Authenticate ヘッダで要求方式を確認 |
| 403 | 禁止 | 認証は通っているが権限やIP制限で拒否。再ログインでは解決しない |
| 404 | 未検出 | パスの綴り、末尾スラッシュ、ルーティング定義。存在を隠す目的で403の代わりに返す設計もある |
| 408 | タイムアウト | クライアントがリクエストを送り切る前に待ち時間が尽きた |
| 409 | 競合 | 現在の状態と矛盾する要求。重複登録や楽観ロックの衝突 |
| 422 | 処理不能 | 構文は正しいが内容の検証に失敗。400と役割を分ける API で使われる |
| 429 | リクエスト過多 | レート制限に到達。Retry-After を見て指数バックオフで再送する |
| 500 | サーバーエラー | 捕まえ損ねた例外。一次情報はサーバー側のスタックトレース |
| 502 | 不正ゲートウェイ | プロキシが上流から不正な応答を受けた。上流の停止やプロトコル不一致 |
| 503 | 利用不可 | 過負荷やメンテナンスで一時的に応答不可。Retry-After が付くことがある |
| 504 | ゲートウェイタイムアウト | 上流の応答が制限時間内に返らなかった。処理が重いのか詰まっているのかを切り分ける |
間違えやすい組み合わせ
- 400 と 422：400は「読めない」、422は「読めたが内容が妥当でない」。バリデーションエラーを400で返す実装も多いので、API を利用する側は両方をハンドリングしておくと安全です。
- 302 と 307・308：301と302はリダイレクト時に POST を GET に変えてしまう実装が歴史的に存在します。メソッドとボディを保ったまま転送したいときは 307 Temporary Redirect / 308 Permanent Redirect を使います（この2つは一覧には収録していません）。
- 500 と 502・504：500はアプリ自身のエラー、502と504は「間に立つプロキシから見た上流の異常」です。502/504が出ているときにアプリのログだけ見ても手掛かりが無いことがあり、ロードバランサやリバースプロキシ側のログが必要になります。
- 204 と 200＋空ボディ：204はボディが存在しないことが仕様なので、クライアントが常に JSON を解析する実装だと 204 で例外になります。ステータスを見てから解析するのが安全です。
この一覧で扱わない範囲
収録は19件のみで、410 Gone や 307・308、451 Unavailable For Legal Reasons などは含みません。また Cloudflare の 520〜527 や nginx の 499 のように、特定の実装だけが返す番号も対象外です。番号の正式な定義と要件は RFC 9110（HTTP Semantics）が一次情報で、追加のコードもそれぞれ個別のRFCで定義されています。挙動が仕様と食い違うときは、まず一次情報の該当節を確認してください。