HTTPステータスコードのリスト
ページは半保護されています

この記事では、標準および注目すべき非標準のHTTPレスポンスステータスコードを列挙します。標準化されたコードはIETFによって定義され、 Request for Comments（RFC）出版物に記載され、 IANAによって管理されています。[ 1 ]その他の非標準の値は、様々なサーバーで使用されています。数値コードの後に​​続く説明文（理由フレーズ）は、ここでは典型的な値を示していますが、実際には異なる値、または省略されることがあります。

標準コード

IETFによって定義されたステータスコードを以下に示します。強調されている用語「must」、「must not」、「should」は、 RFC  2119に示されている解釈ガイドラインです。

1xx 情報応答

情報応答は、リクエストが受信され、理解され、処理中であることを示します。クライアントに最終応答を待つように通知します。メッセージには本文は含まれません。HTTP/1.0標準では1xxステータスコードが定義されていないため、サーバーは試験的な状況を除き、HTTP/1.0準拠のクライアントに1xx応答を送信して はなりません。

100 続行
サーバーはリクエストヘッダーを受信したので、クライアントはリクエストボディの送信に進むべきです（POSTリクエストのように、ボディの送信が必要なリクエストの場合）。不適切なヘッダーのためにリクエストが拒否された後に、サーバーに大きなリクエストボディを送信するのは非効率的です。サーバーにリクエストヘッダーをチェックさせるには、クライアントはExpect: 100-continue最初のリクエストでヘッダーとしてリクエストボディを送信し、100 Continueボディを送信する前にレスポンスでステータスコードを受け取る必要があります。クライアントが403（Forbidden）や405（Method Not Allowed）などのエラーコードを受け取った場合、リクエストボディを送信すべきではありません。レスポンスは、サーバーが期待される動作をサポートしていないことを示しているため（例えば、HTTP/1.0サーバーの場合）、ヘッダー417 Expectation Failedなしでリクエストを繰り返す必要があることを示していますExpect。[ 2 ] : §10.1.1
スイッチングプロトコル101
要求者はサーバーにプロトコルの切り替えを要求し、サーバーはそれに同意しました。
102 処理 ( WebDAV ; RFC 2518)
WebDAVリクエストには、ファイル操作を含む多くのサブリクエストが含まれる場合があり、リクエストの完了に長い時間がかかります。このステータスコードは、サーバーがリクエストを受信して​​処理中であるものの、まだ応答がないことを示します。[ 3 ]これにより、クライアントがタイムアウトしてリクエストが失われたと判断することを防ぎます。このステータスコードは非推奨です。[ 4 ]
103 早期ヒント (RFC 8297)
最終的なHTTPメッセージの前にいくつかのレスポンスヘッダーを返すために使用されます。[ 5 ]

2xx 成功

成功ステータスは、クライアントが要求したアクションが受信され、理解され、受け入れられたことを示します。[ 1 ]

200 OK
成功したHTTPリクエストに対する標準的なレスポンスです。実際のレスポンスは、使用されたリクエストメソッドによって異なります。GETリクエストの場合、レスポンスには要求されたリソースに対応するエンティティが含まれます。POSTリクエストの場合、レスポンスにはアクションの結果を記述または含むエンティティが含まれます。
201 作成
リクエストは満たされ、新しいリソースが作成されました。[ 6 ]
202 承認済み
リクエストは処理のために受理されましたが、処理はまだ完了していません。リクエストは最終的に処理されるかどうかは不明であり、処理開始時に拒否される可能性があります。
203 非権威情報（HTTP/1.1以降）
サーバーは、オリジンから200 OKを受信したが、オリジンの応答を変更したバージョンを返す変換プロキシ（例： Webアクセラレータ）です。 [ 2 ]：§15.3.4 [ 2 ]：§7.7
204 コンテンツなし
サーバーはリクエストを正常に処理しましたが、コンテンツを返していません。
205 コンテンツをリセット
サーバーはリクエストを正常に処理し、リクエスト元にドキュメント ビューをリセットするように要求しましたが、コンテンツを返していません。
206 部分的なコンテンツ
クライアントから送信された範囲ヘッダーが原因で、サーバーはリソースの一部のみ（バイトサービング）を配信しています。範囲ヘッダーは、HTTPクライアントが中断されたダウンロードを再開したり、ダウンロードを複数の同時ストリームに分割したりするために使用されます。
207 マルチステータス (WebDAV; RFC 4918)
これに続くメッセージ本体はデフォルトではXMLメッセージであり、サブリクエストの数に応じて複数の個別の応答コードが含まれることがあります。[ 7 ]
208 すでに報告済み (WebDAV; RFC 5842)
DAV バインディングのメンバーは、(マルチステータス) 応答の前の部分ですでに列挙されており、再度含められることはありません。
226 IM 使用 (RFC 3229)
サーバーはリソースの要求を満たし、応答は現在のインスタンスに適用された1つ以上のインスタンス操作の結果の表現です。[ 8 ]

3xxリダイレクト

3xxステータスは、クライアントがリクエストを完了するために追加のアクション（通常はURLリダイレクト）を実行する必要があることを示します。 [ 1 ]追加リクエストで使用されたメソッドがGETまたはHEADである場合、ユーザーエージェントはユーザーの操作なしに追加のアクションを実行できます。ユーザーエージェントは循環的なリダイレクトを防止する必要があります。[ 2 ] : §15.4

