HTTP 502/504が出る時の切り分け

URLをコピーしました！

Webシステム運用で頻発するエラーが HTTP 502 / 504 です。

急に 502 Bad Gateway が出始めた
負荷が上がると 504 Gateway Timeout になる
curlでもブラウザでも同じエラーが返る

これらはアプリが直接返しているエラーではなく、多くの場合 LB・プロキシ・Webサーバが返している点が重要です。

本記事では、 502 / 504 が出る仕組みの違いを整理し、 実務でそのまま使える切り分け手順と対策を解説します。

まず結論：502と504の違い

ステータス	意味	主な原因
502 Bad Gateway	不正な応答を受信	バックエンド異常・接続リセット
504 Gateway Timeout	応答待ちでタイムアウト	バックエンド遅延・ハング

共通点は「中継装置がバックエンドと通信できていない」ことです。

切り分け全体像（最短ルート）

どのレイヤがエラーを返しているか確認
LB / プロキシ → バックエンド疎通確認
アプリ応答時間・プロセス状態確認
タイムアウト値の不整合確認

① エラーを返しているのは「誰か」を確認する

curlでレスポンスヘッダ確認

curl -v http://example.com

注目ポイント

Server ヘッダ（nginx / envoy / awselb 等）
Via / X-Forwarded-* ヘッダ

ここでLB・リバースプロキシが返していると分かれば、原因はその先（バックエンド）です。

② LB → バックエンドのTCP疎通確認

バックエンドポートがLISTENしているか

ss -lntp | grep 8080

LBと同じネットワークから疎通確認

nc -vz バックエンドIP ポート番号

ここで失敗 → 502 の典型原因

③ バックエンドアプリが応答しているか

TCP接続はできても、 アプリがHTTP応答を返していないケースがあります。

ローカルからcurl

curl -v http://127.0.0.1:8080

典型パターン

プロセスは生きているがスレッド枯渇
DB待ちで応答停止

④ 504の典型原因：応答遅延・タイムアウト

504は「応答は来るが、遅すぎる」時に発生します。

確認

curl -v --max-time 10 http://example.com

見るべき設定

LB idle timeout
proxy_read_timeout（nginx）
アプリ側KeepAlive / 処理時間

⑤ タイムアウト値の不整合

以下のような構成は高確率で504を生みます。

レイヤ	タイムアウト
LB	30秒
Web	60秒
アプリ	120秒

→ LBが先に諦める

対策

外側ほど長く、内側ほど短く

⑥ バックエンドが死んでいる／落ちている

プロセス確認

ps aux | grep java
systemctl status アプリサービス名

OOM・再起動確認

dmesg | grep -i oom
journalctl -u アプリサービス名

OOM → 再起動 → 一時的に502は非常に多いです。

⑦ LBのヘルスチェック失敗

LBはUnhealthyなバックエンドを即座に切り離します。

確認

ヘルスチェックURL
HTTPステータス

アプリが200以外を返すと即502になります。

⑧ 502が断続的に出る場合

コネクション上限超過
短命TCP大量発生
TIME_WAIT / CLOSE_WAIT 枯渇

確認

ss -s
ss -ant | wc -l

即解決用チェックリスト

誰が502/504を返しているか
LB → バックエンド疎通
アプリはHTTP応答しているか
タイムアウト値は整合しているか
OOM・再起動は起きていないか

まとめ

HTTP 502 / 504 はネットワーク障害ではありません。

502 → 接続・応答異常
504 → 応答遅延

中継装置 → バックエンド → アプリの順で確認すれば、必ず原因に辿り着けます。