🌐 Web

HTTPステータスコード一覧

100番台から500番台までのHTTPレスポンスコードの意味と違い
データの読み方

HTTPステータスコードを100番台のグループで読み解きます

HTTPステータスコードは、サーバーがリクエストをどのように処理したかを示す標準レスポンスコードです。1xx、2xx、3xx、4xx、5xxの各グループの意味を先に理解すると、404、429、451、500など個別のエラーも区別しやすくなります。

読み方

コード番号、英語名、日本語の説明、関連キーワードで検索し、100番台のグループまたは主要・特殊コードのフィルターで範囲を絞り込めます。コード番号を押すと該当行へ直接移動します。

このページで見られること
  • IANA HTTP Status Code Registryに基づく登録コードと標準reason phrase
  • 100番台クラスごとの意味、発生する状況、確認すべき点、関連コード
  • 451、429、404、500、503など検索需要の高いコードの詳しい説明
データ基準

IANA HTTP Status Code RegistryとRFC 9110、RFC 7725、RFC 6585などのIETF文書を基準に整理しています。

このページはHTTPプロトコルの意味を説明する参考資料であり、法律・セキュリティ・運用上の判断には各サービス環境と公式文書もあわせて確認してください。

登録コード 64
ステータスクラス 5
主要コード 25
特殊コード 21
1xx 情報応答 5 2xx 成功 10 3xx リダイレクト 9 4xx クライアントエラー 29 5xx サーバーエラー 11
🌐 HTTPステータスコード全一覧
全64コード

1xx Informational

リクエストを受け取り、処理が継続中であることを示す中間応答です。

5
意味 主な状況 確認すべき点
100 Continue RFC 9110 リクエストヘッダーは受信済みで、クライアントはリクエスト本文の送信を続けてもよいことを示します。 大きなリクエスト本文を送る前に、サーバーが続行可能かを確認する場合に使われます。 Expect: 100-continue ヘッダーと、サーバー側のアップロード処理フローを確認します。 関連: 417
101 Switching Protocols RFC 9110 クライアントが要求したプロトコル切り替えをサーバーが受け入れたことを示します。 HTTP接続をWebSocketなど別のプロトコルへアップグレードするときに見られます。 Upgradeヘッダー、Connectionヘッダー、プロキシがアップグレードを正しく転送しているかを確認します。 関連: 426
102 Processing RFC 2518 リクエストは受信され処理中ですが、最終応答はまだ準備できていないことを示します。 処理に時間がかかるWebDAVリクエストで、クライアント側のタイムアウトリスクを下げるために使われることがあります。 最終応答が別途届くか、中間応答をクライアントが安全に無視できるかを確認します。 関連: 207, 208
104 一時的 Upload Resumption Supported IANA temporary registration アップロード再開への対応を示す、一時登録されたステータスコードです。 大容量アップロードが中断された後、Rangeベースの再開を交渉する実験的なフローで現れることがあります。 IANAの一時登録であるため、本番利用前にクライアントとサーバーの対応状況を確認します。 関連: 100, 201

2xx Success

リクエストが正しく理解され、正常に処理されたことを示す応答です。