300個の複数選択問題
クライアントが（エージェント駆動型コンテンツネゴシエーションを介して）選択できるリソースの複数の選択肢を示します。例えば、このコードは、複数のビデオ形式の選択肢を提示したり、異なるファイル名拡張子を持つファイルを一覧表示したり、単語の意味の曖昧性解消を提案したりするために使用できます。
301 恒久的に移動
リンク先が移動され、リクエストおよび将来の同様のリクエストは指定されたURIにリダイレクトされるようになりました。クライアントがリンク編集機能を持っている場合は、リクエストURLへの参照を更新する必要があります。レスポンスは、特に指定がない限りキャッシュ可能です。GETリクエストを除き、ボディには新しいURLへのハイパーリンクを含める必要があります。GETまたはHEADリクエストを除き、クライアントはリダイレクト前にユーザーに確認する必要があります。[ 9 ]
このコードは、ユーザーをHTTPからHTTPSにアップグレードするためのベストプラクティスと考えられています。BingとGoogleはどちらも、検索エンジンの検索結果に表示されるページのURLを変更する際にこのコードを使用することを推奨しています。ただし、URLが永続的に変更され、近いうちに再度変更される予定がないことが条件です。[ 10 ] [ 11 ]
302件見つかりました
リソースがLocationヘッダーフィールドで指定された代替URL経由でアクセス可能であることを示します。HTTP/1.0仕様（理由フレーズ「Moved Temporarily」を使用）では、クライアントは同じ方法でリダイレクトする必要がありましたが[ 12 ]、一般的なブラウザはリクエストをGETに変更しました。[ 13 ]このため、HTTP/1.1（RFC  2616）では、リクエストをGETに変更することを要求する303と、元のリクエストタイプを維持する307の2つのステータスコードが追加されました。この曖昧性の解消によって明確さが向上したにもかかわらず、HTTP/1.1をサポートしていないブラウザとの互換性を維持するために、302コードは依然としてWebフレームワークで使用されています。[ 14 ] [ 2 ] : §15.4 結果として、RFC  7231 （ RFC  2616の更新版）では、ユーザーエージェントがPOSTをGETに書き換えることができるように定義が変更されました。[ 15 ]
303 See Other (HTTP/1.1 以降)
サーバーがPOSTリクエストやその他の非冪等リクエストに対してこのコードとlocationヘッダーフィールドで応答した場合、クライアントは指定された場所へのGETリクエストを発行することが期待されます。同じメソッドを使用して対象リソースへのリクエストをトリガーする場合、サーバーは代わりに307で応答します。
このコードの使用は、セマンティックウェブ理論に基づいて現実世界のオブジェクトを識別するURIへのリクエストに応答する方法の一つとして提案されています[ 16 ] （もう一つはハッシュURIの使用です[ 17 ]）。例えば、が人物「アリス」を識別する場合、サーバーがGETリクエストに200 OKで応答するのは不適切です。サーバーはアリス自身を返すことができないからです。代わりに、サーバーは303で応答し、アリスという人物の説明を提供するURIにリダイレクトします。http://www.example.com/id/alice
このコードは、HTTPベースのWeb APIを提供する際に使用されることがあります。これらのAPIは、呼び出し元に即座に応答する必要があるものの、非同期的に実行を継続する必要があります。例えば、長時間実行される画像変換などです。Web APIは、クライアントが操作のステータスを確認できるように、ステータスチェックURIを提供します。完了すると、レスポンスにはこのステータスコードと最終結果へのリダイレクトURIが含まれる場合があります。[ 18 ]
304 変更されていません
リクエストヘッダーのIf-Modified-SinceまたはIf-None-Matchで指定されたバージョン以降、リソースが変更されていないことを示します。この場合、クライアントは以前にダウンロードしたコピーを保持しているため、リソースを再送信する必要はありません。
305 プロキシを使用する (HTTP/1.1 以降)
要求されたリソースは、レスポンスで提供されるアドレスのプロキシ経由でのみ利用可能です。セキュリティ上の理由から、多くのHTTPクライアント（Mozilla FirefoxやInternet Explorerなど）はこのステータスコードに従いません。[ 19 ]
306 スイッチプロキシ
現在では使用されていません。元々は「後続のリクエストでは指定されたプロキシを使用する」という意味でした。
307 一時リダイレクト（HTTP/1.1以降）
この場合、リクエストは別のURIで再発行する必要がありますが、それ以降のリクエストでは元のURIを使用する必要があります。302の従来の実装方法とは異なり、元のリクエストを再発行する際にリクエストメソッドを変更することはできません。例えば、POSTリクエストは別のPOSTリクエストを使用して再発行する必要があります。
308 永久リダイレクト
このリクエストと今後のすべてのリクエストは、指定されたURIにリダイレクトされる必要があります。308は301の動作と似ていますが、HTTPメソッドの変更を許可しません。そのため、例えば、恒久的にリダイレクトされたリソースへのフォームの送信は、問題なく続行される可能性があります。

4xx クライアント エラー

ウィキメディアの404メッセージ
ウィキメディアの404エラー

4xxステータスコードは、クライアント側でエラーが発生したと思われる状況で使用されます。HEADリクエストに応答する場合を除き、サーバーはエラー状況の説明と、それが一時的なものか永続的なものかを示すエンティティを含める必要があります。これらのステータスコードは、あらゆるリクエストメソッドに適用可能です。ユーザーエージェントは、含まれるエンティティをユーザーに表示する 必要があります。

