📚 HTTPステータスコード辞典

HTTPステータスコードの意味・よくある原因・対処のヒントを日本語でまとめました。「403 意味」「502 503 違い」のようにコード番号や名称で検索できます。

検索

カテゴリ

46件表示中（全46件）

100継続Continue

クライアントがリクエストの一部（ヘッダーなど）を送信した後、残りのボディを送ってよいかをサーバーが確認する暫定応答。通常はExpect: 100-continueヘッダーを送った場合に返る。

よくある原因・対処: 主に大きなリクエストボディ（ファイルアップロードなど）を送る際に、クライアントやHTTPライブラリが自動的にやり取りする。開発者が直接目にすることは少ないが、プロキシがExpectヘッダーを正しく扱わないと通信が滞ることがある。

出典: RFC 9110

101プロトコル切り替えSwitching Protocols

サーバーがUpgradeヘッダーで要求されたプロトコル（例: WebSocket）への切り替えに応じたことを示す応答。

よくある原因・対処: WebSocket接続確立時のハンドシェイクで見られる。プロキシやロードバランサーがUpgradeヘッダーを転送しない設定になっていると、接続確立に失敗する。

出典: RFC 9110

103早期ヒントEarly Hints

最終的なレスポンスを返す前に、事前読み込みすべきリソース（CSSやフォントなど）をLinkヘッダーで先行通知する暫定応答。

よくある原因・対処: 表示速度改善のためCDNやサーバーが対応している場合に返る。対応していないクライアントは単に無視するため、送出しても実害はない。

出典: RFC 8297

200成功OK

リクエストが正常に処理されたことを示す、最も基本的な成功レスポンス。

よくある原因・対処: 特に問題がない通常のケース。ただしエラー時にも常に200を返し、ボディ内のフィールドだけでエラーを表現する設計（ステータスコードの形骸化）は、キャッシュやモニタリングと相性が悪いため避けたい。

出典: RFC 9110

201作成完了Created

リクエストの結果、新しいリソースが作成されたことを示す。多くの場合Locationヘッダーで作成されたリソースのURIを返す。

よくある原因・対処: POSTやPUTでリソースを新規作成するAPIで使用する。作成したリソース本体を返す実装と、Locationヘッダーのみ返す実装がある。

出典: RFC 9110

202受理Accepted

リクエストは受理されたが、処理はまだ完了していないことを示す。非同期処理の開始を表す。

よくある原因・対処: バッチ処理やキューイングされるジョブなど、処理完了を待たずに応答を返す設計で使われる。クライアントは後で別のエンドポイントなどで処理状況を確認する必要がある。

出典: RFC 9110

204内容なしNo Content

リクエストは成功したが、返すべきレスポンスボディがないことを示す。

よくある原因・対処: DELETE成功時や、更新内容を返す必要がないPUT/PATCHでよく使われる。ボディがないためContent-Lengthは0、または省略される。

出典: RFC 9110

206部分的内容Partial Content

Rangeヘッダーによる部分的なリクエストに対し、リソースの一部だけを返したことを示す。

よくある原因・対処: 動画のシークや大きなファイルの再開ダウンロードで使われる。Content-Rangeヘッダーで返却範囲を示す。

出典: RFC 9110

301恒久的に移動Moved Permanently

リソースが恒久的に新しいURIへ移動したことを示す。以降は新しいURIを使うべきことをクライアントに伝える。

よくある原因・対処: URL構造の恒久的な変更や、httpからhttpsへの恒久リダイレクトなどSEO評価を引き継ぎたい場面で使う。ブラウザや検索エンジンに強くキャッシュされやすいため、設定ミスをした場合に修正が反映されにくい点に注意。仕様上POSTがGETに変換される場合があるため、メソッドを維持したい場合は308を検討する。

出典: RFC 9110

302発見（一時的移動）Found

リソースが一時的に別のURIにあることを示す。恒久的な移動ではない点で301と異なる。

よくある原因・対処: 歴史的経緯によりPOSTリクエストがGETに変換されて再送されるブラウザ実装が多く、これが混乱の元になっている（元のHTTP/1.0仕様が曖昧だったため）。恒久的な移動には301、メソッドを厳密に維持したい一時リダイレクトには307を使う方が意図が明確になる。

出典: RFC 9110

303他を参照See Other

処理結果を別のURIからGETで取得させたい場合に使う。PRG（Post/Redirect/Get）パターンの実装で用いられる。

よくある原因・対処: フォーム送信後にブラウザの再読み込みで二重送信されるのを防ぐため、POST処理完了後に303で結果ページへリダイレクトする。常にGETで再取得される点が302や307と異なる。

出典: RFC 9110

