HTTPステータスコードの一覧

HTTPステータスコードとは、RFC2616によって定められた、サーバからのレスポンスの意味を表現するものである。3桁の数字からなる。

コード一覧

HTTPステータスコードは100の位で大まかな種別を識別し、下2桁で細かい内容を識別する。
また、IISでは、401・403・404をさらに細かく区分しているが本来これは標準ではないので割愛する。
概略を説明すると診断のために必要な情報であるという程度である。

原則として、IANAが提供しているHTTPステータスコード一覧に掲載されているものについて取り扱う。ただし、418については掲載されていないが記事があるので触れる。

また、ニコニコ大百科に個別に記事のあるステータスコードは太字で記載するので、詳しくはリンク先の記事も参照にされたい。

1xx - Informational

この系列は暫定的なレスポンスとして返される。そのため、レスポンスには中身がない。

1xxのステータスコード一覧

番号・説明句	概要	出典
100 - Continue	クライアントはリクエストを継続すべきである。サーバはすべてを処理した後最終応答を返さなければならない。一般にこのコードが使われることはほぼないはずである。こちらから要求をしない限りは。	RFC2616(HTTP/1.1)
101 - Switching Protocols	サーバはクライアントから指示されたことに従いプロトコルを変更する用意がある。このコードは一般に見えることはないが、WebSocket(RFC6455)という技術を使う場合は確実に使うことになるので今後お世話になる機会は増えるだろう。	RFC2616(HTTP/1.1)
102 - Processing	リクエストは受理されたがまだ完了していない(おそらく20秒以上かかるだろう)。後継規格のRFC4918では削除されている。	RFC2518(WEBDAV)
103 - Early Hints	予定されるレスポンスの一部である。これにより、先読みをブラウザに可能にさせる。	RFC8297(ヒント提示)

2xx - Success

この系列では原則としてリクエストは正常に受信され、処理され、受理されたということを示す。

2xxのステータスコード一覧

番号・説明句	概要	出典
200 - OK	リクエストは成功した。一般的にはこれに一番お世話になっているが気づくことはないのが普通。ただ、ステータスコードが200でも「ページが見つかりません」とか言うやつがたまにいる(いわゆるソフト404)ので注意。クローラーもこれには苦戦する。	RFC2616(HTTP/1.1)
201 - Created	資源は正常に作成された。レスポンスボディ内部にその資源の場所は書かれていてもっともそれをよくあらわすものはLocationヘッダにある、とされている。とはいえまずこれのお世話になることはないはず。POSTなら200が戻るはずなので。それと、これが戻ってきた段階ですでに資源は作成されているべきである。そうでないならば202を戻すこと。	RFC2616(HTTP/1.1)
202 - Accepted	要求は受け付けられたが処理はまだ完了していない。このステータスに伴う応答本体には現在状況と、監視場所か要求完了見込み時刻のどちらかがあるべきである。	RFC2616(HTTP/1.1)
203 - Non-Authoritative Information	この資源は自分で管理しているものではなく、ローカルもしくは第三者からのコピーである。スーパーセットやサブセットでもかまわない。その場合でも必ずしも203である必要はなく200でもよい。	RFC2616(HTTP/1.1)
204 - No Content	メタ情報の更新はあるが応答の中身は一切ない。UAは見え方を一切更新すべきではない。	RFC2616(HTTP/1.1)
205 - Reset Content	UAは見せ方を更新すべきである。この応答には中身を一切含んではならない。	RFC2616(HTTP/1.1)
206 - Partial Content	部分的GETをサポートする場合で、その資源の指定された一部分である。部分的GETといってなじみがないかもしれないが、実際に2chブラウザの一部はこれをサポートしている。これによりいちいち毎回書き込み全部を読み込む必要がなくなるので回線を圧迫しなくなる。2chブラウザにおける部分的GETの使い方についてはこちらから。	RFC2616(HTTP/1.1)
207 - Multi-Status	COPYメソッドで複数資源を対象にしたが一部資源について失敗したなどの場合に返る。	RFC4918(WebDAV)
208 - Already Reported	同一集合に対する複数束縛の内部メンバの模倣を回避するために使われる、とかかれているが何を言っているのか著者には不明。詳細わかる人執筆希望	RFC5842(WebDAV)
226 - IM Used	この要素について1以上のインスタンス操作が行われている。	RFC3229(HTTPにおける差分符号化)