400 不正なリクエスト
明らかなクライアント エラー (例: 不正な要求構文、サイズが大きすぎる、要求メッセージのフレーミングが無効、要求ルーティングが不正) が原因で、サーバーは要求を処理できません。
401 権限がありません
403 Forbidden に似ていますが、認証が必要なのに失敗した、またはまだ提供されていない場合に特に使用されます。レスポンスには、要求されたリソースに適用可能なチャレンジを含む WWW-Authenticate ヘッダーフィールドが含まれている必要があります。Basicアクセス認証およびDigest アクセス認証を参照してください。401 は意味的に「認証されていない」という意味で、ユーザーは対象リソースに対する有効な認証資格情報を持っていません。
402 支払いが必要です
将来の使用のために予約されています。当初の意図は、このコードを、例えばGNU Taler [ 20 ]によって提案されたような、何らかの形のデジタル現金またはマイクロペイメントスキームの一部として使用することでしたが、それはまだ実現しておらず、このコードは広く使用されていません。Google Developers APIは、特定の開発者がリクエストの1日あたりの制限を超えた場合にこのステータスを使用します。[ 21 ] Sipgateは、アカウントに通話を開始するのに十分な資金がない場合にこのコードを使用します。[ 22 ] Shopifyは、店舗が料金を支払わず一時的に無効になっている場合にこのコードを使用します。[ 23 ] Stripeは、パラメータが正しいのに支払いが失敗した場合、たとえば不正な支払いをブロックした場合にこのコードを使用します。[ 24 ]
403 禁止
リクエストは有効でしたが、サーバーがアクションを拒否しました。これは、ユーザーがリソースへの権限を持っていない、何らかのアカウントを必要としている、または禁止されているアクション（1つしか許可されていないレコードの重複作成など）を試みたことが原因と考えられます。このコードは、リクエストがWWW-Authenticateヘッダーフィールドのチャレンジに応答することで認証を提供したにもかかわらず、サーバーがその認証を受け入れなかった場合にも通常使用されます。リクエストを再度送信しないでください。
このコードは 401 とは異なり、401 はクライアントが認証されていない場合に返され、有効な認証の後に正常な応答が返される可能性があることを意味しますが、403 は認証されたアカウントの権限が不十分であるなど、認証を提供しているにもかかわらずクライアントがリソースへのアクセスを許可されていない場合に返されます。
Apacheウェブサーバーは、ディレクトリ一覧表示が無効で、かつブラウザに返す既存ファイルを指定するためのディレクトリインデックスディレクティブがない場合、ファイルシステムディレクトリに対応するURL [ 25 ]パスのリクエストに対して403を返します。管理者の中には、 Modプロキシ拡張機能を設定してこのようなリクエストをブロックする人もいますが、この場合も403が返されます。IISも、そのサーバーでディレクトリ一覧表示が拒否された場合に同様に応答します。WebDAVでは、クライアントがPROPFINDリクエストを発行したが、必要なDepthヘッダーを発行しなかった、またはDepthヘッダーに無限大を指定した場合に403が返されます。[ 25 ]
このコードは、次の理由で発生する可能性があります。
  • 権限不足: 最も一般的な理由は、ユーザーにリソースにアクセスするために必要な権限がないことです。
  • 認証が必要: 場合によっては、特定のリソースにアクセスするためにサーバーが認証を要求することがあります。
  • IP 制限: サーバーは特定の IP アドレスまたは IP 範囲へのアクセスを制限する場合もあります。
  • サーバー設定：サーバー設定により、ウェブサイトの特定のファイル、ディレクトリ、または領域へのアクセスが禁止される場合があります。これは、設定ミスやサーバー管理者による意図的な制限が原因である可能性があります。
  • ファイアウォールまたはセキュリティソフトウェアによってブロックされています: このコードは、ファイアウォールまたはセキュリティソフトウェアによってリソースへのアクセスがブロックされた場合に表示されることがあります。これは、セキュリティポリシー、マルウェア検出、その他のセキュリティ対策によって発生する可能性があります。
  • レート制限またはリクエストが多すぎる: クライアントが短期間に過剰なリクエストを送信すると、サーバーは不正使用やサービス拒否攻撃を防ぐために 403 で応答することがあります。
