HTTPステータスコード一覧
HTTPステータスコードの意味を素早く確認
1xx 情報(4)
継続。クライアントはリクエストの残りを送信すべき。
プロトコル切替。サーバーがプロトコル変更を理解した。
処理中。サーバーがリクエストを受信し処理中。
早期ヒント。最終レスポンス前にヘッダーを返す。
2xx 成功(10)
成功。リクエストが正常に処理された。
作成済み。新リソースが作成された。POSTでよく使用。
受理済み。処理受け付け済み、未完了。
非権威的情報。情報が第三者由来の可能性。
コンテンツなし。成功だがレスポンス本体なし。DELETEで使用。
コンテンツリセット。ドキュメントビューをリセット。
部分コンテンツ。部分的なGETに成功。
マルチステータス。複数ステータス含むレスポンス（WebDAV）。
既に報告済み。以前のレスポンスで列挙済み（WebDAV）。
IM使用済み。インスタンス操作で完了済み。
3xx リダイレクト(8)
複数選択。複数の表現が利用可能。
恒久的移動。新しいURLを使用すべき。
発見。一時的に別URLにある。
他を参照。GETで別URLから取得。
未変更。キャッシュ版を使用。
プロキシ使用（廃止予定）。
一時リダイレクト。同じメソッドで別URLへ。
恒久リダイレクト。同じメソッドで永久に別URLへ。
4xx クライアントエラー(29)
不正リクエスト。サーバーが理解できない形式。
認証必要。認証が必要。
支払い必要。将来用に予約済み。
禁止。サーバーは理解したが拒否。
未検出。リソースが存在しない。最も一般的。
メソッド不許可。メソッドがサポートされていない。
受入不可。Acceptヘッダーに一致しない。
プロキシ認証必要。プロキシで認証が必要。
リクエストタイムアウト。待機時間超過。
競合。サーバー状態と競合。
消滅。リソースが永久に削除された。
長さ必要。Content-Lengthが必要。
前提条件失敗。条件ヘッダーが満たされない。
ペイロード過大。リクエスト本体が大きすぎる。
URI過長。URLが長すぎる。
サポート外メディアタイプ。形式未対応。
範囲無効。要求範囲が無効。
期待失敗。Expectヘッダーが満たされない。
私はティーポット。RFC 2324のジョーク。
誤送信リクエスト。間違ったサーバーへ送信。
処理不可エンティティ。構文正しいが意味エラー。
ロック済み。リソースがロックされている（WebDAV）。
依存失敗。前のリクエストが失敗（WebDAV）。
早すぎる。再再生リクエストの可能性。
アップグレード必要。TLSへ切り替え。
前提条件必要。条件ヘッダーが必要。
リクエスト過多。レート制限超過。
ヘッダー過大。リクエストヘッダーが大きすぎる。
法的理由で利用不可。
5xx サーバーエラー(11)
内部エラー。予期しない状況に遭遇。
未実装。機能がサポートされていない。
不正ゲートウェイ。上流から無効なレスポンス。
サービス利用不可。一時的に処理できない。
ゲートウェイタイムアウト。上流待機超過。
HTTPバージョン未対応。
バリアントも交渉。設定エラー。
ストレージ不足（WebDAV）。
ループ検出（WebDAV）。
拡張なし。さらなる拡張が必要。
ネットワーク認証必要。
HTTPステータスコードとは？
HTTP ステータスコード表は、ブラウザー、クローラー、アプリ、API クライアントからのリクエストに対してサーバーが返す応答コードを確認するための資料です。2xx は成功、3xx はリダイレクト、4xx はクライアント側の問題、5xx はサーバー側の障害を示すことが多いですが、細かな違いが重要です。401 と 403、404 と 410、301 と 302 はそれぞれ意味も対応も異なります。開発、SEO、サポート対応で原因を切り分け、次に確認すべき箇所を判断する助けになります。
使い方
クイックリファレンス
- ステータスコードカードをクリックしてコピー
- 検索ボックスで特定のコードを素早く検索
- カテゴリタグをクリックしてステータス種別で絞り込み
- コードにカーソルを合わせると詳細な説明が表示
デバッグ時の注意点
- まずステータスファミリーを確認：2xx成功、3xxリダイレクト、4xxクライアント側の問題、5xxサーバー側の問題。
- APIデバッグでは、ステータスコードをレスポンス本文、ヘッダー、リクエストメソッド、サーバーログと照合してください。コードだけでは全体の問題を説明することはほとんどありません。
利用シーン
仕組み
HTTPステータスコードは、レスポンス開始行に返される3桁の整数で、HTTPセマンティクス仕様によって定義されます。現在の規範的参照はRFC 9110（HTTP Semantics、2022年6月）であり、以前のRFC 7231シリーズを廃止し、RFC 9111（Caching）、RFC 9112（HTTP/1.1）、RFC 9113（HTTP/2）、RFC 9114（HTTP/3）に拡張があります。最初の桁がレスポンスクラスを定義するため、未認識のコードでも予測可能な処理が可能です。1xxは情報提供（暫定的、最終レスポンスが後に続く）、2xxは成功、3xxはリダイレクト（ユーザーエージェントによる追加アクションが必要）、4xxはクライアントエラー（リクエストが不正または処理不能）、5xxはサーバーエラーです。キャッシュや中間プロキシは、未知のコードを汎用クラスコードx00（例：未知の4xxは400として処理）として扱うことが求められており、これがステータスファミリーをプロプライエタリや拡張コードでも意味あるものにしています。 リダイレクトコードは、歴史的に意図と乖離したメソッド保持セマンティクスを持ちます。RFC 9110セクション15.4でこの区別が明確化されています。301 Moved Permanentlyと302 FoundはPOSTをGETに書き換えることがあり（1990年代後半にすべてのブラウザが収束した事実上の動作で、RFC 7231で正式化）、307 Temporary Redirectと308 Permanent Redirectはユーザーエージェントに同じメソッドと本文の再送を要求します。SEOツールは通常、301と308でPageRank相当の重みを転送し、302/307は元のURLのシグナルを保持するものとして扱います。条件付きコードの304 Not Modifiedと412 Precondition FailedはリクエストのIf-None-Match/If-Modified-Since/ETag/Last-Modifiedヘッダーに依存し、206 Partial ContentはRangeヘッダーにContent-Rangeヘッダーと、複数の範囲が要求された場合はmultipart/byteranges本文で応答します。 4xxと5xxクラスはヘッダーに契約詳細を持ちます。401 Unauthorizedは受け入れるスキーム（Bearer、Basic、Digest、Negotiate）を列挙したWWW-Authenticateチャレンジを含まなければならず、これを欠くレスポンスは技術的に不正な形式です。405 Method Not Allowedはサポートされるメソッドを列挙したAllowヘッダーを含まなければなりません。429 Too Many Requests、503 Service Unavailable、およびRetry-After付きの301/307/308は、RFC 9110セクション10.2.3に従い、秒数（Retry-After: 120）またはHTTP日付（Retry-After: Wed, 21 Oct 2025 07:28:00 GMT）のいずれかで遅延を通知できます。RFC 9110は305 Use Proxyと306（予約済み/未使用）を非推奨とし、418 I'm a teapotをRFC 2324/RFC 7168のジョークコードとして文書化し、1xxを再編してHTTP/1.1レイヤーで必須なのは100 Continueと101 Switching Protocolsのみとし、102 Processingと103 Early Hints（RFC 8297）は主にCDNエッジロジックで公開されるオプションの拡張です。
- 規範的参照：RFC 9110（HTTP Semantics、2022年6月）がRFC 7230-7235を廃止。拡張はRFC 9111（Caching）、9112（HTTP/1.1ワイヤーフォーマット）、9113（HTTP/2）、9114（HTTP/3）に存在
- 未知のコードはクラスコードに劣化（x00）：未知の4xxは400と同様にキャッシュ・描画され、未知の5xxは500と同様。これにより最初の桁が契約となる
- メソッド保持：301/302は歴史的にPOST→GET書き換えを許容（1990年代初頭のブラウザの乖離後に正式化）。307/308は同じメソッドと本文の再送を要求。恒久的なAPIエンドポイント移動には308を使用
- 401 UnauthorizedはWWW-Authenticateを、405 Method Not AllowedはAllowヘッダーを必ず含む必要がある。これらのヘッダーの欠落は仕様違反であり、正常なHTTPクライアントを壊す
- Retry-After（RFC 9110セクション10.2.3）は429/503/301/307/308で使用可能。デルタ秒（Retry-After: 120）またはHTTP日付（Retry-After: Wed, 21 Oct 2025 07:28:00 GMT）を受け入れ、クライアントは両方の形式をパースすべき
- 条件付きキャッシュ：304 Not ModifiedはIf-None-Match/If-Modified-Sinceの一致に本文なしで応答。206 Partial ContentはRangeに対してContent-Rangeと部分本文またはmultipart/byterangesドキュメントで応答
- RFC 9110は305 Use Proxyと306（予約済み）を非推奨とし、RFC 2324/RFC 7168由来の418 I'm a teapotをジョークとして保持。102 Processing/103 Early Hints（RFC 8297）は多くのプロキシが除去するオプションの1xx拡張
使用例
2xx 成功 - 200 OK と 204 No Content
200 OK GET /api/users -> レスポンスボディを返す
201 Created POST /api/posts -> 新リソースを Location ヘッダーに記載
204 No Content DELETE /api/posts/42 -> 成功、ボディは空
206 Partial 動画ストリーミングや再開可能なダウンロードでの Range リクエスト
RFC: RFC 7231 セクション 6.3 が 2xx 成功ステータスコードを定義3xx リダイレクト - 301 vs 302 vs 304
301 Moved Permanently -> SEO に安全、ブラウザは新しい URL を永続的にキャッシュ
302 Found -> 一時的なリダイレクト、ターゲットをキャッシュしない
304 Not Modified -> キャッシュされたコピーが有効 (ETag/Last-Modified が一致)
307 Temporary Redirect -> 302 と同様だがメソッドを変更してはならない (POST は POST のまま)
308 Permanent Redirect -> 301 と同様だがリクエストメソッドを保持
RFC: RFC 7231 セクション 6.4 が 3xx リダイレクションコードを定義
RFC: RFC 7232 セクション 4.1 が 304 Not Modified のセマンティクスを定義4xx クライアントエラー - 認証 vs 認可
400 Bad Request 不正な JSON、必須フィールドの欠落
401 Unauthorized トークンが欠落または無効 - 呼び出し元は認証が必要
403 Forbidden 認証済みだがこのリソースへのアクセスは許可されていない
404 Not Found リソースが存在しない (またはセキュリティ上、存在しないと装う)
409 Conflict 重複キー、楽観的ロックのバージョン不一致
429 Too Many Reqs レート制限に到達 - Retry-After ヘッダーを参照
RFC: RFC 7231 セクション 6.5 が 4xx クライアントエラーコードを定義
RFC: RFC 6585 セクション 4 が 429 Too Many Requests を定義5xx サーバーエラー - 上流のデバッグ
500 Internal Server Error アプリコード内の未処理例外 - ログを確認
502 Bad Gateway Nginx/上流がバックエンドから無効なレスポンスを受信
503 Service Unavailable メンテナンス、過負荷、またはアプリ起動中
504 Gateway Timeout プロキシのタイムアウト内に上流が応答しなかった
RFC: RFC 7231 セクション 6.6 が 5xx サーバーエラーコードを定義
クイック判定: 5xx = サーバー側の問題、4xx = 呼び出し元の問題複数のステータスコードを示す curl の実例
$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
$ curl -I https://example.com/admin
HTTP/2 401
www-authenticate: Bearer realm="api"
$ curl -X POST https://example.com/api/posts -d '{}'
HTTP/2 422
content-type: application/json
注意: 422 Unprocessable Entity はバリデーションエラーに使用される WebDAV 拡張 (RFC 4918)よくある質問
1xx、2xx、3xx、4xx、5xx の各クラスは何を意味しますか？
1xx は情報提供（実際には稀）です。2xx はリクエストが成功したことを意味します。3xx はリダイレクトで、クライアントは別の URL に従うべきです。4xx はクライアント側の問題（不正なリクエスト、認証情報の欠落、リソースの欠落）です。5xx はサーバー側の問題（リクエストは正常に見えたがサーバーが処理に失敗）です。ログ行を読むときはまずクラスを確認してください。
301 と 302 の違いは何ですか？
301 Moved Permanently は、リソースが恒久的に移動したことをクライアントと検索エンジンに伝えます。ブラウザはリダイレクトを積極的にキャッシュし、SEO のリンクエクイティが新しい URL に転送されます。302 Found は一時的なリダイレクトで、クライアントは長期間キャッシュしないことになっています。リクエストメソッドを保持しなければならない恒久リダイレクトには 308 を、同じ条件下の一時リダイレクトには 307 を使用してください。
401 と 403 はいつ返すべきですか？
401 Unauthorized はクライアントが認証していない、または送信した認証情報が無効であることを意味します。レスポンスには WWW-Authenticate ヘッダーを含めるべきです。403 Forbidden はサーバーがクライアントの身元を理解した上で、いずれにしてもこのリソースの提供を拒否することを意味します。401 はログインで解決しますが、403 はログインしても解決しません。
もう存在しないリソースには 404 と 410 のどちらを使うべきですか？
404 Not Found は「見つけられない、どこかに存在するかもしれないし後で戻ってくるかもしれない」を意味します。410 Gone は「このリソースはここにあったが意図的に削除され、もう探さないでほしい」を意味します。検索エンジンは 410 の URL をインデックスから 404 より早く削除するため、再クロールしてほしくない引退ページには 410 が正しい選択です。
API のデバッグ時にステータスコードをどう読み取るべきですか？
まずクラスを読み（4xx と 5xx でどちら側を見るべきかわかります）、次に具体的なコード、最後にレスポンスボディを読みます。ボディには通常、実際のエラーメッセージと内部エラーコードが含まれます。HTTP ステータスはカテゴリにすぎません。Retry-After、WWW-Authenticate、Location などのヘッダーも常にステータスと併せて確認してください。
2xx 以外のコードは SEO に悪影響を与えますか？
影響するものとしないものがあります。長期間の 5xx レスポンスはサイトの不安定さを示し、検索エンジンは最終的にクロール頻度を減らします。301/308 リダイレクトはリンクエクイティを引き継ぎますが、302/307 は引き継ぎません。410 はインデックスからページを削除しますが、404 はより長く残ります。ソフト 404 ボディ（実際の「見つからない」ページが 200 を返すもの）は本物の 404 より SEO に悪影響があります。空のページでインデックスが埋まるためです。
418、451 などの珍しいコードは何のためのものですか？
418「I'm a teapot」は RFC 2324 のエイプリルフールの有名なコードです。実サービスは本番で返すべきではありません。451 Unavailable For Legal Reasons は、法的要請によりリソースがブロックされていることを示します（ブラッドベリの『華氏 451 度』にちなむ）。429 Too Many Requests はレート制限を示し、Retry-After ヘッダーと組み合わせるべきです。503 Service Unavailable は計画的なメンテナンスに対する正しいコードです。