3xx - Redirection

この系列ではユーザーエージェント(ブラウザやロボット)に対し追加のアクションを求める。たいていの場合は別のURLへリクエストを変更することになるだろう。なお、古い規格ではリダイレクトの回数は5回までに制限することが推奨されていた。基本的に無限リダイレクトは帯域を圧迫するなどデメリットしかないので何らかの方法で無限ループを抑止するべきである。

3xxのステータスコード一覧

番号・説明句	概要	出典
300 - Multiple Choices	この資源には複数の表現が存在するからユーザはお好みの場所を選択すること。そうすればそこへリダイレクトされるだろう。ただ、実際にこれが使われることはほぼないといってよい。というのもたいていはそうは組まないからである。	RFC2616(HTTP/1.1)
301 - Moved Permanently	その資源は新しい永続的URIへ移転した。たいていの場合末尾にスラッシュを忘れた場合にスラッシュを付与するために使われるが、本当にサイトそのものが移転した場合にも使われる。	RFC2616(HTTP/1.1)
302 - Found	そのURLは一時的に別の場所に移転している。リクエストメソッドを本来は変更してはならないのだが、しばしば303の用途に用いられてしまったため(あちらはメソッドをGETに変更する)本来の用途のために307が新しく作られた。2chブラウザの場合はたいていdat落ちした場合に使われる。	RFC2616(HTTP/1.1)
303 - See Other	指示された場所をGETするように。ただ、多くのUAが303をうまく認識しないため、302が代用として使われてしまうという状況に陥っている。	RFC2616(HTTP/1.1)
304 - Not Modified	条件付GETで特に問題はないが、更新がない場合に発生する。2chブラウザの場合、差分GETをしようとしたときに何も更新がない場合に使われる。	RFC2616(HTTP/1.1)
305 - Use Proxy	Locationヘッダで指示されたプロキシを使うこと。なお、この応答はオリジンサーバ(要するに元コンテンツをもってるサーバ)以外は生成してはいけない	RFC2616(HTTP/1.1)
306 - (Unused)	このコードはかつては使われていたが現在のバージョンでは使われていない。なので予約済み。1996年のドラフトでは、Switch Proxy(別のプロキシを使うこと。当然プロキシサーバが生成する)が割り当てられていたようである。	RFC2616(HTTP/1.1)
307 - Temporary Redirect	一時的に別のURIにある。要するに302が誤用されすぎたために代わりに増えたコードである。	RFC2616(HTTP/1.1)
308 - Permanent Redirect	永続的307と考えれば差し支えない。	RFC7238(HTTPステータスコード308(永続的リダイレクト))

4xx - Client Error

この系列ではクライアントのリクエストには何らかの問題を抱えていてサーバはリクエストを処理することができない。たいていの場合本番環境なら本当にクライアントに原因があるが、開発環境だとしばしば、本番環境でもまれにサーバ側に原因がある場合がある(たとえば.htaccessの設定を間違えたとか)。

4xxのステータスコード一覧