404 見つかりません
要求されたリソースは見つかりませんでしたが、将来利用可能になる可能性があります。クライアントによる後続のリクエストは許可されます。
405 メソッドは許可されていません
要求されたリソースでは、リクエスト メソッドがサポートされていません (たとえば、POST経由でデータを提示する必要があるフォームの GET リクエストや、読み取り専用リソースの PUT リクエストなど)。
406 受け入れられません
要求されたリソースは、リクエストで送信されたAcceptヘッダーに従って受け入れられないコンテンツのみを生成できます。コンテンツネゴシエーションを参照してください。
407 プロキシ認証が必要です
クライアントはまずプロキシで自身を認証する必要があります。
408 リクエストタイムアウト
サーバーはリクエストの待機中にタイムアウトしました。HTTP仕様によると、「クライアントは、サーバーが待機できる時間内にリクエストを発行しませんでした。クライアントは、後からいつでも変更を加えることなくリクエストを再発行できます。」
409 紛争
複数の同時更新間の編集競合など、リソースの現在の状態における競合のためにリクエストを処理できなかったことを示します。 [ 26 ]
410 消えた
要求されたリソースは以前使用されていたが、現在は利用できず、今後利用できないことを示します。これは、リソースが意図的に削除され、パージする必要がある場合に使用します。410 ステータスコードを受け取ったクライアントは、今後そのリソースをリクエストしないでください。検索エンジンなどのクライアントは、インデックスからリソースを削除する必要があります。ほとんどのユースケースでは、クライアントや検索エンジンがリソースをパージする必要はなく、代わりに「404 Not Found」を使用できます。
411 長さが必要です
リクエストでは、要求されたリソースに必要なコンテンツの長さが指定されていません。
412 前提条件が失敗しました
サーバーは、リクエスト元がリクエスト ヘッダー フィールドに設定した前提条件の 1 つを満たしていません。
413 コンテンツが大きすぎます
リクエストがサーバーの処理能力を超えています。以前は「リクエストエンティティが大きすぎます」または「ペイロードが大きすぎます」と呼ばれていました。[ 27 ] : §10.4.14 [ 2 ] : §15.5.14
414 URIが長すぎます
指定されたURIはサーバーが処理するには長すぎます。これは多くの場合、GETリクエストのクエリ文字列としてエンコードされたデータが長すぎることが原因です。その場合はPOSTリクエストに変換する必要があります。以前は「Request-URI Too Long」と呼ばれていました。[ 27 ] : §10.4.15
415 サポートされていないメディアタイプ
リクエストエンティティのメディアタイプは、サーバーまたはリソースがサポートしていません。例えば、クライアントがimage/svg+xml 形式で画像をアップロードしたのに、サーバーが別の形式の画像を要求している場合などです。
416 範囲が満たされない
クライアントはファイルの一部を要求しましたが（バイトサービング）、サーバーはその部分を提供できません。例えば、クライアントがファイルの末尾を超える部分を要求した場合などです。これは以前は「要求された範囲を満たせない」と呼ばれていました。[ 27 ] : §10.4.17
417 期待に応えられませんでした
サーバーはExpectリクエストヘッダーフィールドの要件を満たすことができません。[ 28 ]
418 私はティーポットです (RFC 2324、RFC 7168)
このコードは、1998年にIETFの伝統的なエイプリルフールジョークの一つとしてRFC 2324（ハイパーテキストコーヒーポット制御プロトコル）で定義されましたが、実際のHTTPサーバーに実装されることは想定されていません。RFCでは、コーヒーを淹れるように要求されたティーポットがこのコードを返すべきであると規定されています。[ 29 ]このHTTPステータスは、Google.comの「私はティーポットです」イースターエッグなど、一部のウェブサイトでイースターエッグとして使用されています。 [ 30 ] [ 31 ]このステータスコードは、より適切な403 Forbiddenの代わりに、ブロックされたリクエストへの応答として使用されることもあります。[ 32 ] [ 33 ]
421 誤ったリクエスト
要求は、応答を生成できないサーバーに送信されました (たとえば、接続の再利用のため)。
422 処理できないコンテンツ
リクエストは適切に作成されていた（つまり構文的に正しい）が、処理できなかった。[ 2 ] : §15.5.21
423 ロック (WebDAV; RFC 4918)
アクセス中のリソースはロックされています。[ 7 ]
424 依存関係の失敗 (WebDAV; RFC 4918)
リクエストは別のリクエストに依存しており、そのリクエストが失敗したため失敗しました（例：PROPPATCH）。[ 7 ]
425 早すぎる (RFC 8470)
サーバーが、再生される可能性のある要求を処理するリスクを負うことを望まないことを示します。
426 アップグレードが必要です
クライアントは、Upgrade ヘッダーフィールドで指定されたTLS/1.3などの別のプロトコルに切り替える必要があります。
428 前提条件が必要 (RFC 6585)
オリジンサーバーは、リクエストに条件付きを要求します。これは、「更新の損失」問題を防ぐことを目的としています。これは、クライアントがリソースの状態をGETし、変更してサーバーにPUTする一方で、第三者がサーバー上の状態を変更し、競合が発生するという問題です。[ 34 ]
429 リクエストが多すぎます (RFC 6585)
ユーザーが一定時間内に送信したリクエスト数が多すぎます。レート制限スキームで使用することを目的としています。[ 34 ]
431 リクエストヘッダーフィールドが大きすぎます (RFC 6585)
個々のヘッダーフィールド、またはすべてのヘッダーフィールドの合計が大きすぎるため、サーバーはリクエストを処理できません。[ 34 ]
451 法的な理由により利用できません (RFC 7725)
サーバー運営者は、リソースまたは要求されたリソースを含むリソースセットへのアクセスを拒否するよう求める法的要求を受け取りました。[ 35 ]コード451は、小説『華氏451度』に由来しています。[ 36 ]

5xx サーバーエラー

5xx ステータスは、サーバーがエラーが発生したか、リクエストを実行できないことを認識していることを示します。HEAD リクエストに応答する場合を除き、サーバーはエラー状況の説明を含むエンティティをレスポンスに含める必要があり、その状態が一時的なものか永続的なものかを示す必要があります。同様に、ユーザーエージェントは、含まれるエンティティをユーザーに表示する必要があります。これらのレスポンスコードは、あらゆるリクエストメソッドに適用されます。

500 内部サーバーエラー
予期しない状況が発生し、これ以上具体的なメッセージが適切でない場合に表示される一般的なエラー メッセージ。
501 実装されていません
サーバーはリクエストメソッドを認識しないか、リクエストを処理する能力がありません。通常、これは将来的に利用可能になることを意味します（例：WebサービスAPIの新機能）。
502不正なゲートウェイ
サーバーはゲートウェイまたはプロキシとして機能しており、アップストリーム サーバーから無効な応答を受信しました。
503 サービスは利用できません
サーバーがリクエストを処理できません（過負荷またはメンテナンスのため）。通常、これは一時的な状態です。[ 37 ]
504 ゲートウェイタイムアウト
サーバーはゲートウェイまたはプロキシとして機能しており、アップストリーム サーバーからタイムリーな応答を受信しませんでした。
505 HTTPバージョンがサポートされていません
サーバーは、要求で使用された HTTP バージョンをサポートしていません。
506バリアントもネゴシエートします（RFC 2295）
要求に対する透過的な内容交渉の結果、循環参照が発生します。[ 38 ]
507 ストレージ不足 (WebDAV; RFC 4918)
サーバーはリクエストを完了するために必要な表現を保存できません。[ 7 ]
508 ループ検出 (WebDAV; RFC 5842)
サーバーは、リクエストの処理中に無限ループを検出しました ( 208 Already Reportedの代わりに送信されました)。
510 拡張なし (RFC 2774)
サーバーが要求に応じるには、要求をさらに拡張する必要がある。[ 39 ]
511 ネットワーク認証が必要です (RFC 6585)
クライアントはネットワークにアクセスするために認証を行う必要があります。ネットワークへのアクセスを制御するために使用される傍受プロキシ（例えば、Wi-Fiホットスポット経由で完全なインターネットアクセスを許可する前に利用規約への同意を要求する「キャプティブポータル」など）によって使用されることを目的としています。[ 34 ]

非標準コード

以下のコードはさまざまな Web サーバーで使用されますが、IETF 標準では指定されていません。

インターネット情報サービス

