502 Bad Gateway：原因と対処法

エラーの意味

502 は、正常に動いているサーバーからの応答です。手前のウェブサーバー（nginx、Apache、ロードバランサー、Cloudflare などの CDN）はリクエストを受け取り、背後のアプリケーション（PHP-FPM、Node.js や Python のプロセス、バックエンドサーバー）に渡しましたが、使える応答が返ってきませんでした。接続が拒否された、切断された、または意味のないデータが返された、という状態です。「Gateway」は手前のサーバー、「bad」は背後から返ってきたものを指します。

つまり 502 は、手前は動いていて、背後が停止しているか壊れている、という 2 つのことを同時に伝えています。これで、探す範囲は大きく絞られます。

よくある原因

1. アプリケーションのプロセスが動いていません。 PHP-FPM がクラッシュした、または停止した、Node.js のプロセスが終了した、コンテナが終了した。手前からはまったく接続できません。
2. アプリケーションが過負荷です。 PHP-FPM のワーカーがすべて使用中で、キューが満杯になり、新しい接続が拒否されます。アクセスの急増や、すべてのワーカーを止めてしまう遅いデータベースクエリの後に起こりがちです。
3. 設定のソケットまたはポートが間違っています。 アップデートや PHP のバージョン変更の後も、nginx が php8.2-fpm.sock を指したままで、新しいプールは php8.4-fpm.sock で待ち受けています。
4. タイムアウトの設定が厳しすぎます。 バックエンドは応答しますが、手前が待つ時間より遅れています。この状態を 502 として報告する環境もあれば、504 Gateway Timeout として報告する環境もあります。
5. バックエンドが大きすぎるヘッダーや不正な応答を送っています。 Cookie に多くを入れるフレームワークに典型的で、nginx は「upstream sent too big header」と記録します。
6. CDN がサーバーに到達できません。 Cloudflare を手前に置いている場合、Cloudflare のロゴ付きの 502 ページは、Cloudflare がオリジンから何も受け取れなかったことを意味します。原因は、ファイアウォール、移転後の誤った IP、またはサーバー自体のダウンです。

訪問者の場合

他人のサイトの 502 は、修復できません。1 分後に一度再読み込みしてください。それでも続く場合は、サイトの運営者が対応する必要があります。ご自身のサイトの場合は、このまま読み進めてください。

ご自身のサイトの場合：まず確認

すべての人に対してダウンしていますか？ ウェブサイトダウンチェッカーを実行してください。外部からのステータスコードと、CDN とオリジンのどちらが応答したかがわかります。

共有ホスティングやサイトビルダーですか？ その場合、502 はほぼ確実にホスティング会社側の問題です（共有ノード上の PHP プールの過負荷）。下の、ホスティング会社向けの文面に進んでください。

ご自身のサーバー： SSH でログインし、ウェブサーバーに何が起きたかを確認します。

# nginx：直近のエラー、最新が一番下
sudo tail -n 50 /var/log/nginx/error.log

# Apache（Debian/Ubuntu）
sudo tail -n 50 /var/log/apache2/error.log

典型的な行とその意味：

• connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)：PHP-FPM が動いていないか、ソケットのパスが間違っています。
• connect() failed (111: Connection refused) while connecting to upstream：バックエンドのポートが待ち受けていません。
• upstream prematurely closed connection：バックエンドのプロセスが応答中にクラッシュしました。多くは PHP の致命的エラーやメモリ不足です。
• upstream sent too big header：バッファを増やしてください（下記参照）。
• (11: Resource temporarily unavailable)：PHP-FPM のワーカーがすべて使用中です。

ご自身のサーバーでの対処法

1. 停止したサービスを起動する

# 使用している PHP-FPM のバージョンを調べる
systemctl list-units --type=service | grep -E 'php|fpm'

systemctl status php8.3-fpm
sudo systemctl start php8.3-fpm

# systemd で管理されている Node.js や Python のアプリ
sudo systemctl restart myapp

サービスが起動しない場合、理由は journalctl -u php8.3-fpm -n 50 に出ています。最も多いのはディスクの満杯（df -h）、次に多いのはプール設定の構文エラーです（sudo php-fpm8.3 -t）。

2. ソケットまたはポートを修正する

nginx の接続先と、PHP-FPM の待ち受け先を比較します。

grep -r fastcgi_pass /etc/nginx/sites-enabled/
grep -r '^listen' /etc/php/*/fpm/pool.d/

この 2 つは一致している必要があります。変更後は、再読み込みの前に、必ず設定をテストしてください。

sudo nginx -t && sudo systemctl reload nginx

mod_proxy_fcgi 経由で Apache と PHP-FPM を使っている場合は、SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost" の行にも同じ確認が必要です。sudo apachectl configtest でテストしてください。

3. PHP-FPM に余裕を持たせる

エラーログにワーカーが使用中、または server reached pm.max_children と出ている場合は、プールのファイル（/etc/php/8.3/fpm/pool.d/www.conf）で上限を引き上げます。

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

各ワーカーにはメモリが必要です（WordPress では 30～80 MB のことが多い）。数値を上げる前に free -m を確認し、そもそもワーカーを塞いでいる遅いクエリやプラグインを探してください。

4. 大きなヘッダーに備えてバッファを増やす

nginx の server ブロックで：

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffers 8 16k;
proxy_buffer_size 32k;

5. WordPress の場合

プラグインやテーマの更新の直後の 502 は、通常、PHP のメモリ不足か、リクエストのたびに致命的エラーが起きていることを意味します。SFTP または SSH でプラグインのフォルダー名を変更して無効にし（wp-content/plugins/plugin-name を plugin-name.off に）、サイトを再読み込みしてください。journalctl に「Allowed memory size exhausted」と出ている場合は、プールまたは php.ini の memory_limit を引き上げます。WP-CLI を使っている場合：wp plugin deactivate plugin-name。

6. Cloudflare の背後の場合

オリジンが直接応答するか確認します：curl -I https://YOUR-SERVER-IP -H 'Host: example.com' -k。これが動作する場合は、サーバーのファイアウォールが Cloudflare のアドレス範囲をブロックしているか、Cloudflare の DNS レコードが古い IP を指している可能性があります。

ホスティング会社の問題の場合

共有ホスティングでは、PHP-FPM を再起動できません。時刻と正確なエラーを添えて、ホスティング会社に次の文面を送ってください。

お世話になっております。ウェブサイト example.com が、14:30 UTC 頃から「502 Bad Gateway」を返しています。外部からのチェックでも確認できており、こちらでは何も変更していません。ホスティングアカウントの PHP プロセスとウェブサーバーを確認し、復旧したらお知らせいただけますでしょうか。

次回に備えて

502 はほぼ必ず、停止または過負荷のバックエンドが原因で、どちらも訪問者が気づく前に把握できます。停止した PHP-FPM のサービス、足りなくなるメモリ、満杯に近づくディスク。エージェントによるサーバー監視は、まさにこれらをサーバーの内部から報告し、外部からのウェブサイトのチェックは、502 が発生した瞬間に検知します。ご自身のサーバーでは、設定テストに合格した後で、Quick Fix が停止したサービスを再起動できます。原因がもっと深い場合は、Deep Fix が 24 時間体制で引き継ぎます。