304未更新Not Modified

If-Modified-SinceやIf-None-Matchによる条件付きリクエストに対し、リソースが更新されていないことを示す。ボディは返さず、クライアント側キャッシュの再利用を促す。

よくある原因・対処: ブラウザキャッシュや中間プロキシキャッシュの検証時に発生する。ETagやLast-Modifiedの実装ミスにより、常に200が返ってキャッシュが効かない、逆に更新後も304が返り続けて反映されない、といった不具合の原因になりやすい。

出典: RFC 9110

307一時的リダイレクトTemporary Redirect

一時的なリダイレクトで、302と異なりリクエストメソッドとボディを変更せずに再送することが仕様で保証されている。

よくある原因・対処: POSTやPUTのメソッドを維持したまま一時的に別URIへ転送したい場合に使う。302の曖昧な挙動（メソッドがGETに変わりうる）を避けたいAPIや、メンテナンスモードへの転送などで利用される。

出典: RFC 9110

308恒久的リダイレクトPermanent Redirect

恒久的なリダイレクトで、301と異なりメソッドとボディを変更せずに再送することが仕様で保証されている。

よくある原因・対処: APIのエンドポイント恒久移行など、メソッドを厳密に維持したまま恒久リダイレクトしたい場合に使う。301と308、302と307はそれぞれ「恒久/一時」は同じでメソッド保証の有無だけが異なる、という関係で覚えると整理しやすい。

出典: RFC 9110

400不正なリクエストBad Request

リクエストの構文が不正、またはパラメータの形式が誤っているためサーバーが処理できないことを示す。

よくある原因・対処: 不正なJSON、必須パラメータの欠落、型の不一致などクライアント側の入力不備が主な原因。入力バリデーションエラー全般の表現に使われることも多い。

出典: RFC 9110

401認証が必要Unauthorized

リクエストに有効な認証情報が含まれていないことを示す。名称に反して認可(Authorization)ではなく認証(Authentication)の失敗、つまり「あなたが誰か確認できない」状態を意味する。

よくある原因・対処: トークンの未送信・期限切れ・無効な資格情報が主な原因。仕様上はWWW-Authenticateヘッダーで認証方式を提示する必要がある。「誰であるか確認できない」401と、「誰かは確認できているが権限がない」403は明確に区別する。

出典: RFC 9110

402支払いが必要Payment Required

将来の利用のために予約されているステータスコード。当初は電子決済システム向けに定義されたが、現在も標準化された用途は確立していない。

よくある原因・対処: 一部のAPIやサービスが、サブスクリプション未加入や利用クレジットの枯渇時に独自の意味で使用することがある。

出典: RFC 9110

403禁止Forbidden

サーバーがリクエストを理解したうえで、アクセスを拒否したことを示す。認証の有無に関わらず、権限が不足している場合に返る。

よくある原因・対処: 本人確認はできているがロールや権限が不足している、IPアドレス制限、ファイル・ディレクトリのパーミッション設定ミスなどが原因となる。「誰か分からない」401との違いは、403は「誰かは分かるがアクセス権がない」という点にある。

出典: RFC 9110

404見つからないNot Found

指定されたURIに対応するリソースが見つからないことを示す。

よくある原因・対処: URLのタイプミス、リソースの削除、ルーティング設定の不備が典型的な原因。存在自体を秘匿したいセキュリティ上の理由から、あえて403の代わりに404を返す設計もある。

出典: RFC 9110

405許可されないメソッドMethod Not Allowed

リソースは存在するが、リクエストで使用されたHTTPメソッドが許可されていないことを示す。

よくある原因・対処: GETのみ対応のエンドポイントにPOSTを送るなど、実装されていないメソッドでアクセスした場合に発生する。仕様上、Allowヘッダーで許可されているメソッド一覧を示す必要がある。

出典: RFC 9110

406受理不可Not Acceptable

リクエストのAcceptヘッダーで指定された条件（形式・言語・文字コードなど）を満たすレスポンスを生成できないことを示す。

よくある原因・対処: クライアントがAccept: application/xmlのみを許可しているのに、サーバーがJSONしか返せない場合などに発生する。コンテンツネゴシエーションを実装しているAPIで見られる。

出典: RFC 9110

408リクエストタイムアウトRequest Timeout

クライアントが規定時間内にリクエストを完了しなかったため、サーバーが接続をタイムアウトさせたことを示す。

よくある原因・対処: ネットワークが遅い、クライアントが接続を張ったままリクエストを送信しない、などが原因。サーバー側のタイムアウト設定が短すぎる場合にも発生しうる。

出典: RFC 9110

409競合Conflict

リクエストがリソースの現在の状態と競合するため処理できないことを示す。

