「このエラー、何が原因？」を現象から逆引きできるようにまとめました。エンジニアもインフラ担当も、まずはこの一覧で当たりをつけてから深掘りするのが早いと思います。
今回は4xx系と5xx系のみです。
HTTPステータスコードは百の位を見れば、責任の所在がだいたいわかります。
- 4xx系：リクエストを送った側（ブラウザ、アプリ、ユーザー）に原因がある
- 5xx系：受け取った側（サーバー、DB、API）に原因がある
この区別さえつけば、調査すべき場所を無駄に間違えずに済みます。
1. 現象から逆引きする
| こういう状況のとき | コード | 原因はどっち側？ |
|---|---|---|
| URLを打ち間違えた、ページが消えている | 404 Not Found | クライアント側 / 配置ミス |
| ログインしていない状態でアクセスした | 401 Unauthorized | クライアント側（未認証） |
| 権限がなくて弾かれた、IP制限に引っかかった | 403 Forbidden | クライアント側 or サーバー設定 |
| 送ったデータの形式がおかしい、必須項目が抜けている | 400 Bad Request | クライアント側（実装ミス） |
| 短時間にリクエストを送りすぎた | 429 Too Many Requests | クライアント側（過剰アクセス） |
| プログラムが例外を吐いて落ちた | 500 Internal Server Error | サーバー側（コードのバグ） |
| プロキシの後ろのアプリと通信できない | 502 Bad Gateway | サーバー側（起動・設定不備） |
| アクセス集中でサーバーが応答しない、メンテ中 | 503 Service Unavailable | サーバー側（負荷過多） |
| 待っても応答が返らずタイムアウトした | 504 Gateway Timeout | サーバー側（処理が重い・外部遅延） |
2. それぞれの詳細
400 Bad Request
サーバーが「リクエストの中身が理解できない」と突き返してくるパターンです。JSONの構文が壊れている、必須パラメータが足りない、ヘッダーが大きすぎる、といったことが典型的な原因です。まずは送信しているペイロードをそのままダンプして、APIの仕様と突き合わせるのが確実です。
401 Unauthorized
認証情報がない、または間違っている状態でアクセスしたときに返ってきます。セッション切れ、APIトークンの期限切れ、Authorizationヘッダーの書き方ミスなどが多いです。再ログインしてトークンを取り直せば大抵は解決します。
403 Forbidden
401との違いは「誰かはわかっているが、そもそも立ち入り禁止」という点です。管理者専用ページに一般ユーザーがアクセスした場合や、ファイル・ディレクトリのパーミッション設定ミス、WAFやIP制限による誤検知などが原因になります。サーバー側ならchmodや.htaccess、Nginxの設定、WAFのログを見に行くのが早いです。
404 Not Found
指定したURLに対応するものが存在しないときのエラーです。単純なタイポ、ページの削除、あるいはアプリ側のルーティング定義漏れが主な原因です。地味ですが、ルーティングの設定を先に疑うと早く解決することが多い印象です。
429 Too Many Requests
決められたレート制限を超えてリクエストを送ったときに返ります。ループ処理のバグでリクエストが連発している、スクレイピングが激しい、といったケースが典型です。対策としては、リクエストの間隔を空ける、失敗時は指数バックオフで再試行する、という2つが基本になります。
500 Internal Server Error
サーバー側のプログラムが処理中に想定外の例外を起こして止まってしまった状態です。5xx系の中でも最も頻出します。原因はnullチェック漏れ、DB接続失敗、メモリ不足など様々で、ブラウザの画面だけでは特定できません。アプリケーションのエラーログとスタックトレースを見るのが唯一の近道です。
502 Bad Gateway
Nginxやロードバランサーなど、手前のプロキシが後ろのアプリケーションサーバーから正常な応答を受け取れなかったときに出ます。多くの場合、アプリのプロセス自体が落ちているか、ポートやソケットの設定がプロキシ側と噛み合っていません。まずは後ろのプロセスが生きているか確認するのが第一歩です。
503 Service Unavailable
サーバーが一時的にリクエストを処理できない状態です。アクセス集中によるリソース枯渇、DBの接続数上限到達、あるいは意図的なメンテナンスモードが原因になります。恒常的に発生するなら、スペックアップやサーバー台数を増やすといった構成の見直しが必要です。
504 Gateway Timeout
502と混同されがちですが、こちらは「後ろのサーバーは生きているが、応答が規定時間内に返ってこない」状態です。重いDBクエリ、インデックス未設定、外部APIの遅延などが原因になりやすいです。スロークエリを洗い出す、時間のかかる処理は非同期のキュー処理に逃がす、あるいはプロキシ側のタイムアウト値そのものを見直す、といった対応が有効です。
補足：400番台と500番台、どちらか迷ったら
「クライアントが送った内容自体に問題があるか」を基準に考えると判別しやすいです。送信内容や権限に問題があれば4xx、リクエストは正しいのに受け手側の処理でこけていれば5xx、という整理で大体のケースは説明がつきます。
終わりに
困ったら見る程度でいいかなと思います