Microsoftのインターネット インフォメーション サービス(IIS) ウェブ サーバーは、クライアントのリクエストに関するエラーを通知するために、4xx エラー空間を拡張します。IIS は、より具体的な情報を提供するために、追加の10進サブコードを使用することがありますが[ 40 ] 、これらのサブコードはレスポンス ペイロードとドキュメントにのみ表示され、実際の HTTP ステータス コードの代わりには表示されません。

440 ログインタイムアウト
クライアントのセッションが期限切れになったため、再度ログインする必要があります。[ 41 ]
449 再試行
ユーザーが必要な情報を提供していないため、サーバーはリクエストに応じることができません。[ 42 ]
450 Windows ペアレンタルコントロールによってブロックされました
Windowsのペアレンタルコントロールによって、要求されたWebページへのアクセスがブロックされていることを示します。[ 43 ]
451 リダイレクト
Exchange ActiveSyncでは、より効率的なサーバーが利用できる場合、またはサーバーがユーザーのメールボックスにアクセスできない場合に使用されます。[ 44 ]クライアントは、より適切なサーバーを見つけるためにHTTP自動検出操作を再実行する必要があります。[ 45 ]

nginx

nginxウェブサーバーソフトウェアは4xxエラースペースを拡張して、クライアントのリクエストに関する問題を通知します。[ 46 ] [ 47 ]

444 応答なし
内部的に使用され[ 48 ]、サーバーにクライアントに情報を返さず、直ちに接続を閉じるように指示します。
494 リクエストヘッダーが大きすぎます
クライアントが送信したリクエストが大きすぎるか、ヘッダー行が長すぎます。
495 SSL証明書エラー
400 Bad Request応答コードの拡張。クライアントが無効なクライアント証明書を提供した場合に使用されます。
496 SSL証明書が必要です
400 Bad Request応答コードの拡張版。クライアント証明書が必要なが提供されていない場合に使用されます。
497 HTTPリクエストがHTTPSポートに送信されました
400 Bad Request応答コードの拡張版。クライアントが HTTPS 要求をリッスンしているポートに HTTP 要求を送信したときに使用されます。
499 クライアントがリクエストをクローズしました
サーバーが応答を送信する前にクライアントが要求を閉じた場合に使用されます。

クラウドフレア

Cloudflareのリバースプロキシサービスは、5xxシリーズのエラースペースを拡張して、オリジンサーバーの問題を通知します。[ 49 ]

520 Webサーバーが不明なエラーを返しました
オリジンサーバーはCloudflareに空、不明、または予期しない応答を返しました。[ 50 ]
521 Webサーバーがダウンしています
オリジンサーバーはCloudflareからの接続を拒否しました。オリジンのセキュリティソリューションが、特定のCloudflare IPアドレスからの正当な接続をブロックしている可能性があります。[ 51 ]
522 接続タイムアウト
Cloudflareはオリジンサーバーへの接続にタイムアウトしました。[ 52 ]
523 オリジンにアクセスできません
Cloudflareはオリジンサーバーに接続できませんでした。[ 53 ]
524 タイムアウトが発生しました
CloudflareはオリジンサーバーへのTCP接続を完了することができましたが、オリジンサーバーはタイムリーなHTTP応答を提供しませんでした。[ 54 ]
525 SSLハンドシェイクに失敗しました
CloudflareはオリジンサーバーとのSSL/TLSハンドシェイクをネゴシエートできませんでした。 [ 55 ] [ 56 ]
526 無効なSSL証明書
CloudflareはオリジンウェブサーバーのSSL証明書を検証できませんでした。[ 57 ] [ 58 ] Cloud Foundryのgorouterでも使用されます。
527 レールガン エラー（廃止）
エラー527は、CloudflareとオリジンサーバーのRailgunサーバー間の接続が中断されたことを示しています。[ 59 ] CloudflareはRailgunを廃止したため、このエラーは廃止されました。
530 オリジンが利用できません
Cloudflareはオリジンホスト名を解決できなかったため、オリジンサーバーへの接続を確立できませんでした。レスポンス本文には1xxxエラーが含まれています。[ 60 ] [ 61 ]

AWS エラスティックロードバランシング

Amazon Web ServicesのElastic Load Balancingは、クライアントのリクエストまたはオリジンサーバーに問題があることを通知するためにいくつかのカスタム戻りコードを追加します。[ 62 ]

000
いずれかのヘッダーの圧縮された長さが8Kバイトを超える場合、または1つの接続で10Kを超えるリクエストが処理される場合、HTTP/2 GOAWAYフレームで返されます。[ 62 ]
460
クライアントは、アイドルタイムアウト期間が経過する前にロードバランサーとの接続を閉じました。通常、クライアントのタイムアウトがElastic Load Balancerのタイムアウトよりも早い場合です。[ 62 ]
463
ロードバランサは30個を超えるIPアドレスを含むX-Forwarded-Forリクエストヘッダーを受信しました。[ 62 ]
464
クライアントとオリジンサーバー間のプロトコルバージョンに互換性がありません。[ 62 ]
561 不正
ロードバランサーに登録されたサーバーから認証に関するエラーが返されました。リスナールールはユーザーを認証するように設定されていますが、アイデンティティプロバイダー（IdP）がユーザー認証時にエラーコードを返しました。[ 62 ]

アパッチ

Apache HTTP Serverによって使用されます。

218 これは大丈夫
この設定が有効になっている場合、メッセージ本文がサーバーを通過できる包括的なエラー状態ProxyErrorOverride。この状況では、4xxまたは5xxエラーメッセージの代わりに表示されます。[ 63 ]
509 帯域幅制限を超えました
サーバーはサーバー管理者によって指定された帯域幅を超えました。これは共有ホスティングプロバイダーが顧客の帯域幅を制限するためによく使用されます。[ 64 ] cPanelでも使用されます。

Laravelフレームワーク

Laravelフレームワークで使用されます。

419 ページが期限切れです
CSRFトークンが見つからないか期限切れです。[ 65 ]

