502・503・504エラーの原因と切り分け｜Webサーバー・アプリ・DBのどこで詰まっているか

深夜に「サイトが502で開けません」という連絡が来て、とりあえずサーバーを再起動したら直った。しかし原因が分からないので、また起きるのではないかと不安なまま——こうした経験は多くの運用担当者にあるはずです。502・503・504は「サーバーの奥のどこかで詰まっている」ことしか教えてくれないため、当てずっぽうで対応しがちです。

この記事では、502・503・504それぞれの意味と、CDN・ロードバランサー・Nginx・アプリのどの層がそのエラーを返しているかを見分ける方法、典型的な原因（アプリ停止、ソケットの不一致、タイムアウト、ワーカー枯渇、DB接続待ち）、ログを見る順番、再現と暫定対処、恒久対策までを一本の手順として解説します。ログの場所やjournalctlの使い方はLinuxのログ管理入門で扱っているので、ここでは「何を、どの順に見るか」に集中します。

502・503・504の意味｜「誰が」「何に困って」返しているか

3つのエラーは中継役の悲鳴

5xx系のうち502・503・504は、いずれも「リクエストを受け取った中継役（プロキシ）が、後ろにいる本来の処理役（アップストリーム）とうまくやり取りできなかった」ときに返されます。中継役とはNginx、ロードバランサー、CDNなどで、処理役とはアプリサーバー（Gunicorn、PHP-FPM、Node.js、Pumaなど）や、さらにその奥のバックエンドです。

ステータス	意味	中継役から見た状況	典型的な原因
502 Bad Gateway	アップストリームから不正な応答、または接続できなかった	「つないだが相手がいない／変な返事が来た」	アプリプロセス停止、ソケットパス・ポートの不一致、アプリのクラッシュ、応答ヘッダーが大きすぎる
503 Service Unavailable	サービスが一時的に利用できない	「受け付けられる状態ではない」	メンテナンスモード、LBの正常なターゲットがゼロ、ワーカー・接続数の上限超過、レート制限
504 Gateway Timeout	アップストリームからの応答が時間内に来なかった	「つないだが返事が遅すぎる」	重いクエリやN+1、DB接続待ち、外部APIの遅延、ワーカーが全部塞がっている

覚え方として、502は「つながらない」、503は「受け付けない」、504は「返ってこない」です。この違いだけで、次に見るべき場所がかなり絞れます。

どの層が返しているかを見分ける

同じ502でも、CDNが返したのか、ロードバランサーが返したのか、Nginxが返したのかで原因の場所が変わります。見分ける手がかりは応答ヘッダーとボディです。

# ヘッダーだけを見る（-I）。Server・Via・cf-ray などから返している層を推定する
curl -sI https://example.com/ | head -20

# 例：Cloudflareが返している場合  → server: cloudflare, cf-ray: ... が付く
# 例：ALBが返している場合        → server: awselb/2.0
# 例：Nginxが返している場合      → server: nginx、ボディに <center>nginx</center>
# CDNやLBを迂回して直接オリジンに聞く（Hostヘッダーを付けてIP直打ち）
curl -sI -H "Host: example.com" http://10.0.11.21/ | head -5

「CDN経由だと502だがオリジン直打ちだと200」なら、原因はCDNとオリジンの間（証明書、Hostヘッダー、オリジン側のファイアウォール）にあります。「オリジン直打ちでも502」なら、Nginxより後ろの問題です。このように、手前の層を1枚ずつ剥がして、どこまで正常かを確認するのが切り分けの基本動作です。Webサーバーとアプリサーバーの役割分担が曖昧な方は、先にWebサーバーとアプリケーションサーバーの違いを読んでおくと以降が理解しやすくなります。

典型原因と特定方法｜502編

アプリプロセスが動いていない

最も多いのがこれです。デプロイ直後の起動失敗、OOM Killerによる強制終了、依存ライブラリの欠落によるクラッシュなどで、Nginxの向き先にプロセスがいない状態です。

# プロセスの状態と直近のログ
systemctl status myapp
journalctl -u myapp -n 100 --no-pager

