HTTPステータスコード詳細対照表

Httpステータスコード ステータスコードの意味
100 クライアントはリクエストを継続する必要があります。この一時的な応答は、クライアントに部分リクエストがサーバーに受け入れられたことを通知し、まだ拒否されていないことを知らせるためのものです。クライアントはリクエストの残りの部分を送信するか、リクエストが完了している場合はこの応答を無視する必要があります。サーバーはリクエストが完了した後、クライアントに最終応答を送信しなければなりません。
101 サーバーはクライアントのリクエストを理解し、Upgradeメッセージヘッダを通じてクライアントに異なるプロトコルを使用してリクエストを完了することを通知します。この応答の最後の空行を送信した後、サーバーはUpgradeメッセージヘッダに定義されたプロトコルに切り替わります。切り替えが有益な場合のみ、この措置を取るべきです。例えば、新しいHTTPバージョンが古いバージョンよりもメリットがある場合や、リアルタイムで同期の取れたプロトコルに切り替えてその特性を利用してリソースを転送する場合です。
102 WebDAV（RFC 2518）によって拡張されたステータスコードで、処理が継続されることを示します。
200 リクエストが成功しました。リクエストで期待された応答ヘッダまたはデータ本体がこの応答に返されます。
201 リクエストが実行され、新しいリソースがリクエストに従って作成され、そのURIがLocationヘッダ情報とともに返されました。必要なリソースがすぐには作成できない場合は、'202 Accepted'を返すべきです。
202 サーバーはリクエストを受け入れましたが、まだ処理していません。このリクエストは拒否される可能性がありますし、最終的には実行される可能性もあります。非同期の操作の場合、202というステータスコードを返すのが最も便利です。このステータスコードの目的は、サーバーが他のプロセスのリクエストを受け入れることを許可することであり（例えば、毎日一回実行されるバッチ処理など）、クライアントがバッチ処理が完了するまでサーバーとの接続を維持する必要がありません。202ステータスコードで応答する際には、現在の状態に関する情報を示すエンティティを含め、処理状態の監視装置や状態予測へのポインタを指し示す必要があります。
203 サーバーはリクエストを正常に処理しましたが、返されたエンティティのヘッダのメタ情報は、元のサーバーで有効な確定した集合ではなく、ローカルまたはサードパーティのコピーからのものです。現在の情報は元のバージョンのサブセットまたはスーパーセットである可能性があります。例えば、リソースのメタデータを含むと、元のサーバーがメタ情報のスーパーセットを知ることができます。このステータスコードの使用は必須ではなく、応答がこのステータスコードを使用しなければ200 OKが返される場合にのみ適切です。
204 サーバーはリクエストを正常に処理しましたが、エンティティの内容を返す必要がなく、更新されたメタ情報を返すことを期待しています。応答はエンティティのヘッダを通じて、新しいまたは更新されたメタ情報を返すかもしれません。これらのヘッダ情報が存在する場合は、要求された変数に対応する必要があります。クライアントがブラウザの場合、ユーザーのブラウザはそのリクエストを送信したページを保持し、ドキュメントビューに変更を加えないようにしてください。規格に従い、新しいまたは更新されたメタ情報はユーザーのブラウザ活動ビューに適用されなければなりません。204応答はメッセージボディを含めることが禁止されているため、常にメッセージヘッダの後の最初の空行で終わります。
205 サーバーはリクエストを成功裏に処理しましたが、何も返していません。しかし、204応答とは違い、このステータスコードを返す応答は、リクエスターにドキュメントビューをリセットすることを要求します。この応答は、ユーザーが入力を受け入れた後に、即座にフォームをリセットして、ユーザーが新たな入力を簡単に開始できるようにするために主に使用されます。204応答と同様に、この応答はメッセージボディを含めることが禁止され、メッセージヘッダの後の最初の空行で終わります。
206 サーバーは部分的なGETリクエストを正常に処理しました。FlashGetや迅雷といったHTTPダウンロードツールは、ブレークポイントレジュームや大きなドキュメントを複数のダウンロードセクションに分解して同時にダウンロードするためにこのような応答を利用します。このリクエストにはRangeヘッダ情報を含める必要があり、クライアントが希望する内容の範囲を指定します。また、If-Rangeがリクエスト条件として含まれる場合があります。応答は次のヘッダフィールドを含めなければなりません：Content-Rangeは今回の応答に返される内容の範囲を示すためのものです。Content-Typeがmultipart/byterangesの場合、各multipartセクションはそのセクションの内容範囲を示すContent-Rangeフィールドを含める必要があります。応答にContent-Lengthが含まれる場合、その数値は返された内容の実際のバイト数と一致する必要があります。Date、ETag、および/またはContent-Locationは、同じリクエストが本来200応答を返すはずの場合です。Expires、Cache-Control、および/またはVaryは、その値が以前と異なる場合には他の応答に対する同じ変数の値と異なる場合もあります。この応答がIf-Rangeで強いキャッシュバリデーションを使用する場合、この応答には他のエンティティヘッダを含めることはできません。If-Rangeが弱いキャッシュバリデーションを使用する場合も、他のエンティティヘッダを禁止されます。これによりキャッシュされたエンティティの内容と更新されたエンティティヘッダ情報の間の不一致を防ぎます。そうでない場合、この応答には本来200応答で返されるすべてのエンティティヘッダフィールドが含まれるべきです。ETagまたはLast-Modifiedフィールドが正確に一致しない場合、クライアントキャッシュは206応答で返された内容を以前に何らかの理由でキャッシュした内容と組み合わせようとしてはいけません。RangeおよびContent-Rangeヘッダをサポートしていないキャッシュは、206応答で返された内容をキャッシュすることを禁止されます。
207 WebDAV(RFC 2518)によって拡張されたステータスコードで、以降のメッセージボディはXMLメッセージとなり、以前のサブリクエストの数に応じた独立した応答コードの系列を含む場合があります。
300 リクエストされたリソースには、一連の選択肢があり、それぞれには固有のアドレスとブラウザによるドライビングメッセージ情報があります。ユーザーまたはブラウザは、好みのアドレスを選択してリダイレクトできます。これはHEADリクエストでない限り、この応答は特性とアドレスのリストを含むエンティティを返す必要があります。このエンティティのフォーマットはContent-Typeによって定義されたフォーマットによって決まります。ブラウザはレスポンスの形式とブラウザ自身の機能に基づき、自動的に最適な選択を行うことがあります。当然、RFC 2616規格はこうした自動選択がどのように行われるかを規定していません。サーバーがあらかじめ選択した応答が存在する場合、それがLocationに指定されているUVに示されるべきで、ブラウザはこのLocation値を自動的にリダイレクトのアドレスとして使用する可能性があります。さらに、特に指定がない限り、この応答もキャッシュ可能です。
301 リクエストされたリソースは新しい位置に永続的に移動しました。これ以降のリソースに対する参照は、この応答で返されるURIのいずれかを使用するべきです。可能であれば、リンク編集機能を持つクライアントは、サーバーから返されたアドレスにリクエストのアドレスを自動的に変更する必要があります。特に指定がない限り、この応答もキャッシュ可能です。新しい永続的URIは応答のLocationフィールドに返されるべきです。これはHEADリクエストでない限り、応答のエンティティには新しいURIへのハイパーリンクと簡潔な説明が含まれている必要があります。これはGETまたはHEADリクエストでない場合、ブラウザはユーザーの確認が得られない限り、リダイレクトを自動的に行うことはできません。リクエストの条件が変更される可能性があるからです。注意：HTTP/1.0プロトコルを使用する一部のブラウザでは、POSTリクエストを送信し、301応答を受けると、次のリダイレクトリクエストがGET方式に変わります。
302 リクエストされたリソースは現在一時的に異なるURIから応答されています。このようなリダイレクトは一時的なもののため、クライアントは元のアドレスに対して以降のリクエストを送信するべきです。Cache-ControlまたはExpiresで指定された場合にのみ、この応答はキャッシュ可能です。新しい一時的URIは応答のLocationフィールドに返されるべきです。これはHEADリクエストでない限り、応答のエンティティには新しいURIへのハイパーリンクと簡潔な説明が含まれている必要があります。これがGETまたはHEADリクエストでない場合、ブラウザはもちろんユーザーの確認が得られない限りは自動的にリダイレクトできません。リクエストの条件が変更される可能性があるからです。注意：RFC 1945とRFC 2068規範は、クライアントがリダイレクト時にリクエストのメソッドを変更することを許可していませんが、多くの既存のブラウザでは302応答を303応答と見なし、Locationで指定されたURIにGET方式でアクセスし、元のリクエストメソッドを無視します。ステータスコード303と307が明確にクライアントがサーバーに期待する反応を示すために追加されました。
303 現在のリクエストの応答は別のURIで見つけることができ、クライアントはそのリソースにGET方式でアクセスする必要があります。この方法は、スクリプトによってアクティブにされたPOSTリクエストから別のリソースへのリダイレクトを可能にするために存在します。この新しいURIは、元のリソースの代替参照ではありません。同時に、303応答はキャッシュを禁止します。もちろん、二度目のリクエスト（リダイレクト）はキャッシュされる可能性があります。新しいURIは応答のLocationフィールドに返されるべきです。これはHEADリクエストでない限り、応答のエンティティには新しいURIへのハイパーリンクと簡潔な説明が含まれている必要があります。注意：多くのHTTP/1.1未満のブラウザでは、303ステータスを正しく理解することができません。これらのブラウザとの相互作用を考慮する必要がある場合、302ステータスコードが適していると考えられます。なぜならほとんどのブラウザは302応答を取得した際、クライアントが303応答として処理すべき事をするからです。
304 クライアントが条件付きGETリクエストを送信し、そのリクエストが許可されている場合、文書の内容（最後のアクセスからまたは要求の条件に基づく）が変更されていない場合、サーバーはこのステータスコードを返すべきです。304応答は禁止されているメッセージボディを含めるため、常にメッセージヘッダの後の最初の空行で終わります。この応答には以下のヘッダ情報を含める必要があります：Date、サーバーに時計がない場合を除き。時計のないサーバーもこれらのルールを遵守する場合、プロキシサーバーやクライアントも受信したレスポンスヘッダにDateフィールドを追加することができます（RFC 2068の規定のように）。キャッシュメカニズムは正常に機能します。ETagおよび/またはContent-Location、同じリクエストが本来200応答を返すはずの場合です。Expires、Cache-Control、および/またはVaryは、その値が以前の変数の他の応答と異なる場合には異なる場合があります。この応答が強キャッシュの確認を使用する場合、この応答には他のエンティティヘッダを含めるべきではありません；そうでない場合（条件付きGETリクエストが弱いキャッシュ確認を使用する場合）、この応答は他のエンティティヘッダを含めることは禁止されています。これにより、キャッシュされたエンティティ内容と更新されたエンティティヘッダ情報の間の不一致を防ぎます。ある304応答が現在のエンティティにキャッシュがないことを示している場合、キャッシュシステムはその応答を無視し、制限条件のないリクエストを繰り返し送信する必要があります。あるキャッシュエントリを更新するリクエスト279307サーバーの応答が304となった場合、キャッシュシステムはすべてのエントリを更新して応答で更新されたすべてのフィールドの値を反映する必要があります。
305 リクエストされたリソースは指定されたプロキシを通じてアクセスする必要があります。Locationフィールドには指定されたプロキシのURI情報が含まれ、受信者はこのプロキシを通じてリクエストを再送信する必要があります。この305応答は、オリジナルのサーバーのみが構成できるものです。注意：RFC 2068では、305応答は単一のリクエストをリダイレクトするためのものとして明確にされておらず、元のサーバーのみが生成可能です。これらの制限を無視することは深刻なセキュリティの結果を招く可能性があります。
306 現在の仕様では、306ステータスコードはもはや使用されていません。
307 リクエストされたリソースは現在一時的に異なるURIから応答しています。このリダイレクトが一時的なものであるため、クライアントは元のアドレスに引き続きリクエストを行うべきです。Cache-ControlまたはExpiresによって指定されている場合、この応答はキャッシュ可能です。新しい一時的URIは応答のLocationフィールドに返されるべきです。これはHEADリクエストでない限り、応答のエンティティには新しいURIへのハイパーリンクと簡潔な説明が含まれる必要があります。一部のブラウザが307応答を理解できないため、ユーザーが理解し新しいURIにアクセスできるように必要な情報を追加する必要があります。これはリクエストがGETまたはHEADリクエストでない場合には、ブラウザはユーザーの確認が得られない限り自動的にリダイレクトを行うことはできません。
400 1. セマンティクスが誤っており、現在のリクエストはサーバーによって理解されません。変更しない限り、クライアントはこのリクエストを再送信するべきではありません。2. リクエストパラメータに誤りがあります。
401 現在のリクエストにはユーザー認証が必要です。この応答は、リクエストされたリソースに適用可能なWWW-Authenticate情報ヘッダを含む必要があります。クライアントは適切なAuthorizationヘッダ情報を含むリクエストを再送信することができます。現在のリクエストがすでにAuthorization証明書を含んでいる場合、401応答はサーバーがこれらの証明書を拒否したことを示します。401応答が前の応答と同じ認証の問い合わせを含み、ブラウザが少なくとも一度認証しようとした場合、ブラウザは応答に含まれるエンティティ情報をユーザーに表示するべきです。このエンティティ情報には関連する診断情報が含まれているかもしれません。詳細についてはRFC 2617を参照してください。
402 このステータスコードは将来の可能性のある要求のために予約されています。
403 サーバーはリクエストを理解しましたが、その実行を拒否します。401応答とは異なり、認証は役に立たず、このリクエストも再送信されるべきではありません。これはHEADリクエストでない場合、サーバーがリクエストが実行されない理由を明確に説明したい場合、エンティティ内に拒否の理由を説明する必要があります。もちろん、サーバーはクライアントに対して何らかの情報を提供したくない場合、404応答を返すこともできます。
404 リクエストが失敗しました。リクエストで希望されたリソースがサーバー上に見つかりませんでした。この状況が一時的なものであるのか永続的なものであるのかをユーザーに知らせる方法はありません。サーバーが状況を知っている場合、410ステータスコードを使用して、古いリソースが内部構成メカニズムの問題により永続的に使用できなくなっていることを通知し、移動先のアドレスは提供しません。404というステータスコードは、サーバーがリクエストが拒否される理由を明らかにしたくないか、他に適切な応答がない場合に広く使用されています。
405 リクエストラインで指定されたリクエストメソッドは、リクエストされたリソースには使用できません。この応答は、現在のリソースが受け入れるリクエストメソッドのリストを示すAllowヘッダ情報を返す必要があります。PUTおよびDELETEメソッドは、サーバー上のリソースに対して書き込み操作を行うため、ほとんどのウェブサーバーは、デフォルトでこれらのリクエストメソッドをサポートしていないか、許可していません。これらのリクエストは、すべて405エラーを返します。
406 リクエストされたリソースの内容特性が、リクエストヘッダの条件を満たすことができず、応答エンティティを生成できません。これはHEADリクエストでない場合、応答は、ユーザーまたはブラウザが最も適切なエンティティ特性とアドレスのリストを選択できるようにするエンティティを返す必要があります。エンティティのフォーマットはContent-Typeヘッダで定義されたメディアタイプによって決定されます。ブラウザはフォーマットと自身の能力を基に、最適な選択を自動的に行うことがあります。ただし、規格では、このような自動選択の標準を定義していません。
407 401応答に似ていますが、クライアントはプロキシサーバーで認証を受ける必要があります。プロキシサーバーは、認証のためのProxy-Authenticateを返す必要があります。クライアントは、Proxy-Authorization情報ヘッダを返して認証することができます。詳細についてはRFC 2617を参照してください。
408 リクエストタイムアウト。クライアントはサーバーが待つ予定の時間内にリクエストを送信できませんでした。クライアントは、変更せずにこのリクエストを再度送信することができます。
409 リクエストがリクエストされたリソースの現在の状態と衝突しているため、完了できません。このコードは、ユーザーが衝突を解決でき、新しいリクエストを再送信する場合にのみ使用することを許可されています。この応答は、ユーザーが衝突のソースを特定できるように、十分な情報を提供するべきです。衝突は通常、PUTリクエストの処理中に発生します。例えば、バージョンチェック環境での特定リソースのPUT提出のリクエストに付随するバージョン情報が以前のサードパーティリクエストと衝突する場合、サーバーは409エラーを返し、リクエストが完了できないことをユーザーに伝えるべきです。この場合、応答エンティティには衝突した2つのバージョンの確認が含まれる可能性が高く、ユーザーが再度新しいバージョンを提出することが可能です。
410 リクエストされたリソースはサーバー上でアクセスできなくなっており、移動先のアドレスはありません。この状況は永久的なものと見なされるべきです。可能であれば、リンク編集機能を持つクライアントは、ユーザーの許可を得てこのアドレスへのすべての参照を削除すべきです。サーバーがこの状況が永久的であるかどうか知っている、または決定できない場合、404ステータスコードを使用すべきです。特に指定がない限り、この応答はキャッシュ可能です。410応答の主な目的は、ウェブサイト管理者がサイトを維持できるようにし、リソースが永久的に使えなくなったことをユーザーに通知し、サーバーの所有者がこのリソースへの遠隔接続を削除してほしいと願っていることを伝えることです。このような出来事は、制限付き、付加価値サービスにおいて一般的です。同様に、410応答はサーバーサイト上において、本来は特定の個人が所有していたリソースが利用できなくなったことを通知するためにも使用されます。もちろん、すべての永続的に使用できないリソースを「410 Gone」とマークする必要があるかどうか、またこのマークをどのくらいの期間保持するかは、サーバーの所有者に完全に依存します。
411 サーバーはContent-Lengthヘッダが定義されていない限りリクエストを受け付けることを拒否しました。リクエストメッセージボディの長さを示す有効なContent-Lengthヘッダを追加した後、クライアントは再度このリクエストを送信できます。
412 サーバーはリクエストヘッダフィールドで指定された前提条件を検証する際に、1つ以上の条件が満たされなかったことを示します。このステータスコードを使うことで、クライアントはリソースを取得する際にリクエストのメタ情報（リクエストヘッダフィールドデータ）に前提条件を設定することができ、そのリクエストのメソッドが希望する内容以外のリソースに適用されないことを保証することができます。
413 サーバーは、現在のリクエストを処理することを拒否しました。なぜなら、エンティティデータサイズがサーバーが処理したいまたはできる範囲を超えたからです。この場合、サーバーは接続を切って、クライアントがこのリクエストを送信し続けるのを防ぐことができます。この状況が一時的な場合、サーバーはRetry-Afterレスポンスヘッダを返し、クライアントに再試行できるまでの時間を通知します。
414 リクエストされたURIがサーバーが解釈できる長さを超えているため、サーバーはそのリクエストに対してサービスを拒否しました。これはあまり一般的ではありません。通常の状況には、POSTメソッドを使用すべきフォーム送信がGETメソッドに変わることでクエリ文字列が長すぎること、リダイレクトURI「ブラックホール」（例えば、古いURIを新しいURIの一部としてリダイレクトする過程で複数回リダイレクトされ、URIが長すぎる）、クライアントがサーバーにあるセキュリティホールを利用しようとしている場合があります。このようなサーバーは、固定長バッファを読み取るか、リクエストURIを操作する場合、GETのパラメータがある数を超えるとバッファオーバーフローが発生し、任意のコードが実行されることがあります。これらの脆弱性がないサーバーは、414ステータスコードを返すべきです。
415 現在のリクエストメソッドおよびリクエストされたリソースに対して、送信されたエンティティがサーバーでサポートされていない形式であるため、リクエストが拒否されます。
416 リクエスト中にRangeリクエストヘッダが含まれていて、Rangeで指定されたデータ範囲が現在のリソースの利用可能範囲と重ならない場合、かつリクエスト中にIf-Rangeリクエストヘッダが定義されていない場合、サーバーは416ステータスコードを返すべきです。もしRangeがバイト範囲を使用している場合、この状況は、リクエストに指定されたデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを示します。サーバーは、416ステータスコードと一緒に現在のリソースの長さを示すContent-Rangeエンティティヘッダを含めるべきです。この応答も絶対にmultipart/byterangesをContent-Typeとして使用することを禁止されています。
417 リクエストヘッダExpectで指定された期待内容がサーバーによって満たされず、またはこのサーバーはプロキシサーバーであり、これが現在のルートの次のノードで満たされないという明確な証拠があります。
421 現在のクライアントのIPアドレスからサーバーへの接続数が、サーバーで許可されている最大範囲を超えました。通常、このIPアドレスはサーバーに表示されているクライアントアドレス（例えばユーザーのゲートウェイやプロキシサーバーアドレス）を指します。この場合、接続数の計算には1人のエンドユーザー以上が関与する可能性があります。
422 現在のクライアントのIPアドレスからサーバーに接続数が、サーバーで許可されている最大範囲を超えています。通常の状況では、サーバーはcurrentの接続を数えて、リクエストを追加で回避することが求められます。
422 リクエスト形式は正しいですが、意味的な誤りがあるため、応答できません。（RFC 4918 WebDAV）423 Locked現在のリソースがロックされています。（RFC 4918 WebDAV）
424 以前のリクエストによるエラーにより、現在のリクエストが失敗しました。例えばPROPPATCH。（RFC 4918 WebDAV）
425 WebDav Advanced Collections草案で定義されていますが、「WebDAVシーケンスセットプロトコル」（RFC 3658）には欠落しています。
426 クライアントはTLS/1.0に切り替えるべきです。（RFC 2817）
449 マイクロソフトによって拡張されており、リクエストは適切な操作が完了するまでは再試行されるべきです。
500 サーバーは予期しない状況に遭遇し、リクエストを処理できません。一般的には、この問題はサーバーのプログラムコードがエラーとなったときに発生します。
501 サーバーは、現在のリクエストに必要な機能をサポートしていません。この場合、サーバーはリクエストメソッドを認識できず、リソースへのリクエストをサポートできません。
502 ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとした際、上流のサーバーから無効な応答を受け取りました。
503 一時的なサーバーメンテナンスまたは過負荷により、サーバーは現在リクエストを処理できません。この状況は一時的であり、しばらくしてから回復します。遅延時間を予測することができる場合、応答にはRetry-Afterヘッダを含めることができます。このRetry-After情報が与えられなかった場合、クライアントは500応答を処理する場合と同じ方法でこれを処理するべきです。注意：503ステータスコードが存在するからといって、サーバーが過負荷の場合に必ず使用する必要があるわけではありません。特定のサーバーは、接続を拒否することを望んでいます。
504 ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとしたが、上流サーバー（URIで指定されているサーバー、例えばHTTP、FTP、LDAP）や補助サーバー（DNSなど）から応答を受け取れませんでした。注意：一部のプロキシサーバーは、DNSクエリのタイムアウトによって400または500エラーを返すことがあります。
505 サーバーは、リクエスト中に使用されたHTTPバージョンをサポートしていないか、そのサポートを拒否しています。これは、サーバーがクライアントと同じバージョンを使用できないか、使用したくないことを示します。応答には、なぜバージョンがサポートされていないのか、またサーバーがどのプロトコルをサポートしているのかを説明する内容が含まれるべきです。
506 透明なコンテンツ協商プロトコル（RFC 2295）で拡張されており、サーバーに内部設定エラーが発生しています：リクエストされた妥協変数リソースが透明なコンテンツの協商処理で自己を使用するように設定されています。
507 サーバーは、リクエストを完了するために必要なコンテンツをストアできません。この状況は一時的であると見なされます。WebDAV(RFC 4918)
509 サーバーが帯域幅制限に達しました。これは公式なステータスコードではありませんが、広く使用されています。
510 リソースを取得するためのポリシーが満たされていません。（RFC 2774）