よくある原因・対処: 楽観的ロックにおけるバージョン不一致、一意制約に反する重複登録、同時編集の競合などが典型例。原因となっている状態を解消してから再送する必要がある。

出典: RFC 9110

410消失Gone

リソースが以前は存在したが恒久的に削除され、今後も復活しない見込みであることを示す。

よくある原因・対処: 意図的に廃止したAPIエンドポイントや、退会済みユーザーのページなどで使う。404との違いは「今後も戻らないことを明示する」点で、検索エンジンのクローラーへのシグナルとしても有用。

出典: RFC 9110

411長さの指定が必須Length Required

サーバーがContent-Lengthヘッダーを必須としているのに、リクエストに含まれていないことを示す。

よくある原因・対処: チャンク転送エンコーディングを使わずボディ長を省略したPOST/PUTリクエストで発生することがある。

出典: RFC 9110

412前提条件失敗Precondition Failed

If-MatchやIf-Unmodified-Sinceなど、リクエストヘッダーで指定した前提条件が満たされなかったことを示す。

よくある原因・対処: 楽観的排他制御でETagが一致しない場合など、自分がリソースを取得した後に他のユーザーが先に更新してしまった際の競合検出に使われる。

出典: RFC 9110

413リクエストが大きすぎるContent Too Large

リクエストボディがサーバーの許容するサイズを超えていることを示す（旧称 Payload Too Large）。

よくある原因・対処: 大きなファイルのアップロードや、リクエストボディがサーバー・プロキシの上限（nginxのclient_max_body_sizeなど）を超えた場合に発生する。

出典: RFC 9110

414URIが長すぎるURI Too Long

リクエストURIがサーバーの処理可能な長さを超えていることを示す。

よくある原因・対処: GETパラメータに大量のデータを詰め込んだ場合や、無限リダイレクトによってURLが連結され続けた場合などに発生する。

出典: RFC 9110

415サポートされないメディアタイプUnsupported Media Type

リクエストボディのメディアタイプ（Content-Type）をサーバーが処理できないことを示す。

よくある原因・対処: JSONを期待しているAPIにContent-Type: text/plainやmultipart/form-dataを送ってしまうなど、Content-Typeヘッダーの指定ミスが典型的な原因。

出典: RFC 9110

418私はティーポットI'm a teapot

元々はエイプリルフールのジョークとして定義されたステータスコード。「私はティーポットであり、コーヒーを淹れることはできない」という意味で、実運用のプロトコル上の意味は持たない。

よくある原因・対処: 一部のフレームワークやサービスが遊び心・イースターエッグとして実装している例がある。本番のエラー表現として使うべきではない。

出典: RFC 9110（附属書の非規範的な記述）

422処理できない内容Unprocessable Content

リクエストの構文は正しいが、意味的に処理できない（値がビジネスルールに反するなど）ことを示す（旧称 Unprocessable Entity）。

よくある原因・対処: 必須項目は揃っているが値が業務ルールに反する、参照先の外部キーが存在しないなど、構文エラーではなく意味的な入力不備が原因。RESTful APIのバリデーションエラーでよく使われる。

出典: RFC 9110

425早すぎるToo Early

TLS 1.3の0-RTTデータ（Early Data）で送られたリクエストについて、リプレイ攻撃のリスクがあるためサーバーが処理を拒否したことを示す。

よくある原因・対処: 0-RTTを有効にしたTLS接続で、冪等でない操作（決済処理など）が早期データとして送られた場合に、安全のため拒否されることがある。

出典: RFC 8470

426アップグレードが必要Upgrade Required

サーバーが現在のプロトコルでの処理を拒否し、Upgradeヘッダーで示す別のプロトコルへの切り替えを要求していることを示す。

よくある原因・対処: 平文のHTTPでの通信を拒否し、TLSへの切り替えを要求する場合などに使われる。

出典: RFC 9110

428前提条件が必須Precondition Required

サーバーが条件付きリクエスト（If-Matchなど）を必須としているのに、それが付与されていないことを示す。

よくある原因・対処: 複数クライアントによる同時更新でのロストアップデート問題を防ぐため、更新系APIでIf-Matchの付与を必須化している場合に発生する。

出典: RFC 6585

429リクエストが多すぎるToo Many Requests

一定時間内のリクエスト数がレート制限を超えたことを示す。

よくある原因・対処: APIのレート制限やDDoS対策による制限に達した場合に発生する。Retry-Afterヘッダーで再試行までの待機時間が示されることが多い。

出典: RFC 6585

431リクエストヘッダーが大きすぎるRequest Header Fields Too Large