番号・説明句	概要	出典
400 - Bad Request	リクエストの構造がおかしくサーバが理解できない。クライアントは修正なしにリクエストを投げるべきではない。	RFC2616(HTTP/1.1)
401 - Unauthorized	認証されていないか、あるいは認証に失敗した。サーバはその情報を伝えるべきであるし、クライアントは認証を行えるようなシステムを提供すべきである。一応、RFC2617にBASIC認証とダイジェスト認証が定義されている。	RFC2616(HTTP/1.1)
402 - Payment Required	将来の利用のために予約されている。	RFC2616(HTTP/1.1)
403 - Forbidden	サーバはリクエストを理解したが遂行を拒否した。よくあるのがアクセスが禁止されている場所へアクセスしたり、管理者によりアクセスを拒否されたりしている場合である。まれに設定ミスの可能性もあるが。なお、この応答ではHEADメソッド(ヘッダだけ必要で他の中身は不要)でない限り理由を明示すべきである(必須ではない)。理由を明かしたくないならば404を使ってもよい。	RFC2616(HTTP/1.1)
404 - Not Found (404 - File Not Found)	その資源は存在しない。410とは違いそれが一時的な場合もある。404は他の応答を使う場合で理由を隠蔽したい場合にも使うことができる。エラーの中では一番よくみるものである。	RFC2616(HTTP/1.1)
405 - Method Not Allowed	リクエスト先URIに対して要求されたメソッドは許可されていない。応答ヘッダには許可されているメソッドを含むべきである。例えば読み込み専用のリソースに対してPUTを試みたなど。	RFC2616(HTTP/1.1)
406 - Not Acceptable	クライアントの受け入れられる応答は生成できない。HTMLが欲しいといっているが作れるのはJSONだけであるなどいろいろなパターンが存在する。	RFC2616(HTTP/1.1)
407 - Proxy Authentication Required	プロキシ経由での認証が必要である。	RFC2616(HTTP/1.1)
408 - Request Timeout	リクエストを制限時間内に完了しなかった。リクエストについては問題のない可能性があるのでもう一度繰り返してもよい。	RFC2616(HTTP/1.1)
409 - Conflict	リクエストは衝突したため完了できなかった。解決可能なだけの情報をサーバは提供すべきである。よく起きるのはPUTメソッドの場合である。	RFC2616(HTTP/1.1)
410 - Gone	もはやその資源は利用可能でなく、どこにその資源がいったか知らない。本当にそうであるか確信を持てない場合404を返すべきである。	RFC2616(HTTP/1.1)
411 - Length Required	Content-Lengthヘッダがない。POSTやPUTのようにデータが必要なリクエストにも関わらずその長さがわからない。	RFC2616(HTTP/1.1)
412 - Precondition Failed	前提条件が失敗した。要するに条件付きリクエストにも関わらずその条件を満たしていない、ということ。	RFC2616(HTTP/1.1)
413 - Request Entity Too Large	リクエストが大きすぎなのでサーバはその遂行を拒否した。一時的ならRetry-Afterでどれくらいしたら大丈夫かを示してもよい。	RFC2616(HTTP/1.1)
414 - Request-URI Too Large	リクエストURIが長過ぎる。本来POSTで投げるべきようなものをGETで投げてしまっているなどを疑うべきである。	RFC2616(HTTP/1.1)
415 - Unsupported Media Type	リクエストのメディアタイプがそのメソッドではサポートされていないので拒否した。	RFC2616(HTTP/1.1)
416 - Requested Range Not Satisfiable	部分的GETを試みたが、その範囲を満たすことができない。2chブラウザでは、あぼーんが発生した場合によく発生する。	RFC2616(HTTP/1.1)
417 - Expectation Failed	Expectヘッダに適合できない。	RFC2616(HTTP/1.1)
418 - I'm a tea pot	ティーポットにコーヒーを入れさせようとした。 (HTTPではなく)HTCPCPが使用するため、4xx系のコードに空きがなくなるまでは欠番扱い。	RFC2324(HTCPCP/1.0) RFC9110(HTTP Semantics)
421 - Misdirected Request	レスポンスを生成できないサーバにリクエストした。	RFC7540(HTTP/2)
422 - Unprocessable Entity	リクエストのボディのタイプは理解したし、文法上も問題ないが指示内容が処理不能である。	RFC4918(WebDAV)
423 - Locked	指示された資源はロックされている。	RFC4918(WebDAV)
424 - Failed Dependency	依存している他のアクションが失敗したので失敗した。	RFC4918(WebDAV)
425 - Unordered Collection	順序なし集合に対し順序を指定した。	とある失効したドラフト(失効日は1999年12月18日)
426 - Upgrade Required	Upgradeヘッダが必要である。	RFC2817(HTTP/1.1のTLSアップグレード)
428 - Precondition Required	オリジンサーバが条件付きリクエストを要求している。	RFC6585(追加HTTPステータスコード)
429 - Too Many Requests	短時間にリクエストを送りすぎなのでリクエストの遂行を拒否した。	RFC6585(追加HTTPステータスコード)
431 - Request Header Fields Too Large	ヘッダサイズが大きすぎる。	RFC6585(追加HTTPステータスコード)
451 - Unavailable For Legal Reasons	法的な理由により利用できない。 451を割当てたのはレイ・ブラッドベリの作品「華氏451度」にちなむ。	RFC7725(追加HTTPステータスコード)