10
意味 主な状況 確認すべき点
201 Created RFC 9110 リクエストが成功し、新しいリソースが作成されたことを示します。 投稿、注文、アカウント、ファイルなどのリソースをPOSTリクエストで作成する場合に適しています。 新しいリソースの場所がLocationヘッダーまたは応答本文で提供されているかを確認します。 関連: 200, 202, 204
202 Accepted RFC 9110 リクエストは受理されましたが、処理はまだ完了していません。 非同期ジョブ、キュー処理、結果が後で確定するバッチ操作で使われます。 可能であれば、ステータスURL、ジョブID、再試行方法を応答に含めます。 関連: 200, 201, 204
203 Non-Authoritative Information RFC 9110 プロキシまたは変換レイヤーが、オリジンサーバーの200応答を変更して転送したことを示します。 中間層が変換済みの表現やメタデータを提供する場合に使われることがあります。 元の応答、変換ポリシー、Warningヘッダー、キャッシュヘッダーをあわせて確認します。 関連: 200, 214
204 No Content RFC 9110 リクエストは成功しましたが、応答本文はありません。 削除、保存、切り替えなどが成功し、応答本文や画面遷移が不要な場合に使われます。 204応答では本文を送らず、クライアントが空の応答をエラー扱いしないことを確認します。 関連: 200, 205
205 Reset Content RFC 9110 リクエストは成功し、クライアントは入力画面をリセットしてよいことを示します。 フォーム送信後、同じ画面で入力フィールドをクリアするよう伝える場合に使われることがあります。 実務ではまれなため、ユーザーインターフェースのリセットが本当に望ましい体験かを確認します。 関連: 204
207 Multi-Status RFC 4918 1つのリクエスト内の複数のサブ操作について、それぞれの状態を含むWebDAV応答です。 複数リソースをまとめて処理し、各リソースごとに成功または失敗の結果が必要な場合に使われます。 リソースごとの状態を応答本文から解析します。通常のREST APIでは独自の結果形式を使うことが多いです。 関連: 102, 208
208 Already Reported RFC 5842 WebDAVのbindingリソースがすでに報告済みで、重複して返されないことを示します。 同じリソースが複数のパスから参照されるWebDAV応答で、重複リストを減らすために使われます。 WebDAVクライアントが207応答本文とあわせて208を処理できるかを確認します。 関連: 207
226 IM Used RFC 3229 サーバーがinstance manipulation (IM)を適用した結果を返したことを示します。 差分エンコーディングなど、変更差分ベースの応答のために定義されています。 A-IMとIMヘッダーを使う特殊なキャッシュ・転送フローが必要なため、通常のWebサイトではほとんど使われません。 関連: 200, 206

3xx Redirection

リクエストを完了するために、別の場所または追加の操作が必要であることを示す応答です。

9
意味 主な状況 確認すべき点
300 Multiple Choices RFC 9110 要求されたリソースに複数の表現または選択肢があることを示します。 同じリソースについて、言語、形式、バージョンなどの候補からユーザーまたはクライアントが選ぶ必要がある場合に使われます。 実務では、301、302、303、307、308のように明確なLocationヘッダーを持つリダイレクトの方が一般的です。 関連: 301, 302
303 See Other RFC 9110 リクエストの結果を、別のURLからGETで取得すべきことを示します。 フォーム処理後に結果ページや完了ページへ送るPOST/Redirect/GETパターンで有用です。 メソッドがGETに変わることを理解し、フォームの重複送信防止フローを確認します。 関連: 302, 307
305 Use Proxy RFC 9110 クライアントにプロキシ利用を指示する古いステータスコードで、現在はセキュリティ上の理由から非推奨です。 現代のWebでは未使用として扱うのが安全です。 新規実装では使わず、プロキシポリシーは設定またはネットワーク層で扱います。 関連: 407
306 Unused RFC 9110 過去に定義されていましたが、現在は予約済みで未使用のステータスコードです。 通常のサーバー応答として使わないでください。 ログに現れる場合は、中間装置、テストコード、非標準実装を確認します。 関連: 305
307 Temporary Redirect RFC 9110 リクエストメソッドと本文を維持する必要がある一時リダイレクトです。 POST、PUTなどのメソッドを維持したまま一時的な場所へ送る必要がある場合、302より明確です。 クライアントがメソッドをGETに変えないこと、Location先が同じリクエストを処理できることを確認します。 関連: 302, 308

4xx Client Error

構文、認証、認可、リソース状態など、クライアント側の条件によりリクエストを処理できないことを示す応答です。