HTTPステータスコード詳細一覧 - 一般的なHTTP応答ステータスコードを深く理解する

HTTPステータスコードは、クライアントとサーバー間の通信の重要な部分であり、それぞれのステータスコードはサーバーがクライアントのリクエストに対する異なる応答を示します。これらのステータスコードを理解することは、開発者やウェブサイト管理者にとって極めて重要です。このツールはHTTPステータスコード詳細一覧を提供し、一般的なHTTPステータスコードを素早く理解できるようサポートし、オンラインでのクエリ機能を提供します。

一般的なHTTPステータスコードの詳細

以下は一般的なHTTPステータスコードとその意味です。これらのステータスコードを使用することで、サーバーの応答状態を素早く把握することができます：

ステータスコード 説明 一般的なシーン
200 OK リクエスト成功、サーバーがリクエストされたリソースを返答。
301 Moved Permanently リクエストされたリソースは新しい場所に永続的に移動しました。
302 Found リクエストされたリソースは一時的に別の場所に移動しました。
400 Bad Request クライアントからのリクエストに誤りがあり、サーバーが理解できません。
401 Unauthorized リクエストにはユーザー認証が必要で、無効な認証情報が提供されました。
403 Forbidden サーバーはリクエストを拒否し、クライアントがそのリソースに対する十分なアクセス権限を持っていません。
404 Not Found リクエストされたリソースはサーバー上で見つかりませんでした。
500 Internal Server Error サーバーは予期しないエラーに遭遇し、リクエストを完了できません。
502 Bad Gateway サーバーがゲートウェイまたはプロキシとして機能している時に無効な応答を受け取りました。
503 Service Unavailable サーバーは一時的にリクエストを処理できませんが、通常は過負荷またはメンテナンス中です。
504 Gateway Timeout サーバーがゲートウェイまたはプロキシとして機能しているときにリクエストの応答をタイムリーに受け取れませんでした。