リクエストヘッダーのサイズ（単一または合計）が大きすぎて、サーバーが処理を拒否したことを示す。

よくある原因・対処: 大量のCookieの蓄積や、長すぎる認証トークンをヘッダーに含めた場合などに発生する。

出典: RFC 6585

451法的理由により利用不可Unavailable For Legal Reasons

法的な理由（裁判所命令や検閲など）によりコンテンツの提供が拒否されていることを示す。

よくある原因・対処: 著作権侵害の申し立てや特定国・地域の法規制により、コンテンツへのアクセスが制限されている場合に使われる。

出典: RFC 7725

500サーバー内部エラーInternal Server Error

サーバー内部で予期しないエラーが発生し、リクエストを処理できなかったことを示す包括的なエラー。

よくある原因・対処: 未処理の例外、null参照、設定ミスなどアプリケーションコード側の不具合が主な原因。まずはサーバーのアプリケーションログを確認するのが調査の第一歩となる。

出典: RFC 9110

501実装されていないNot Implemented

サーバーがリクエストの処理に必要な機能をサポートしていないことを示す。

よくある原因・対処: 未対応のHTTPメソッドや、実装されていない機能へのリクエストがあった場合に返る。405はそのリソースに対してメソッドが許可されていないことを示すのに対し、501はサーバー自体がそのメソッドを一切サポートしていない場合に使う。

出典: RFC 9110

502不正なゲートウェイBad Gateway

ゲートウェイやプロキシとして動作するサーバーが、上流（バックエンド）サーバーから不正な応答を受け取ったことを示す。

よくある原因・対処: バックエンドのアプリケーションサーバーがクラッシュした、上流サーバーが処理中に接続を切断した、リバースプロキシと上流の設定が食い違っているなどが原因。「上流から異常な応答が返ってきた」状態を指す点が503・504と異なる。

出典: RFC 9110

503サービス利用不可Service Unavailable

サーバーが一時的に過負荷、またはメンテナンス中でリクエストを処理できないことを示す。

よくある原因・対処: アクセス集中による過負荷、デプロイ中のメンテナンスモード、ヘルスチェック失敗によるロードバランサーからの切り離しなどが原因。Retry-Afterヘッダーで復旧見込み時刻を示せる。502が「上流から異常な応答が返ってきた」状態であるのに対し、503は「サーバー自身が処理不能を宣言している」状態を指す。

出典: RFC 9110

504ゲートウェイタイムアウトGateway Timeout

ゲートウェイやプロキシが、上流サーバーからの応答を規定時間内に受け取れなかったことを示す。

よくある原因・対処: バックエンド処理に時間がかかりすぎている（重いDBクエリ、外部API呼び出しの遅延など）、プロキシのタイムアウト設定が短すぎる、などが原因。502が「異常な応答が返ってきた」状態であるのに対し、504は「応答自体が時間内に返ってこない」状態を指す。

出典: RFC 9110

505サポートされないHTTPバージョンHTTP Version Not Supported

サーバーがリクエストで使用されたHTTPのバージョンをサポートしていないことを示す。

よくある原因・対処: 古い、または非対応のHTTPバージョンでリクエストを送った場合に発生する。実運用で遭遇することは稀。

出典: RFC 9110

507ストレージ不足Insufficient Storage

リクエストを完了するために必要なストレージ容量をサーバーが確保できないことを示す（WebDAV拡張）。

よくある原因・対処: ディスク容量不足により、ファイルの保存やリソースの作成に失敗した場合に発生する。

出典: RFC 4918

508ループ検出Loop Detected

リクエストを処理する過程で無限ループを検出したため、サーバーが処理を中断したことを示す（WebDAV拡張）。

よくある原因・対処: WebDAVのリソース間の循環参照（例: コピー先が自分自身の子孫になっている等）が原因となる。

出典: RFC 5842

511ネットワーク認証が必要Network Authentication Required

クライアントがネットワークへのアクセスを得るために認証が必要であることを示す。

よくある原因・対処: 公衆Wi-Fiのキャプティブポータル（利用規約への同意やログインを求める画面）で使われる。目的のサーバーではなく、間に入るネットワーク機器やプロキシ自身がこの応答を生成して返す。

出典: RFC 6585

※ 各コードの意味・出典RFCは執筆時点の情報です。実際の挙動はサーバーやフレームワークの実装により異なる場合があります。

※ URLの末尾に「#404」のようにコード番号を付けてアクセスすると、該当するカードまで自動でスクロールします。

こんなツールをこれからも作っていきます。もしこれは！と思っていただけましたら、シェア・応援していただけると嬉しいです！😀

X (旧Twitter)

Facebook

LINE

はてブ

リンクコピー

✅ コピーしました！