5xx - Server Error

サーバ側に問題がありこのリクエストを処理することができないことをこの系列では指し示している。

5xxのステータスコード一覧

番号・説明句	概要	出典
500 - Internal Server Error	サーバはリクエスト処理中にリクエスト遂行を妨げる予期せぬ状況に遭遇した。たいていの場合、CGIなどのプログラムミスである。	RFC2616(HTTP/1.1)
501 - Not Implemented	あなたのリクエストはサーバが取り扱うことのできないものである。メソッドが実装されていないなどの場合の適切な応答。	RFC2616(HTTP/1.1)
502 - Bad Gateway	上流サーバから不正な応答を受け取った。一般にアプリケーションサーバとやり取りしてる際に、そのアプリケーションサーバと適切なやり取りを行えなかった時に起きる。	RFC2616(HTTP/1.1)
503 - Service Unavailable	過負荷やメンテナンスによりアクセス不能である。Retry-Afterヘッダで待ってほしい時間を連絡可能。もしそれがない場合クライアントは500と同様に扱うべきである。また、この応答は単純に接続拒否したいためだけにこの503を使うかもしれない。	RFC2616(HTTP/1.1)
504 - Gateway Timeout	ゲートウェイやプロキシから出したリクエストの応答が所定時間内に戻ってこなかった。ただし、一部のプロキシ実装ではDNSルックアップに失敗した場合にこの504ではなく400や500を戻すやつがいる。	RFC2616(HTTP/1.1)
505 - HTTP Version not supported	そのバージョンのHTTPはこのサーバではサポートしていない。サーバはきちんとどのバージョンをサポートしているか伝えるべきである。	RFC2616(HTTP/1.1)
506 - Variant Also Negotiates	設定ミス。自分自身と透過的コンテンツ交渉をしようとしている。	RFC2295(HTTPにおける透過的コンテンツ交渉)
507 - Insufficient Storage	記憶領域の容量不足によりリクエストを完了できない。この状況は一時的と見なされ、ユーザリクエストによるものなら別のアクションによってリクエストが発行されるまで繰り返されてはならない。	RFC4918(WebDAV)
508 - Loop Detected	無限再帰を要求されたがループに入った。	RFC5842(WebDAV)
510 - Not Extended	資源アクセスポリシーと整合しない。サーバは拡張リクエストを発行するために必要な情報を提供すべきである。	RFC2774(HTTP拡張フレームワーク)
511 - Network Authentication Required	ネットワーク認証が必要である。クレデンシャルを発行するためのアドレスを応答は示すべきである。この応答はオリジンサーバから発行されるべきではない。	RFC6585(追加HTTPステータスコード)

関連項目

• 一覧の一覧