29
意味 主な状況 確認すべき点
402 Payment Required RFC 9110 支払いが必要な状況のために予約されていますが、標準的な意味は広く確立されていません。 一部のAPIや決済サービスでは、支払い、クレジット、サブスクリプションの問題に非公式に使われます。 402の実際の意味と復旧手順は、サービス固有のAPIドキュメントで確認します。 関連: 403, 429
405 Method Not Allowed RFC 9110 リソースは存在しますが、要求されたHTTPメソッドは許可されていません。 GET専用URLにPOSTを送った場合や、APIルートが別のメソッド向けに設定されている場合に発生します。 Allowヘッダー、ルーターのメソッド定義、プロキシのメソッド制限ポリシーを確認します。 関連: 404, 501
406 Not Acceptable RFC 9110 クライアントのAcceptヘッダーに合う表現をサーバーが提供できないことを示します。 クライアントが未対応のメディアタイプ、言語、エンコーディングだけを要求した場合に起こります。 Accept、Accept-Language、Accept-Encodingヘッダーと、サーバーのコンテンツネゴシエーション設定を確認します。 関連: 415
407 Proxy Authentication Required RFC 9110 クライアントがプロキシを利用する前に認証が必要です。 企業ネットワーク、セキュリティプロキシ、ゲートウェイ認証環境で見られます。 Proxy-Authenticate、Proxy-Authorizationヘッダーと、ネットワークプロキシ設定を確認します。 関連: 401, 305
408 Request Timeout RFC 9110 サーバーが待機できる時間内に、クライアントから完全なリクエストを受信できなかったことを示します。 低速ネットワーク、大容量アップロード、keep-aliveタイムアウト、ロードバランサーのタイムアウトで発生することがあります。 クライアントの再試行動作、アップロードサイズ、keep-alive設定、プロキシのタイムアウト値を確認します。 関連: 504
409 Conflict RFC 9110 リクエストがリソースの現在の状態と競合していることを示します。 重複作成、バージョン競合、同時編集、不正な状態遷移でよく使われます。 リソースバージョン、ETag、重複キー、業務上の状態遷移ルールを確認します。 関連: 412, 422
411 Length Required RFC 9110 Content-Lengthが含まれていないため、サーバーがリクエストを拒否したことを示します。 サーバーまたはゲートウェイがリクエスト本文の長さを事前に知る必要がある場合に起こります。 Content-Length、Transfer-Encoding、クライアントライブラリのストリーミング動作を確認します。 関連: 413
412 Precondition Failed RFC 9110 If-Matchなど、条件付きリクエストの前提条件が失敗したことを示します。 同時編集の防止、キャッシュ再検証、ETagベースの更新で使われます。 If-Match、If-None-Match、If-Unmodified-Sinceを現在のリソースバージョンと比較します。 関連: 304, 409, 428
414 URI Too Long RFC 9110 リクエストURIが、サーバーで処理できる長さを超えています。 非常に長いクエリ文字列、不具合のあるリダイレクトループ、GET URLへ過剰なデータを入れた場合に起こります。 長いデータはPOST本文へ移し、プロキシとサーバーのURI長制限を確認します。 関連: 400, 431
415 Unsupported Media Type RFC 9110 サーバーがリクエスト本文のメディアタイプをサポートしていません。 JSON APIが誤ったContent-Typeを受け取った場合や、未対応のファイル形式がアップロードされた場合に発生します。 Content-Type、拡張子、multipart設定、サーバーパーサーが登録されているかを確認します。 関連: 406, 422
416 Range Not Satisfiable RFC 9110 要求されたRangeがリソースサイズに合わないため、提供できません。 再開可能ダウンロードやストリーミングで、要求範囲がファイルサイズ外にある場合に発生します。 Rangeヘッダー、Content-Range、ファイルサイズ、古いキャッシュメタデータを確認します。 関連: 206
417 Expectation Failed RFC 9110 サーバーがExpectヘッダーで示された期待条件を満たせないことを示します。 サーバーまたはプロキシがExpect: 100-continueなどの期待条件に対応していない場合に起こります。 Expectヘッダーを削除するか、サーバーが100 Continue処理に対応しているかを確認します。 関連: 100
423 Locked RFC 4918 対象リソースがロックされているため、リクエストを処理できません。 ファイル編集ロック、共同編集ドキュメント、WebDAVリソースロックで使われます。 ロック所有者、ロック期限、解除API、競合処理ポリシーを確認します。 関連: 409, 424
424 Failed Dependency RFC 4918 依存していた先行操作が失敗したため、現在のリクエストを実行できません。 複数の操作が相互依存し、先の操作の失敗が後続操作の失敗につながる場合に使われます。 失敗した先行操作と依存関係を応答本文で明確にします。 関連: 207, 423
426 Upgrade Required RFC 9110 サーバーがリクエストを処理する前に、クライアントへプロトコルのアップグレードを要求しています。 HTTPバージョン、TLS、WebSocketなど、特定のアップグレードが必要な場合に使われます。 Upgradeヘッダー、対応プロトコル、プロキシがアップグレードリクエストを転送するかを確認します。 関連: 101
428 Precondition Required RFC 6585 サーバーが条件付きリクエストヘッダーを要求していることを示します。 If-Matchなどの条件を必須にし、同時編集による更新消失を防ぐために使われます。 クライアントにETagを読み取りIf-Matchで更新するよう伝えるAPIドキュメントとエラーメッセージを用意します。 関連: 412, 409

