2026年10月15日

WordPressの「502 Bad Gateway」を解決する方法｜エラーログの読み方とPHP-FPM・プラグイン側の原因を多い順に確認

エラー・白い画面

WordPress の「502 Bad Gateway」は、手前の Web サーバー（nginx など）や CDN が、奥で動く PHP（PHP-FPM）から正常な応答を受け取れなかったときに表示されます。多くの場合、PHP-FPM が停止している・処理しきれない・処理中に落ちている、のいずれかです。この記事では、502 を返したのがどの層かを見分け、エラーログの文言から原因を絞り込み、WordPress のプラグインや設定に起因するものを含めて、多い順に確認と対処を説明します。

502 と 503・504 の違い

似たエラーと区別しておくと、原因を早く絞れます。

502 Bad Gateway：奥のサーバーにつながらない、またはつながったが応答が壊れていた・途中で切れた
503 Service Unavailable：サーバーが意図的に受け付けを止めている（メンテナンス中、負荷制限など）
504 Gateway Timeout：奥のサーバーにはつながったが、待ち時間内に応答が返らなかった

重い処理が時間内に終わらない場合は 504 になるのが基本ですが、PHP 側の設定で処理が強制終了されると 502 になることもあります。

手順1：502 を返したのはどこかを確認する

エラーページの見た目と応答ヘッダーで、返した相手を判断します。

Cloudflare などの CDN のロゴ入りページで、「Host」側がエラーになっている図が出る場合は、CDN からオリジン（自分のサーバー）への接続に失敗しています。オリジンを直接確認します
「502 Bad Gateway」と「nginx」だけが書かれた白いページなら、自分のサーバーの nginx が PHP-FPM との通信に失敗しています
レンタルサーバー独自のエラーページなら、サーバー会社側の障害情報やリソース制限の状況も確認します

# 応答ヘッダーで Server などを確認
curl -sI https://example.com/ | head -n 20

手順2：nginx のエラーログを読む

自分で管理しているサーバーなら、nginx のエラーログに原因がほぼ書かれています。

sudo tail -n 50 /var/log/nginx/error.log

よく出る文言と意味は次のとおりです（ソケットのパスやバージョン番号は環境によって異なります）。

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)：PHP-FPM が動いていないか、nginx の設定のソケットのパスが違います
connect() ... failed (13: Permission denied)：ソケットのアクセス権限が合っていません
connect() ... failed (111: Connection refused)：TCP で待ち受けている想定のポートで、PHP-FPM が待ち受けていません
connect() ... failed (11: Resource temporarily unavailable)：PHP-FPM が処理しきれず、待ち行列もあふれています
recv() failed (104: Connection reset by peer) / upstream prematurely closed connection：処理の途中で PHP のプロセスが終了しました。強制終了・メモリ不足・クラッシュが考えられます
upstream sent too big header：PHP からの応答ヘッダーが nginx のバッファーに収まりません

この文言によって、次の手順のどこを見るべきかが決まります。

手順3：原因の多い順に確認する

1. PHP-FPM が停止している・ソケットの指定が違う

systemctl status php8.3-fpm        # バージョンは環境に合わせる
ls -l /run/php/                    # 実際のソケットのファイル名を確認

PHP のバージョンを上げた直後に 502 が出た場合、新しいバージョンの PHP-FPM は起動しているのに、nginx の fastcgi_pass が古いバージョンのソケットを指したままになっていることがよくあります。PHP-FPM が起動しない場合は sudo php-fpm8.3 -t で設定ファイルを検査し、journalctl -u php8.3-fpm で起動失敗の理由を確認します。

権限エラーの場合は、PHP-FPM のプール設定（Debian 系なら /etc/php/8.3/fpm/pool.d/www.conf）の listen.owner・listen.group が nginx の実行ユーザーと合っているかを確認します。

2. PHP-FPM のプロセスが足りない

アクセスの集中やボットの大量アクセスで、PHP-FPM のプロセスがすべて使用中になると、新しいリクエストを受けられず 502 になります。PHP-FPM のログに次のような警告が出ていないかを確認します。