スプリングフレームワーク

Spring Frameworkによって使用されます。

420 メソッドの失敗
WebDAVの開発中に提案された非推奨のレスポンスステータス[ 66 ]は、メソッドが失敗したときにSpring Frameworkで使用されます。[ 67 ]

ツイッター

Twitterで使用されます。

420 落ち着きを高める
Twitter Search and Trends APIバージョン1では、クライアントがレート制限を受けている場合に返されます。バージョン1.1以降では、代わりに429 Too Many Requests応答コードが使用されます。[ 68 ]「Enhance your calm（落ち着きを高めよう）」というフレーズは1993年の映画『デモリションマン』に由来しており、この数字との関連はおそらく大麻への言及である。

ショッピファイ

Shopifyによって使用されます。

430 リクエストヘッダーフィールドが大きすぎます
Shopifyが、一定時間内にリクエストされたURLが多すぎる場合に、429 Too Many Requestsレスポンスコードの代わりに使用する非推奨のレスポンス。 [ 69 ]
430 Shopifyセキュリティ拒否
Shopifyがリクエストが悪意のあるものであると判断されたことを通知するために使用されます。[ 70 ]
530 オリジン DNS エラー
Cloudflareが要求されたDNSレコードを解決できないことを示します。[ 70 ]
540 一時的に無効
要求されたエンドポイントが一時的に無効になっていることを示します。[ 70 ]
783 予期しないトークン
リクエストにJSON構文エラーが含まれていることを示します。[ 70 ]

ArcGIS サーバー

ArcGIS Serverによって使用されます。

498 無効なトークン
期限切れまたは無効なトークンを示します。[ 71 ]
499トークンが必要です
トークンが必要であるが送信されなかったことを示します。[ 71 ]

cパネル

cPanelによって使用されます。

508 リソース制限に達しました
サーバーのアカウントがCPU/RAM使用量や同時プロセス数などの割り当てられたリソースを超えた場合に503の代わりに使用されます。 [ 72 ]

SSLLabs サーバーテスト API

SSLLabs サーバー テスト API で Qualysによって使用されます。

529 サイトが過負荷です
サイトがリクエストを処理できないことを知らせます。[ 73 ]

Pantheon Systems ウェブプラットフォーム

Pantheon Systems Web プラットフォームで使用されます。

530 サイトは凍結されています
非アクティブのため凍結されたサイトを示します。[ 74 ]

リンクトイン

LinkedInで使用されます。

999 リクエストが拒否されました
ブロックされたり、壁で囲まれたり、サインインしないとウェブページにアクセスできないことに関連しています。[ 75 ]

その他

598 ネットワーク読み取りタイムアウトエラー
一部のHTTPプロキシがプロキシ背後のネットワーク読み取りタイムアウトをプロキシ前方のクライアントに通知するために使用する非公式の慣例。[ 76 ]
599 ネットワーク接続タイムアウトエラー
一部の HTTP プロキシが、プロキシの背後のネットワーク接続タイムアウトをプロキシの前のクライアントに通知するために使用するエラー。

参照