HTTPステータスコードクエリツールの使い方

このツールのステータスコードクエリ機能を使用して、HTTP応答ステータスコードを素早く検索し理解することができます。これにより開発とデバッグがより効率的になります：

  1. ステータスコードを入力：クエリボックスにHTTPステータスコード（例：200、404、500など）を入力します。
  2. 説明を確認：クエリ結果には、該当するステータスコードの詳細な説明が提供され、その意味と適用シーンを理解するのに役立ちます。
  3. 提案を得る：一般的なエラーのステータスコード（例：404、500など）については、ツールが問題を診断し、ウェブサイトの可用性を向上させるための最適化提案を提供します。

一般的なHTTPステータスコードの詳細

以下は、最も一般的なHTTPステータスコードとその説明です：

200 OK

ステータスコード200はリクエストの成功を示し、サーバーがリクエストされたリソースを正常に返しました。このステータスコードは最も一般的な応答であり、クライアントとサーバー間の通信がスムーズであることを示しています。

404 Not Found

404ステータスコードは、クライアントがリクエストしたリソースがサーバー上で見つからなかったことを示します。通常、ユーザーは「ページが見つかりません」というメッセージを目にします。解決方法としては、リクエストされたURLが正しいかを確認するか、サーバーログを確認して他の問題が発生していないかを確認します。