sudo grep -i "max_children" /var/log/php8.3-fpm.log
# 例: WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

pm.max_children を上げる前に、メモリが足りるかを計算します。PHP のプロセス一つあたりの使用量を確認し、「PHP に割り当てられるメモリ ÷ 一つあたりの使用量」を上限の目安にします。

# PHP-FPM の各プロセスのメモリ使用量（RSS, KB）
ps -o rss,cmd -C php-fpm8.3

メモリを超える値を設定すると、次の項目のメモリ不足を招きます。あわせて、wp-login.php や xmlrpc.php への大量アクセスが原因なら、レート制限や不要な機能の停止で負荷そのものを減らすほうが効果的です。

3. メモリ不足で PHP のプロセスが強制終了されている

サーバー全体のメモリが不足すると、Linux の OOM キラーが PHP のプロセスを終了させ、処理中のリクエストが 502 になります。

sudo dmesg -T | grep -iE "out of memory|killed process"
free -h

記録があれば、pm.max_children を下げる、MySQL などほかのプロセスとのメモリ配分を見直す、サーバーのメモリを増やす、といった対処になります。WordPress の WP_MEMORY_LIMIT を大きくしても、サーバー全体のメモリが増えるわけではない点に注意してください。

4. プラグインやテーマが PHP のプロセスを落としている

特定のページや操作だけで 502 になる場合は、プラグインやテーマの処理が原因の可能性があります。PHP-FPM のログに exited on signal 11 (SIGSEGV) のような記録があれば、PHP の拡張モジュールやプラグインの処理でクラッシュしています。

切り分けには WP-CLI が便利です。WP-CLI は PHP-FPM ではなくコマンドラインの PHP で動くため、サイトが 502 の状態でも操作できます。

wp plugin list --status=active          # 有効なプラグインを確認
wp plugin deactivate --all               # すべて停止（作業前にバックアップ）
wp plugin activate plugin-slug           # 一つずつ戻して再現を確認

WP-CLI が使えない場合は、FTP やファイルマネージャーで wp-content/plugins フォルダーの名前を一時的に変えると、すべてのプラグインが停止します。どのプラグインを有効にしていたかは、先に wp plugin list などで控えておくと復旧が楽です。

バックアップ・インポート・画像の一括処理など、時間のかかる処理の途中で 502 になる場合は、PHP-FPM の request_terminate_timeout による強制終了も疑います。ログに execution timed out と出ていれば該当します。上限を延ばすより、処理を WP-CLI や分割実行に移すほうが安定します。

5. 応答ヘッダーが大きすぎる

ログに upstream sent too big header が出ている場合は、nginx の FastCGI 用のバッファーを広げます。ログイン中のユーザーの Cookie が多い場合や、プラグインが大きなヘッダーを出す場合に起こります。

# server または location ブロック内（値は一例）
fastcgi_buffer_size 32k;
fastcgi_buffers 16 16k;

変更後は sudo nginx -t で文法を確認し、sudo systemctl reload nginx で反映します。

修正後の確認と再発防止

同じ URL・操作で 502 が出なくなったかを確認し、エラーログに新しい記録が出ていないかを数時間から数日見守る
PHP-FPM のステータスページ（pm.status_path）を内部からのみ見られる形で有効にし、使用中のプロセス数を把握する
外部の死活監視で、502 が出たときに通知を受け取れるようにする

設定値は、PHP のバージョンやサーバーの構成によって適切な値が異なります（2026年10月現在）。ここで示したコマンドや値は例として、自分の環境に合わせて読み替え、可能ならステージング環境で試し、設定ファイルのバックアップを取ってから本番に反映してください。

まとめ

502 は手前のサーバーが PHP-FPM などから正常な応答を受け取れなかった状態で、まず返した層を特定する
nginx のエラーログの文言（No such file、Permission denied、Connection reset、too big header など）で原因を絞り込む
多いのは PHP-FPM の停止・ソケット指定の誤り、プロセス不足、メモリ不足、プラグインによるクラッシュ
WP-CLI はサイトが 502 でも動くため、プラグインの切り分けに使える
設定変更はメモリの計算とバックアップを前提に、監視で再発を早く捉える