# Nginxのエラーログには「connect() failed (111: Connection refused)」が出る
tail -n 50 /var/log/nginx/error.log

# OOM Killerに殺されていないか
dmesg -T | grep -i -E "killed process|out of memory" | tail

「Connection refused」は「そのアドレス・ポートで誰も待ち受けていない」という意味なので、アプリの起動失敗か、次に述べる向き先の不一致が原因です。

ソケット・ポートの不一致と権限

Nginxはproxy_pass http://127.0.0.1:8000;に投げているのに、アプリは0.0.0.0:3000で待ち受けている。あるいはNginxはunix:/run/myapp.sockを見ているのに、アプリはソケットを/tmp/myapp.sockに作っている。Unixソケットの場合は、ソケットファイルの所有者・パーミッションが原因で「Permission denied (13)」になることもあります。

# 実際に待ち受けているアドレスとポートを確認
ss -ltnp | grep -E "8000|3000"

# Unixソケットの存在と権限
ls -l /run/myapp.sock

# Nginx側の向き先を確認
grep -rn "proxy_pass\|fastcgi_pass" /etc/nginx/

localhost・0.0.0.0・Unixソケットの違いによる「つながらない」は非常に多いので、localhost・0.0.0.0・127.0.0.1の違いもあわせて参照してください。

典型原因と特定方法｜503・504編

503：ワーカー枯渇とヘルスチェック失敗

ロードバランサーが返す503の典型は「正常なターゲットがゼロ」です。アプリ自体は動いていても、ヘルスチェックのパスが404を返していたり、応答が遅くて閾値を超えたりすると、LBは全ターゲットを異常と判定し、振り分け先がなくなって503を返します。この場合、LBのターゲットグループの状態を最初に確認します。

Nginx自身が503を返すケースでは、limit_connやlimit_reqによる制限、PHP-FPMのプロセス上限（pm.max_children）到達、あるいはメンテナンス用の設定が残っている、といった原因が多く見られます。

# ALBのターゲットの健全性を確認（healthy がゼロなら503の原因）
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:...

# PHP-FPMがプロセス上限に達しているか（ログに "server reached pm.max_children" が出る）
grep "max_children" /var/log/php8.3-fpm.log | tail

# Nginxのレート制限で弾かれているか（"limiting requests" / "limiting connections"）
grep -E "limiting (requests|connections)" /var/log/nginx/error.log | tail

504：タイムアウトの連鎖

504は「アプリに届いたが処理が終わらない」状態です。原因の多くはアプリの外にあり、DBの重いクエリ、ロック待ち、コネクションプール枯渇、外部APIの応答遅延が代表例です。ここで見るべきは、Nginxのタイムアウト値と、アプリのワーカーが今何をしているかです。

# Nginxのタイムアウト設定（デフォルトは proxy_read_timeout 60s）
grep -rn "proxy_read_timeout\|proxy_connect_timeout" /etc/nginx/

# PostgreSQLで長時間実行中のクエリと待機状態を確認
psql -c "SELECT pid, now() - query_start AS running, state, wait_event_type, left(query, 80)
         FROM pg_stat_activity
         WHERE state <> 'idle' ORDER BY running DESC LIMIT 10;"

# アプリのワーカーが全部使用中か（Gunicornの例：プロセス数とCPU状態）
ps -o pid,stat,etime,cmd -C gunicorn

タイムアウトの値は「Nginx＞アプリのワーカータイムアウト＞DB・外部APIのタイムアウト」という順に、外側ほど長くなるように設計します。内側にタイムアウトがないと、1件の遅い外部APIがワーカーを何十秒も占有し、それが積み重なってワーカー全滅→504（あるいは503）へと連鎖します。この設計はタイムアウト・リトライ・サーキットブレーカーで詳しく扱っています。

ログを見る順番と切り分けの手順

外側から内側へ、時刻を揃えて

障害時に見るログの順番を決めておくと、慌てずに済みます。ポイントは、利用者がエラーを見た時刻を起点に、各層のログを同じ時刻で突き合わせることです。

