ログに 502 と 504 が並んでいる。どっちを疑えばいいのか。 401 と 403 の違いを、毎回検索し直している。 「このコード、RFC に載っているのか」を一度で確かめたい。 このツールは、64 件のステータスコードを番号や語句で絞り込み、意味・よくある原因・対処・関連ヘッダー・出典をまとめて表示します。
使い方
- 検索欄に番号（例:
429）か語句（例:タイムアウト、Retry-After）を入れます。全角の数字も半角に直して検索されます。 - 入力するたびに結果が絞り込まれ、件数が「◯ / 64 件が一致しました。」と出ます。
- 一致のあった区分（1xx〜5xx）の見出しは自動で開きます。何も入力していないときは 4xx だけが開いています。
- 各コードには、意味・よくある原因・対処・関連ヘッダー・出典が出ます。418 や 499 のような標準外のコードには、タグが付きます。
検索は「番号の部分一致」と「説明文の部分一致」の両方を見ています。
仕組み・計算式
収録の基準は RFC 9110（HTTP Semantics）です。1xx〜5xx の標準コードはここを土台にしています。そのほか、RFC 6585（429、431、511 など）、RFC 7725（451）、RFC 8297（103 Early Hints）、RFC 8470（425 Too Early）、WebDAV 由来の RFC 4918 と RFC 5842 を出典に挙げたコードを入れています。
418 は RFC 2324 の冗談から生まれたコードで、RFC 9110 には規定がありません。499 は nginx が独自に使うコードで、標準ではありません。どちらも現場で目にするので、「非標準」のタグを付けて載せています。
名称が変わったコードもあります。413 は旧称 Payload Too Large から Content Too Large へ、422 は Unprocessable Entity から Unprocessable Content へ改められました。資料によって呼び方が違うのは、この改称のためです。
検索のしくみは、計算ではなく単純な部分一致です。番号は文字列として部分一致を見ます。英語名・意味・原因・対処・関連ヘッダーは、大文字小文字を区別せずに文字列を探します。リダイレクトだけは、メソッドの扱いに差があります。301 と 302 は歴史的にクライアントが POST を GET に変える実装が残っていて、メソッドとボディを保つことが決まっている 308 と 307 が、その穴を埋める位置づけです。
計算例
この節は計算ではなく「入力したら何が出るか」の例です。ツールの検索ロジックと収録データを node に読み込ませ、実際に出た件数と番号を書き写しています。
例1: 429 と入れる
一致は 429 の 1 件だけでした。4xx の区分に出て、原因は「短時間の連続アクセス、API クォータ超過」など、対処は「Retry-After で示された時間だけ待って再試行する」、関連ヘッダーは Retry-After、出典は RFC 6585 です。
例2: タイムアウト と入れる
4 件が一致しました。102、408、499、504 です。504 だけでなく、499 や 408 も出ます。「タイムアウトした」という症状は 1 つでも、見る場所が複数あるとわかります。
例3: 4 とだけ入れる（境界の例）
これは意外でした。4xx がまとめて出るのかと思ったら、33 件が出て、そこには 204、304、504 も混じっています。番号に「4」を含むコードがすべて拾われるからです。4xx だけを見たいなら、見出し「4xx client error」の開閉を使うほうが早いです。
例4: 50 と入れる
9 件で、500 から 508 です。510 と 511 は番号に「50」を含まないため、出ません。
例5: Retry-After と入れる
429 と 503 の 2 件が出ます。小文字の retry-after でも同じ結果でした。
よくある間違い
1. 502、503、504 を同じ「サーバーエラー」として扱う
どれも 5xx なので、まとめて「サーバーが落ちた」と考えがちです。でも原因の方向が違います。502 はプロキシが上流から不正な応答を受け取った場合で、アプリのクラッシュや再起動中が典型です。504 は上流が時間内に応答しなかった場合で、重い処理やタイムアウト設定を疑います。503 はサーバーが一時的に処理できない状態で、過負荷やメンテナンス、ヘルスチェックの失敗が典型です。
確かめ方は、リバースプロキシのログと上流アプリのログを並べて見ることです。上流に届いた形跡があるかどうかで、502 と 504 の切り分けが進みます。
2. 401 と 403 を逆に使う
「ログインしていない」のに 403 を返す、「権限がない」のに 401 を返す、という実装はよく見ます。401 は認証が無い、または無効で、再認証で直る可能性があります。403 は認証済みでも権限がなく、再ログインしても変わらないことが多いコードです。
画面に出たコードだけで判断すると、デバッグの方向を誤ります。401 のときは WWW-Authenticate ヘッダーが付いているかを見てください。
3. 301 や 302 のリダイレクトで POST が GET に変わると気づかない
API の URL を移したあと、POST が通らなくなったことはありませんか。301 と 302 では、クライアントが POST を GET に変えて再送する実装が残っています。メソッドとボディを保ちたい場合は、恒久なら 308、一時なら 307 を使います。
4. 418 や 499 を仕様のコードだと思い込む
418 は冗談、499 は nginx の内部ログ用のコードです。499 はクライアントに返るレスポンスではないので、ブラウザの開発者ツールには出ません。アクセスログで 499 を見たときは、クライアントが応答を待たずに切断した、という意味で読みます。
よくある質問
Q. 401 と 403 の違いは何ですか？
A. 401 は認証情報が無い、または無効な状態です。403 は認証済みでも権限がなく拒否された状態です。ツールで 401 と 403 を続けて検索して、対処の欄を見比べると違いがつかみやすいです。
Q. 404 と 410 はどう使い分けますか？
A. 404 は「見つからない」という一般的な表現です。410 は恒久的に削除され、今後も戻らないことを明示したいときに使います。意図して消したページには 410 が向いています。
Q. 429 が返ってきたらどうしますか？
A. Retry-After ヘッダーに示された時間だけ待ってから再試行するのが基本です。連続して失敗するなら、待ち時間を段階的に延ばすバックオフを足します。ヘッダーが付いていないサーバーもあるので、ドキュメントの確認が先です。
Q. 全部のコードが載っていますか？
A. 載っていません。RFC 9110 の標準コードと、実務で見かける主な拡張コード（WebDAV 系、RFC 6585 系、nginx の 499 など）の計 64 件です。クラウドサービスなど各社が独自に決めたコードは収録していません。
関連ツール
最終更新・根拠の確認日: 2026-10-12 · カテゴリ: 開発・データ