500 Internal Server Error

500ステータスコードは、サーバーが意図しないエラーに遭遇し、リクエストを完了できなかったことを示します。一般的な原因には、サーバー構成の誤り、アプリケーションのクラッシュ、またはデータベース接続の問題などがあります。解決方法としては、通常サーバーのエラーログを確認し、問題を見つけて修正します。

403 Forbidden

403ステータスコードは、サーバーがリクエストを理解したものの、その実行を拒否したことを示しています。通常、これはユーザーがそのリソースにアクセスできる十分な権限を持っていない場合に発生します。ファイルの権限設定を確認し、サーバーがそのリソースへのアクセスを許可しているかを確認することができます。

502 Bad Gateway

502ステータスコードは、サーバーがゲートウェイまたはプロキシとして機能しているときに無効な応答を受け取ったことを示しています。この状況は、逆プロキシサーバーと上流のサーバー間の通信に問題が発生した場合に多く見られます。

なぜHTTPステータスコードを理解する必要があるのか？

HTTPステータスコードを理解することは、ウェブサイトの開発と運用において非常に重要です。これにより、開発者は問題を素早く特定し解決することができます。たとえば、404エラーはあるページが存在しないことを示し、500エラーはサーバーにより深刻な問題が発生している可能性を示します。この情報をタイムリーに把握することで、ウェブサイトのユーザー体験や安定性を効果的に向上させることができます。

HTTPステータスコードを最適化する方法

HTTPステータスコードに基づいて、さまざまな最適化手法を取ることができます。例えば：

  • 404エラーに対しては、カスタムエラーページを提供して、ユーザーが他の有効なコンテンツを見つけやすいようにすることができます。
  • 500エラーに対しては、サーバーログを確認し、コードや構成の問題を修正してサービスの可用性を保つことができます。
  • すべての応答ステータスコードがサーバーの実際の状態を正しく反映するようにし、ユーザーや開発者が混乱しないようにすることが重要です。

まとめ

HTTPステータスコードを掌握し理解することは、すべてのウェブサイト開発者やシステム管理者にとって基本的なスキルです。HTTPステータスコード詳細一覧を活用することで、ウェブサイトの問題を素早く特定し解決し、ウェブサイトのスムーズな運用とユーザー体験の最適化を保証することができます。

あなたの足跡：
言語を選択