参考文献

  1. ^ a b c「Hypertext Transfer Protocol (HTTP) Status Code Registry」 . Iana.org. 2011年12月11日時点のオリジナルよりアーカイブ。2015年1月8日閲覧。
  2. ^ a b c d e f g R. Fielding、M. Nottingham、J. Reschke編（2022年6月）。HTTPセマンティクス。インターネット技術タスクフォース。doi ：10.17487/ RFC9110。ISSN 2070-1721。STD 97。RFC 9110 。 インターネット標準97。RFC 2818、7230、7231、7232、7233、7235、7538、7615、7694 を 廃止。RFC 3864を更新。​​​​​​​​​​​ ​​
  3. ^ Goland, Yaronn; Whitehead, Jim ; Faizi, Asad; Carter, Steve R.; Jensen, Del (1999年2月).分散オーサリングのためのHTTP拡張 – WEBDAV . ネットワークワーキンググループ. doi : 10.17487/RFC2518 . RFC 2518 .提案された標準。RFC 4918  によって廃止されました。
  4. ^ 「102 処理 – HTTP MDN」。2023年7月25日。102 ステータスコードは非推奨です
  5. ^奥 一穂 (2017年12月).ヒントを示すHTTPステータスコード.インターネット技術タスクフォース. doi : 10.17487/RFC8297 . RFC 8297 .実験的。
  6. ^ Stewart, Mark; djna. 「POSTでリクエストを作成し、レスポンスコード200または201とコンテンツを返す」 . Stack Overflow . 2016年10月11日時点のオリジナルよりアーカイブ。 2015年10月16日閲覧。
  7. ^ a b c d Dusseault, Lisa編 (2007年6月). Web分散オーサリングおよびバージョン管理（WebDAV）のためのHTTP拡張. ネットワークワーキンググループ. doi : 10.17487/RFC4918 . RFC 4918 .提案 された標準。RFC 5689 によって更新されました。RFC 2518は 廃止されました。
  8. ^ Hoff, Arthur van ; Douglis, Fred; Krishnamurthy, Balachander; Goland, Yaron Y.; Hellerstein, Daniel M.; Feldmann, Anja; Mogul, Jeffrey (2002年1月). HTTPにおけるデルタエンコーディング. Network Working Group. doi : 10.17487/RFC3229 . RFC 3229 .提案された標準。
  9. ^ Fielding; et al. (1999年6月). 10.3.2 301 Moved Permanently . IETF. p. 61. sec. 10.3.2. doi : 10.17487/RFC2616 . RFC 2616 .
  10. ^ 「サイト移動ツール」。Bing Web マスター ヘルプとハウツー。
  11. ^ 「301 リダイレクト」。Googleウェブマスター ツール ヘルプ。
  12. ^ T Berners-Lee ; R. Fielding ; H. Frystyk (1996年5月). Hypertext Transfer Protocol -- HTTP/1.0 . Network Working Group. doi : 10.17487/RFC1945 . RFC 1945 .情報提供。
  13. ^ Lawrence, Eric. 「HTTPメソッドとリダイレクトステータスコード」 EricLawのIEInternalsブログ。 2011年8月20日閲覧。
  14. ^ 「リクエストオブジェクトとレスポンスオブジェクト | Djangoドキュメント | Django」 . Docs.djangoproject.com . 2014年6月23日閲覧。
  15. ^ Fielding, Roy T.; Reschke, Julian (2014年6月). 「Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content」 . Tools.ietf.org . 2019年1月5日閲覧。
  16. ^ 「セマンティックウェブのためのクールなURI：303 URIを1つの汎用ドキュメントに転送」 www.w3.org . 2025年6月16日時点のオリジナルよりアーカイブ。 2025年7月1日閲覧。
  17. ^ 「セマンティックウェブのためのクールなURI：ハッシュURI」。W3C Interest Group Note。2008年12月3日。
  18. ^アラマラジュ、スブブ;スブラマニヤム州アラマラジュ（2010 年 3 月）。RESTful Web サービス クックブック。オライリーメディア。ISBN 9780596801687。
  19. ^ 「Mozilla Bugzilla Bug 187996: 305 リダイレクトでの奇妙な動作、コメント 13」 。2003年3月3日。 2014年4月21日時点のオリジナルよりアーカイブ。2009年5月21日閲覧。
  20. ^ 「 PHP Webショップ開発者向けGNU Talerチュートリアル 0.4.0」。docs.taler.net 。 2017年11月8日時点のオリジナルよりアーカイブ。2017年10月29日閲覧。
  21. ^ 「Google API 標準エラー応答」 。2016年。 2017年5月25日時点のオリジナルよりアーカイブ。 2017年6月21日閲覧。
  22. ^ 「Sipgate APIドキュメント」。2018年7月10日時点のオリジナルよりアーカイブ。2018年7月10日閲覧。
  23. ^ “Shopify Documentation” . 2018年7月25日時点のオリジナルよりアーカイブ。2018年7月25日閲覧。
  24. ^ 「Stripe APIリファレンス – エラー」 . stripe.com . 2019年10月28日閲覧。
  25. ^ a b「Web分散オーサリングおよびバージョン管理（WebDAV）のためのHTTP拡張機能」IETF 2007年6月。2016年3月3日時点のオリジナルよりアーカイブ。 2016年1月12日閲覧。
  26. ^ 「409 Conflict」 . MDN Web Docs . 2025年3月13日. 2025年6月11日閲覧。
  27. ^ a b c R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; L. Masinter ; P. Leach; T. Berners-Lee (1999年8月). Hypertext Transfer Protocol -- HTTP/1.1 . Network Working Group. doi : 10.17487/RFC2616 . RFC 2616 .廃止。RFC 7230、7231、7232、7233、7234、7235  により廃止。RFC 2068 は廃止。RFC 2817、5785、6266、6585 により更新。​​​​​​​​​​​​​
  28. ^ TheDeadLike. 「HTTP/1.1 ステータスコード 400 と 417、どちらを選択できない」 . serverFault . 2015年10月10日時点のオリジナルよりアーカイブ。 2015年10月16日閲覧。
  29. ^ L. Masinter (1998年4月1日).ハイパーテキストコーヒーポット制御プロトコル (HTCPCP/1.0) . ネットワークワーキンググループ. doi : 10.17487/RFC2324 . RFC 2324 .情報提供。RFC 7168 により更新。これはエイプリルフールの RCFです 。ティーポットでコーヒーを淹れようとすると、エラーコード「418 I'm a teapot」が返されます。結果として得られるエンティティボディは短く太くても構いません。
  30. ^バリー・シュワルツ (2014年8月26日). 「SEOオタクのためのGoogleの新たなイースターエッグ：サーバーステータス418、私はティーポットです」 . Search Engine Land . 2015年11月15日時点のオリジナルよりアーカイブ。 2015年11月4日閲覧。
  31. ^ 「エラー418（私はティーポットです）！？」2025年12月17日閲覧。
  32. ^ 「ウェブサイトで追加のウェブセキュリティを有効にする」 DreamHost . 2022年12月18日閲覧。
  33. ^ 「ロシアのウェブサイトにアクセスしたら、このひどいティーポットしか表示されなかった」 PCMag 、 2022年2月25日。 2022年12月18日閲覧。
  34. ^ a b c d M. Nottingham; R. Fielding (2012年4月).追加のHTTPステータスコード.インターネット技術タスクフォース. doi : 10.17487/RFC6585 . ISSN 2070-1721 . RFC 6585 . 提案された標準。RFC 2616 を 更新します。
  35. ^ Bray, T. (2016年2月). 「法的障害を報告するためのHTTPステータスコード」 ietf.org . 2016年3月4日時点のオリジナルよりアーカイブ。 2015年3月7日閲覧。
  36. ^ポール・イアン（2015年12月21日）「エラー451はレイ・ブラッドベリ風のオンライン検閲のための新たなHTTPコード」 PC World 2025年7月18日閲覧。
  37. ^ alex. 「サイトがメンテナンスのためにダウンしているときに送信すべき正しいHTTPステータスコードは何ですか？」 . Stack Overflow . 2016年10月11日時点のオリジナルよりアーカイブ。 2015年10月16日閲覧。
  38. ^ K. Holtman; AH Mutz (1998年3月). HTTPにおける透過的コンテンツネゴシエーション. ネットワークワーキンググループ. doi : 10.17487/RFC2295 . RFC 2295 .実験的。
  39. ^ Nielsen, Henrik Frystyk ; Leach, Paul; Lawrence, Scott (2000年2月). HTTP拡張フレームワーク. ネットワークワーキンググループ. doi : 10.17487/RFC2774 . RFC 2774 .歴史的。
  40. ^ 「IIS 7.0のHTTPステータスコード」。Microsoft 。 2009年7月14日。2009年4月9日時点のオリジナルよりアーカイブ。2009年4月1日閲覧。
  41. ^ 「Outlook Web Access を使用して Exchange 2007 にログオンしようとすると、エラー メッセージ「440 ログイン タイムアウト」が表示される」「 . Microsoft . 2010. 2013年11月13日閲覧。
  42. ^ 「2.2.6 449 Retry With Status Code」。Microsoft 。2009年。2009年10月5日時点のオリジナルよりアーカイブ。2009年10月26日閲覧。
  43. ^ 「エラーページのスクリーンショット」 。 2013年5月11日時点のオリジナル（bmp）からアーカイブ。2009年10月11日閲覧。
  44. ^ 「MS-ASCMD、セクション3.1.5.2.2」。Msdn.microsoft.com。2015年3月26日時点のオリジナルよりアーカイブ。2015年1月8日閲覧。
  45. ^ "Ms-oxdisco" . Msdn.microsoft.com. 2014年7月31日時点のオリジナルよりアーカイブ。2015年1月8日閲覧。
  46. ^ "ngx_http_request.h" . nginx 1.9.5 ソースコード. nginx inc. 2017年9月19日時点のオリジナルよりアーカイブ。 2016年1月9日閲覧。
  47. ^ "ngx_http_special_response.c" . nginx 1.9.5 ソースコード. nginx inc. 2018年5月8日時点のオリジナルよりアーカイブ。 2016年1月9日閲覧。
  48. ^ "return" ディレクティブは 2018 年 3 月 1 日にWayback Machine (http_rewrite モジュール) ドキュメントにアーカイブされています。
  49. ^ 「トラブルシューティング：エラーページ」。Cloudflare 。 2016年3月4日時点のオリジナルよりアーカイブ。2016年1月9日閲覧。
  50. ^ 「エラー520：ウェブサーバーが不明なエラーを返しました」。Cloudflare。2025年5月29日。
  51. ^ 「エラー521: ウェブサーバーがダウンしています」。Cloudflare。2025年4月29日。
  52. ^ 「エラー522: 接続がタイムアウトしました」。Cloudflare。2025年5月5日。
  53. ^ 「エラー523: originにアクセスできません」。Cloudflare。2025年4月29日。
  54. ^ 「エラー524：タイムアウトが発生しました」。Cloudflare。2025年8月6日。
  55. ^ 「エラー525: SSLハンドシェイクに失敗しました」。Cloudflare。2025年4月29日。
  56. ^ 「Cloudflareサポートドキュメント」 . developers.cloudflare.com . 2025年4月29日. 2025年9月14日閲覧。
  57. ^ 「エラー526: 無効なSSL証明書」。Cloudflare。2025年8月11日。
  58. ^ 「Cloudflareサポートドキュメント」 . developers.cloudflare.com . 2025年8月11日. 2025年9月14日閲覧。
  59. ^ 「527 エラー: Railgun Listener から origin へのエラー」 . Cloudflare . 2016年10月13日時点のオリジナルよりアーカイブ。2016年10月12日閲覧。
  60. ^ 「エラー 530」 . Cloudflare . 2019年11月1日閲覧。
  61. ^ 「Cloudflareサポートドキュメント」 . developers.cloudflare.com . 2025年4月29日. 2025年9月14日閲覧。
  62. ^ a b c d e f「アプリケーションロードバランサーのトラブルシューティング – Elastic Load Balancing」 . docs.aws.amazon.com . 2023年5月17日閲覧。
  63. ^ 「218 これは問題ありません – HTTPステータスコードの説明」 HTTP.dev 2023年7月25日閲覧。
  64. ^ 「HTTPエラーコードとクイックフィックス」 Docs.cpanel.net。2015年11月23日時点のオリジナルよりアーカイブ。2015年10月15日閲覧。
  65. ^ "framework/src/Illuminate/Foundation/Exceptions/Handler.php" . GitHub . 2023年12月12日閲覧。
  66. ^ 「draft-ietf-webdav-protocol-05: World Wide Web 上の分散オーサリングの拡張 -- WEBDAV」。
  67. ^ "Enum HttpStatus" . Spring Framework . org.springframework.http. 2015年10月25日時点のオリジナルよりアーカイブ。2015年10月16日閲覧。
  68. ^ 「Twitter Error Codes & Responses」Twitter 2014年。2017年9月27日時点のオリジナルよりアーカイブ。2014年1月20日閲覧。
  69. ^ 「HTTPステータスコードとSEO ：知っておくべきこと」ContentKing . 2019年8月9日閲覧。
  70. ^ a b c d「Shopify API レスポンスステータスとエラーコード」 。 2023年12月12日閲覧。
  71. ^ a b「トークンベース認証の使用」。ArcGIS Server SOAP SDK。2014年9月26日時点のオリジナルよりアーカイブ。 2014年9月8日閲覧。
  72. ^ 「CloudLinuxでサイトを閲覧中に「508 リソース制限に達しました」というエラーが表示される」。2021年9月28日。2025年7月19日時点のオリジナルよりアーカイブ。 2025年7月19日閲覧。
  73. ^ 「SSL Labs API v3 ドキュメント」 . github.com .
  74. ^ 「プラットフォームに関する考慮事項 | Pantheon Docs」 . pantheon.io . 2017年1月6日時点のオリジナルよりアーカイブ。2017年1月5日閲覧。
  75. ^ 2017年、 2024年、 2025年の事例で見られる
  76. ^ "HTTPステータスコード – ascii-code.com" . www.ascii-code.com . 2017年1月7日時点のオリジナルよりアーカイブ。2016年12月23日閲覧。
ウィキメディア コモンズには、 HTTP ステータス コードに関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=List_of_HTTP_status_codes&oldid=1334667563#200」より取得