本番エラーで、まず誰に聞くか判断する
502 / 503 / 504 の対照表は、アプリが落ちたのか、トラフィックが外れたのか、遅いだけなのかを教えてくれます。Cloudflare の 52x カードは「オリジンのファイアウォール／証明書／タイムアウトを確認」という方向を直接示します。
読み込み中…
Guide
HTTP ステータスコード一覧は72件のステータスコードを収録しています。RFC 9110 が定義するすべての標準コード（100–101、200–206、300–308、400–418、421、422、426、500–505）、RFC 6585 / 7725 / 8297 / 8470 と WebDAV 系 RFC が定義する拡張コード（103、207、208、226、423–425、428、429、431、451、506–511）、そしてどの RFC にもないものの、本番のトラブルシューティングで毎日のように見かける非標準コード——nginx の 444 と 499、Cloudflare の 520–526 です。
更新日 2026-09-094 sources7 min read
HTTP ステータスコード一覧は72件のステータスコードを収録しています。RFC 9110 が定義するすべての標準コード（100–101、200–206、300–308、400–418、421、422、426、500–505）、RFC 6585 / 7725 / 8297 / 8470 と WebDAV 系 RFC が定義する拡張コード（103、207、208、226、423–425、428、429、431、451、506–511）、そしてどの RFC にもないものの、本番のトラブルシューティングで毎日のように見かける非標準コード——nginx の 444 と 499、Cloudflare の 520–526 です。
「意味」だけを載せる一覧とは違い、各コードを4段に分けて書いています。その意味とは何か。どんな状況で見かけるのか。フロントエンド／クライアントは受け取ったら何をすべきか（再試行する? ログイン画面へ誘導する? どのレスポンスヘッダーを読む?）。バックエンドはいつ返すべきで、返すときにどのヘッダーを付けるべきか。頻出コードには「よくある誤用」の段も追加しています。本番のステータスコード問題の多くは「知らない」ことではなく「使い方を間違えている」ことだからです——業務上の失敗に 200、未ログインに 403、レート制限に 503。
ページ冒頭には7組の「紛らわしい比較」もあります。401 vs 403、301/302/307/308、400 vs 422、404 vs 410、502/503/504、200/201/202/204、429 vs 503。面接、コードレビュー、障害対応で最もよく聞かれる組み合わせです。
502）を入力すると、完全一致するカードが最上部に表示されます。「429」で検索して得られるカードの内容（抜粋）:
対応するバックエンドのレスポンスはこの形です:
429 Too Many Requests リクエスト過多 RFC 6585
意味 一定時間内にリクエストを送りすぎた（レート制限）。
場面 API のレート制限、ログイン試行の超過、クローラーの速度制限、AI API の毎分クォータ超過。
フロント Retry-After ヘッダー（秒数または日付）を読んで指数バックオフで再試行。ユーザーには「しばらくしてからもう一度」と伝える。すぐに再試行しない。
バックエンド Retry-After と RateLimit-* ヘッダーを付与。ユーザー / IP / API key 単位でカウントする。
誤用 レート制限に 403 や 503 を返すと、権限の問題なのか待つべきなのかクライアントが区別できない。HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
RateLimit-Limit: 60
RateLimit-Remaining: 0
RateLimit-Reset: 30
{"error":"rate_limited","message":"1分あたり最大60リクエスト。30秒後に再試行してください"}ステータスコードの1桁目がカテゴリを決めます。これは意図的です。クライアントが個別のコード（たとえば新しい 425）を知らなくても、カテゴリ単位で正しく扱えるようにしているからです。4xx は「そのまま再試行しない。問題はリクエスト側」、5xx は「後で再試行してよい」、3xx は「Location を見る」。RFC 9110 は、クライアントがカテゴリの意味を理解しなければならず、個別のコードを理解しなくてもよいと明記しています。だからこそ独自のステータスコードは正しい百番台に置く必要があります。
歴史的な命名ミスです。HTTP の初期には authentication（あなたは誰か）と authorization（あなたは何をしてよいか）を区別しておらず、401 は Unauthorized と名付けられました。しかし付随する WWW-Authenticate ヘッダーと「資格情報を再提示すれば成功するかもしれない」という意味が「認証」を語っています。RFC 9110 の §15.5.2 では "lacks valid authentication credentials" と表現が変わっています。一言で覚えるなら401 = ログインしてください、403 = ログインしてもダメです。フロントエンドはこれでログイン画面へ送るか「権限がありません」を出すかを決めます。逆に使うと、ログイン済みなのに何度もログイン画面へ蹴り返される現象が起きます。
よく使う4つのリダイレクトコードは実は 2×2 の行列です。301 と 308 は恒久（ブラウザーと検索エンジンが新しいアドレスを記憶）、302 と 307 は一時。歴史的にブラウザーは 301/302 を処理するとき POST を GET に変えていました。RFC 9110 はこの現実を認めつつ、307/308 で「メソッドとリクエストボディを必ず保持する」厳密版を提供しています。Web ページの https リダイレクトに 301 を使うのは問題ありません。API エンドポイントの移行では、POST リクエストに 307/308 を使わないとリクエストボディが失われます。
304 は「リクエストが1回節約できた」と誤解されがちです。実際にはブラウザーは If-None-Match / If-Modified-Since を付けた条件付きリクエストをサーバーへ送り、サーバーが比較して 304 をレスポンスボディなしで返しています。節約されるのは転送であって往復ではありません。リクエストそのものを節約するのは Cache-Control: max-age です（有効期間内はブラウザーがサーバーに問い合わせません）。両者は組み合わせて使います。max-age の期間内はそのまま使い、期限切れ後は条件付きリクエストで 304 を取って延命します。DevTools に "200 (from disk cache)" と出るのが前者、"304" が後者です。
本番で最もよく見る 5xx の組み合わせで、区別できると調査範囲を大きく絞れます。リバースプロキシ（Nginx、ゲートウェイ、CDN）が上流に接続できないか、上流が不正なものを返した——502。アプリのプロセスが落ちていないか確認します。上流が明示的にビジーまたはメンテナンス中と示した——503。通常は意図的に返されるもので、ヘルスチェックとサーキットブレーカーを見ます。上流がなかなか返さない——504。スロークエリとタイムアウト設定を見ます。Cloudflare はこの3つを 520–526 に細分化しており、521 ≈ 502（接続拒否）、522/524 ≈ 504（接続／読み取りタイムアウト）、525/526 は TLS 層の問題です。
最もよくあるアンチパターンは、すべてのリクエストで 200 を返し、エラーをレスポンスボディの code フィールドに入れることです。これでは CDN がエラーページをキャッシュし、監視システムの 5xx アラートが機能せず、ブラウザーの fetch().ok が意味を失い、再試行戦略も立てられません。正しいやり方は、HTTP ステータスコードで「リクエストの層で何が起きたか」（RFC 9110 の意味）を表し、レスポンスボディの業務コードで「業務層の詳細」を表すことです。両者は役割を分担し、互いを置き換えるものではありません。在庫不足は 422 + {"code":"OUT_OF_STOCK"} であり、200 + {"code":500} ではありません。
502 / 503 / 504 の対照表は、アプリが落ちたのか、トラフィックが外れたのか、遅いだけなのかを教えてくれます。Cloudflare の 52x カードは「オリジンのファイアウォール／証明書／タイムアウトを確認」という方向を直接示します。
カードの「フロントエンド／クライアント」欄に沿ってインターセプターを書きます。401 は token を更新するかログインへ、403 は権限なしを表示、429 は Retry-After を読んでバックオフ、5xx は回数を限って再試行し記録を送ります。
リソース作成は 201 + Location を返しているか? 削除は 204 か? 業務バリデーションの失敗は 400 か 422 か? レート制限に Retry-After を付けているか?「バックエンド」欄と「よくある誤用」欄がそのままレビューチェックリストになります。
7組の比較表が最もよくある「違い」系の質問をカバーします。「仕組み」では 401 の命名、307/308 が生まれた理由、304 の実際の役割を説明しています。
サイトの入口サーバー（ゲートウェイ）が、リクエストを実際に処理するバックエンドに接続できていません。多くの場合はバックエンドのプロセスが落ちたか再起動中です。ユーザー側は後で再読み込みするしかありません。自分のサイトなら、バックエンドのプロセスとゲートウェイのエラーログを確認してください。
クライアント側: Retry-After ヘッダーを読み、指定時間を待ってから再試行します。何度も失敗する場合は指数バックオフ（1s、2s、4s…）にし、ユーザーには「操作が多すぎます」と伝えます。サーバー側: 429 を返すときは必ず Retry-After を付け、できれば RateLimit-* ヘッダーも付けて、クライアントが事前に速度を落とせるようにします。
リクエストした対象によります。GET /users/123 で 123 が存在しない——404。GET /users?name=xxx の結果が空——200 + 空配列。一覧 API の空結果は「結果があり、その結果が空」という正当な状態で、エラーではありません。
204 にはレスポンスボディがありません。json() が空文字列を解析しようとして SyntaxError を投げます。response.status === 204（または response.headers.get('content-length') === '0'）を先に判定してから、解析するかを決めてください。
これらは nginx がアクセスログに書き込むための内部コードです。444 は nginx が接続をそのまま閉じて何も返さなかったこと、499 は nginx が応答する前にクライアントが切断したことを示します。ブラウザー側では「接続がリセットされました」と表示されるか、そもそも応答を受け取れません。
ステータスコードのデータはページと一緒に静的にダウンロードされ、検索・絞り込み・コピー・お気に入りはすべてブラウザー内で完結し、リクエストを送信しません。お気に入りは端末の localStorage に保存されます。外部リンクは RFC Editor、IANA、Cloudflare のドキュメントを指し、クリック後は相手サイト側で処理されます。
更新日 2026-09-09
RFC 9110 の全コード＋拡張コード＋nginx/Cloudflare の非標準コード計 72 件。各コードの意味、発生場面、フロントエンドとバックエンドの対処、よくある誤用を掲載。紛らわしい 7 組の比較付き。検索・コピー・お気に入り対応
このツールの翻訳は未完了です。一部は原文または代替言語で表示されます。
リクエストは受信され処理が続いています。ブラウザがページスクリプトにこれを公開することはほとんどありません。
リクエストヘッダーを受信しました。クライアントはリクエストボディの送信を続けられます。
RFC 9110 §15.2.1
サーバーは Upgrade ヘッダーによるプロトコル切り替えに同意しました。
RFC 9110 §15.2.2
サーバーはリクエストを受信して処理中ですが、最終レスポンスはまだありません。
RFC 2518（WebDAV、廃止）
最終レスポンスの前に一部のヘッダー（主に Link: preload）を先に送り、ブラウザにリソースを早く読み込ませます。
RFC 8297
リクエストは正常に受信・理解され、処理されました。
リクエストは成功し、ボディには要求されたリソースまたは操作の結果が入っています。
RFC 9110 §15.3.1
リクエストは成功し、新しいリソースが作成されました。
RFC 9110 §15.3.2
リクエストは受け付けましたが、まだ処理は完了していません。非同期タスクの受領証です。
RFC 9110 §15.3.3
レスポンスは成功ですが、内容は中間プロキシによって変更されています。
RFC 9110 §15.3.4
成功ですが、レスポンスボディはありません。
RFC 9110 §15.3.5
成功し、クライアントにドキュメントビューのリセット（フォームのクリアなど）を求めます。
RFC 9110 §15.3.6
リソースの一部だけを返します（Range リクエストの成功）。
RFC 9110 §15.3.7
ボディは XML で、各サブリソースがそれぞれのステータスを報告します。
RFC 4918（WebDAV）
207 レスポンス内で、同じリソースは先に報告済みなので繰り返しません。
RFC 5842（WebDAV）
サーバーが現在のインスタンスにインスタンス操作（差分エンコーディング）を適用し、差分を返しました。
RFC 3229
リクエストを完了するには、クライアントが追加のアクション（通常は別のアドレスへの再リクエスト）を行う必要があります。
リソースに複数の表現があり、クライアントが1つを選ぶ必要があります。
RFC 9110 §15.4.1
リソースは Location の新しい URL へ恒久的に移動しました。以後は新しい URL を使います。
RFC 9110 §15.4.2
リソースは一時的に別の場所にあります。次回も元の URL を要求します。
RFC 9110 §15.4.3
このリクエストのメソッドに関係なく、GET で Location から結果を取得します。
RFC 9110 §15.4.4
リソースは変わっていません。キャッシュにあるコピーを使ってください。
RFC 9110 §15.4.5
Location で指定されたプロキシ経由でのみリソースにアクセスできます。
RFC 9110 §15.4.6（非推奨）
草案ではプロキシ切り替えを意味しましたが、現在は予約され未使用です。
RFC 9110 §15.4.7
一時的なリダイレクトで、クライアントは同じメソッドとボディで再送する必要があります。
RFC 9110 §15.4.8
メソッドとボディも保つ恒久的リダイレクト（301 の厳格版）です。
RFC 9110 §15.4.9
リクエスト自体に問題があります。構文、認証、リソースの不在、頻度超過など。同じリクエストを再送しても成功しません。
サーバーがリクエストを理解できません。構文エラー、パラメーターの欠落や形式不正、JSON の解析失敗などです。
RFC 9110 §15.5.1
資格情報がないか無効です —「あなたは誰?」(名前は Unauthorized ですが、実際は未認証の意味です)。
RFC 9110 §15.5.2
将来のデジタル決済用に予約されており、仕様は具体的な意味を定義していません。
RFC 9110 §15.5.3（予約）
サーバーはあなたが誰かを知っていますが、権限がありません —「あなたはできない」。再認証しても無駄です。
RFC 9110 §15.5.4
サーバーは要求されたリソースを見つけられず、一時的か恒久的かも示しません。
RFC 9110 §15.5.5
リソースは存在しますが、この HTTP メソッドには対応していません。
RFC 9110 §15.5.6
Accept / Accept-Language の要件を満たす表現がサーバーにありません。
RFC 9110 §15.5.7
まずプロキシサーバーへの認証が必要です（401 のプロキシ版）。
RFC 9110 §15.5.8
サーバーがリクエストを待ちすぎました（クライアントが送り終えませんでした）。
RFC 9110 §15.5.9
リクエストがリソースの現在の状態と競合しています。リクエストを変更すれば解決できる場合があります。
RFC 9110 §15.5.10
リソースは以前存在しましたが、恒久的に削除され、転送先もありません。
RFC 9110 §15.5.11
サーバーはリクエストに Content-Length を要求しています。
RFC 9110 §15.5.12
リクエストヘッダーの条件（If-Match、If-Unmodified-Since）が満たされていません。
RFC 9110 §15.5.13
リクエストボディがサーバーの許容サイズを超えています。
RFC 9110 §15.5.14（旧称 Payload Too Large）
URL がサーバーで処理できる長さを超えています。
RFC 9110 §15.5.15
リクエストボディの形式（Content-Type）にサーバーが対応していません。
RFC 9110 §15.5.16
Range ヘッダーで要求したバイト範囲がリソースのサイズを超えています。
RFC 9110 §15.5.17
Expect ヘッダーの要求をサーバーが満たせません。
RFC 9110 §15.5.18
1998 年のエイプリルフール RFC のジョークで、実際の HTTP で使うべきではありません。
RFC 2324（エイプリルフール RFC）。RFC 9110 では未使用とされています
リクエストが、そのオーソリティ（ドメイン）の応答を出せないサーバーに届きました。
RFC 9110 §15.5.20
構文と形式は正しいものの、意味的に処理できません（業務バリデーションの失敗）。
RFC 9110 §15.5.21（旧称 Unprocessable Entity）
リソースはロックされています。
RFC 4918（WebDAV）
依存する操作が先に失敗したため、この操作も失敗しました。
RFC 4918（WebDAV）
再生される可能性のあるリクエストを処理したくない、というサーバーの意思表示です（TLS 1.3 0-RTT の早期データ）。
RFC 8470
サーバーは現在のプロトコルでの処理を拒否し、Upgrade ヘッダーで指定したプロトコルへの切り替えを求めます。
RFC 9110 §15.5.22
更新の消失を防ぐため、サーバーは条件ヘッダー（If-Match など）を要求しています。
RFC 6585
一定時間内にリクエストを送りすぎました（レート制限）。
RFC 6585
リクエストヘッダー（単一フィールドまたは合計）が大きすぎます。
RFC 6585
著作権や政府命令などの法的理由でリソースを提供できません。番号は小説『華氏451度』へのオマージュです。
RFC 7725
サーバーは自身の失敗、または正当なリクエストを処理できないことを把握しています。時間を置けば成功する場合があります。
サーバーが予期しない状態に遭遇し、リクエストを完了できませんでした。
RFC 9110 §15.6.1
リクエストの完了に必要な機能にサーバーが対応していません（多くの場合、未知のメソッド）。
RFC 9110 §15.6.2
ゲートウェイ/プロキシとして動くサーバーが、上流から無効な応答を受け取りました。
RFC 9110 §15.6.3
サーバーが一時的にリクエストを処理できません（過負荷またはメンテナンス）。多くは一時的です。
RFC 9110 §15.6.4
ゲートウェイ/プロキシが上流の応答を待ちすぎてタイムアウトしました。
RFC 9110 §15.6.5
リクエストで使われた HTTP メジャーバージョンにサーバーが対応していません。
RFC 9110 §15.6.6
コンテンツネゴシエーションの設定ミスがループを生んでいます。
RFC 2295
リクエストに必要な内容をサーバーが保存できません。
RFC 4918（WebDAV）
リクエスト処理中に無限ループを検出しました。
RFC 5842（WebDAV）
サーバーが処理するには、リクエストをさらに拡張する必要があります。
RFC 2774（歴史的）
ネットワーク層（キャプティブポータル）での認証を先に行う必要があります。
RFC 6585
どの RFC にも載っておらず、特定のサーバーのログや CDN のエラーページにだけ現れます。知っておくと調査の時間を大幅に節約できます。
nginx が応答を一切返さず接続を閉じます。nginx のログにだけ現れます。
nginx 独自
サーバーが応答する前にクライアントが切断しました。nginx のログにだけ現れます。
nginx 独自
オリジンが Cloudflare に返した応答が空・不正、またはヘッダーが大きすぎました。
Cloudflare 独自
Cloudflare がオリジンに到達できません（TCP 接続が拒否されました）。
Cloudflare 独自
Cloudflare からオリジンへの TCP 接続がタイムアウトしました。
Cloudflare 独自
Cloudflare がオリジンへルーティングできません（DNS またはネットワーク経路の問題）。
Cloudflare 独自
TCP は接続できましたが、オリジンが 100 秒以内に HTTP 応答を返しませんでした。
Cloudflare 独自
Cloudflare とオリジン間の TLS ハンドシェイクに失敗しました。
Cloudflare 独自
Full (strict) モードで、オリジンの証明書が期限切れ・自己署名・ドメイン不一致です。
Cloudflare 独自