1. 監視・LB・CDNのダッシュボード：5xxの割合がいつから上がったか、全リクエストか一部か（特定のパスや端末だけか）。
2. Nginxのerror.log：「upstream」を含む行を探す。Connection refusedなら502（アプリ不在）、upstream timed outなら504、no live upstreamsなら全アップストリーム異常。
3. アプリのログ／systemdジャーナル：クラッシュ、例外、起動失敗、ワーカータイムアウト（Gunicornなら「WORKER TIMEOUT」）。
4. DB・外部依存：スロークエリログ、接続数、ロック待ち、外部APIのステータス。
5. OSレベル：メモリ（OOM）、ディスクフル、ファイルディスクリプタ上限、CPU飽和。

# 障害時刻付近のNginxエラーを種類別に集計する（時刻は例）
grep "2026/09/02 03:1" /var/log/nginx/error.log \
  | grep -oE "upstream (timed out|prematurely closed)|Connection refused|no live upstreams|Permission denied" \
  | sort | uniq -c | sort -rn

トラブル事例：毎朝9時に数分間だけ504

症状：平日の9時前後に数分間だけ504が多発し、その後は自然に回復する。再起動しても関係なく、翌朝また起きる。

原因：Nginxのerror.logにupstream timed out (110: Connection timed out) while reading response headerが集中しており、同時刻のPostgreSQLのpg_stat_activityには、夜間バッチが作った巨大テーブルへの集計クエリが数十秒かかって残っていた。9時の出社直後のアクセス集中とこのクエリが重なり、コネクションプールが枯渇、以降のリクエストがすべて接続待ちになってワーカーが埋まり、Nginxの60秒でタイムアウトしていた。

暫定対処：問題の集計クエリにstatement_timeoutを設定して長時間実行を打ち切り、ワーカーが解放されるようにした。

恒久対策：集計に必要なインデックスを追加し、集計結果を夜間バッチ側で事前計算するよう変更。さらにPgBouncerを導入してアプリからの接続数を制御し、DB側の接続待ちを可視化した。プーリングの設計はデータベースのコネクションプーリング入門を参照してください。

再現・暫定対処・恒久対策の進め方

まず止血、次に原因、最後に再発防止

障害対応では「原因究明」と「復旧」を分けて考えます。利用者が困っている間は復旧が最優先ですが、再起動する前にログとプロセス状態を保全しておかないと、原因が永遠に分からなくなります。

1. 保全：ss -tnp、ps aux、free -m、df -hの出力と、直近のNginx・アプリ・DBのログをファイルに退避する（30秒で終わる）。
2. 暫定対処：プロセス再起動、問題クエリの停止、ワーカー数やタイムアウトの一時的な緩和、問題のある機能のフラグオフなど、影響が小さい順に試す。
3. 再現：ステージングで同じ負荷やデータ量を再現し、原因を確定する。再現できない仮説での「対策」は、たいてい別の問題を生む。
4. 恒久対策：タイムアウトの階層設計、ヘルスチェックの見直し、リソース上限の適正化、監視アラートの追加（5xx率、ワーカー使用率、DB接続数）。

再発防止として特に効果が高いのは、「5xxの割合」と「アプリのワーカー使用率」と「DB接続数」の3つにアラートを設定することです。504が出てから気づくのではなく、ワーカーが8割埋まった時点で気づければ、多くの障害は未然に防げます。

まとめ

502は「つながらない」、503は「受け付けない」、504は「返ってこない」。この違いと、応答ヘッダーからどの層が返しているかを見分ける手順があれば、当てずっぽうの再起動から卒業できます。原因はアプリの停止、ソケット・ポートの不一致、ヘルスチェック失敗、ワーカー枯渇、タイムアウトの連鎖に集約され、外側から内側へ時刻を揃えてログを追えば、ほとんどは特定できます。そして再起動の前に状態を保全し、暫定対処の後に再現と恒久対策へ進むことが、同じ障害を二度と起こさないための道筋です。

まずは本番のNginxのerror.logで「upstream」を含む行を集計し、自社で起きている5xxの型を把握するところから始めてみてください。障害の根本原因の調査や、タイムアウト・監視設計の見直しに専門的な支援が必要な場合は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。