5xx Server Error

サーバーまたはゲートウェイが、本来は有効なリクエストを処理できなかったことを示す応答です。

11
意味 主な状況 確認すべき点
501 Not Implemented RFC 9110 サーバーがリクエスト処理に必要な機能をサポートしていないことを示します。 未対応のHTTPメソッド、または未実装のサーバー機能が要求された場合に使われます。 405はそのリソースでメソッドが禁止されている状態で、501はサーバーがその機能自体を知らない状態に近いです。 関連: 405
505 HTTP Version Not Supported RFC 9110 サーバーがリクエストで使われたHTTPバージョンをサポートしていないことを示します。 古いクライアント、壊れたプロキシ、サーバー側のHTTPバージョン制限で起こることがあります。 クライアントのHTTPバージョン、TLS/ALPNネゴシエーション、プロキシのプロトコル変換設定を確認します。 関連: 426
506 Variant Also Negotiates RFC 2295 透過的コンテンツネゴシエーションの設定エラーにより、内部的なネゴシエーションループが発生したことを示します。 サーバーのコンテンツネゴシエーション設定に問題があり、選ばれたvariant自体もネゴシエーション対象になっている場合に使われます。 コンテンツネゴシエーション設定、variantマッピング、サーバー設定ファイルを確認します。 関連: 300, 406
507 Insufficient Storage RFC 4918 リクエストを完了するために必要なストレージをサーバーが確保できません。 WebDAV、ファイルアップロード、ストレージクォータ超過、ディスク容量不足で起こることがあります。 ディスク使用量、一時ファイルストレージ、ユーザークォータ、オブジェクトストレージエラーを確認します。 関連: 413, 500
508 Loop Detected RFC 5842 リクエスト処理中にサーバーが無限ループを検出したことを示します。 WebDAVのDepthリクエストや内部参照構造に循環が含まれる場合に使われることがあります。 リソース参照グラフ、シンボリックリンク、WebDAV bindings、再帰制限を確認します。 関連: 508
510 Not Extended RFC 2774 リクエストを処理するには追加の拡張が必要です。 HTTP拡張フレームワークで定義されていますが、通常のWebサービスではほとんど使われません。 関連するAPIまたはサーバー拡張要件のドキュメントを確認します。 関連: 501

よく検索されるHTTPコードを詳しく見る

表で素早く見つけたあと、下の説明で似たコードとの違いを確認できます。

HTTP 451 Unavailable For Legal Reasons

451は、法的理由によりアクセスできないことを明確に示す4xxステータスコードです。

HTTP 451は、サーバー、検索エンジン、プロキシ、中間装置が、法的要求のためにリソースを提供できない場合に使われます。単なる権限不足ではなく、裁判所命令、政府要請、著作権上の措置、地域規制など、外部の法的要件が制限の背景にあることを示します。

検索結果やブラウザで451を見た場合、そのページが技術的に消えたと考えるより、現在のリクエスト地点またはサービス方針において法的理由で提供されていないと理解する方が正確です。可能であれば、サービス提供者は応答本文でブロック主体や法的要求を説明し、利用者が状況を理解できるようにするべきです。

403との違い 403は権限またはサーバーポリシーによりアクセスが禁止されていることを示します。451は、その制限理由が法的要件である場合に使われます。
404との違い 404はリソースが見つからない、または存在を隠していることを示します。451は、リソースが存在する、または把握されているものの、法的理由で提供できない意味がより強くなります。
410との違い 410はリソースが恒久的に削除されたことを示します。451は、リソースが削除されたかどうかに関係なくアクセスが制限されていることを示します。

HTTP 429 Too Many Requests

429はリクエスト上限を超えたことを示し、特にAPIやログイン保護でよく使われます。

429は、クライアントが短時間に多すぎるリクエストを送信した場合に使われます。利用上限、bot対策、ログイン試行制限、無料プランのAPIクォータなど、サービス安定性と不正利用防止のポリシーに関係します。

サーバーは可能であればRetry-Afterやレート制限ヘッダーを提供し、クライアントがいつ再試行すべきか分かるようにするべきです。クライアント側では、すぐに同じリクエストを繰り返すのではなく、exponential backoffやキューイングを使います。

403との違い 403はアクセス自体が禁止されていることを示します。一方429は、時間の経過や利用量の回復後に再び許可される可能性があります。
503との違い 503はサーバーが一時的にリクエストを処理できないことを示します。429は、特定のクライアントまたはトークンがリクエスト割り当てを超えたことをより具体的に示します。

HTTP 404 Not Found

404は最も一般的なWebエラーコードで、まずURLとコンテンツ状態を確認する必要があります。

404は、サーバーが要求されたリソースを見つけられなかったことを示します。利用者は通常、URLの入力ミスや削除済みページと解釈しますが、保護されたリソースの存在有無を明かさないためにサーバーが404を返すこともあります。

検索上の可視性を保つには、壊れた内部リンク、古いサイトマップ、削除コンテンツの代替ページ不足を確認します。明確な代替先がある場合は301が適切なことがあり、リソースが恒久的に削除された場合は410も選択肢になります。

410との違い 404は一般的な見つからない応答です。一方410は、リソースが以前は存在し、現在は恒久的になくなったことを示します。
403との違い 403はサーバーがリソースを見つけたうえでアクセスを拒否していることを示します。404は見つからない、またはサーバーが存在有無を明かしていないことを示します。

HTTP 500 Internal Server Error

500は、リクエスト処理中に例外や失敗が発生したことを示す広範なサーバー側エラーです。

500は、クライアントのリクエスト形式ではなく、サーバー側ロジック、設定、依存サービス、データ処理で問題が発生した場合に使われます。詳細な例外をユーザーに公開しないため、汎用的なエラーコードとして返されることがよくあります。

運用では、まず直近のデプロイ、アプリケーションログ、エラートラッキング、データベース接続、不足している環境変数を確認します。同じリクエストで500が繰り返し発生する場合は、入力バリデーションや例外処理の経路も調べます。

502との違い 500は現在のサーバー内部のエラーです。502はゲートウェイが上流サーバーから無効な応答を受け取ったことを示します。
503との違い 503はメンテナンスや過負荷など、一時的に利用できない状況により適しています。

HTTP 503 Service Unavailable

503は、サーバーが一時的にリクエストを処理できないことを示します。

503は、メンテナンス、過負荷、デプロイ、バックエンド障害、オートスケーリング遅延により、サービスが一時的にリクエストを受け付けられない場合に使われます。検索エンジンに対しては一時的な問題を示せるため、予定メンテナンスでは500より503の方が適していることが多いです。

可能であればRetry-Afterヘッダーを含め、クライアントがいつ再試行すべきかを示します。あわせて、ロードバランサーのヘルスチェック、キュー滞留、インスタンス数、依存サービスの障害を確認します。

500との違い 500は内部エラーを広く扱います。一方503は、サーバーが一時的にリクエストを処理できないことをより明確に示します。
429との違い 429はリクエスト元のクライアントが多すぎるリクエストを送ったことを示します。503はサービス全体、またはその一部の処理能力が不足している状況に近いです。

HTTPステータスコードは通信上の意味を標準化した信号です。実際の原因は、アプリケーションログ、プロキシ/CDN設定、認証ポリシー、キャッシュヘッダー、デプロイ履歴とあわせて確認する必要があります。

出典とライセンス

データの出典と利用条件

このページは、以下の元提供者による公開データをもとにしています。各データは、元提供者のライセンスまたは利用条件に従います。

出典 データ/API 利用条件 Onul Worksでの処理
IANA HTTP Status Code Registry 利用条件 IANA登録コードとIETF RFCの説明を、100番台のグループ、検索タグ、主要コードの説明として再構成します。
IETF / RFC Editor HTTP Semantics and status code RFCs 利用条件 IANA登録コードとIETF RFCの説明を、100番台のグループ、検索タグ、主要コードの説明として再構成します。

Onul Worksによる正規化、翻訳、統合、キャッシュ、単位換算は、元提供者による保証または承認を意味するものではありません。