WordPressで「502 bad gateway」と表示された時の対処法

4xx = 「閲覧者からのアクセス内容に問題がある」

5xx = 「サーバー側のトラブルでページが出せない」

1. 別ブラウザで開く

ChromeやFirefox、Edgeなど、ブラウザによって差がないかチェック

2. 端末を変える

スマートフォンやタブレットなどモバイル回線のアクセスを試す。

3. ルーターやプロキシを経由しない回線で確認

社内ネットワーク固有の通信制限が疑われる場合に試す。

curl コマンド

curlコマンドを使用し、「curl -I https://example.com」と入力すると、httpステータスと応答ヘッダーが即時に表示されます。ここで502が表示されれば、サーバー側の障害であることが確定します。

DevTools

Googleであれば「F12キー」をクリックし、Networkタブを開き「F5キー」でページを再読込すると、各リソースのステータスと読み込み時間が一覧表示されます。HTMLが502で止まっているのか、画像やCSSだけが502になっているのかで対処法が変わります。

1. WebサーバーとPHPを再起動

systemctl restart nginx php-fpm またはApacheでプロセスを再起動し、プロセス数やメモリ使用量をリセットします。

2. error_logの直近数行を確認する

tail -n 50 /var/log/nginx/error.log と php-fpm.logに“connect() failed” や “upstream prematurely closed connection” が並んでいれば、PHP が落ちているかタイムアウト超過のサインです。

3. プラグイン・テーマの一括無効化

SFTP で wp-content/plugins を plugins_backup にリネームして WordPress を再読み込みします。表示が戻ればプラグイン競合が原因なので、フォルダを戻して個別に有効化していきます。

4. リソース不足の確認

top や htop で CPU・メモリが 100 % 近く張り付いていないか、df -h でディスク容量が枯渇していないかをチェックしましょう。

1. CDN/WAFの切り分け

Cloudflare などを使っている場合、そのサブドメインだけオレンジ雲（プロキシ）を外すか、開発モードにして直通にすると改善することがあります。CDN 側の 502 は「オリジンに到達できない」意 味なので、オリジンサーバーのファイアウォールや rate-limit 設定も確認します。

2. Nginxのlocation設定漏れ

location ~* \.(css|js|png|jpg|gif|webp)$ などで try_files を書き換えた直後に起こりがちです。パーミッションやパスが正しいか、fastcgi_pass を誤って静的ファイルにも適用していないかをチェックします。

3. ファイルパーミッションの不整合

アップロード直後に 502 が出る場合、uploads ディレクトリやファイルの権限が 600／700 になっていないか確認します。推奨はディレクトリ 755、ファイル 644です。

4. PHPで動的に生成されるアセット

Autoptimize・Elementor などが作る圧縮 CSS/JS は実体が PHP スクリプトの場合があり、その PHP がタイムアウトすると当該アセットだけ 502 になります。一時的に最適化プラグインをオフにして動作を確かめましょう。

1. プラグインを無効化

SFTPでwp-content/plugins を一時的に plugins_off へリネームし、すべてのプラグインを一括無効化します。

2. 影響しているプラグインを特定

ページが復旧したらフォルダ名を戻し、問題のプラグインを一つずつ有効化して再現テストを行います。

3. プラグインを特定したら

影響しているプラグインが特定できたらダウングレードするか、開発元にパッチの有無を問い合わせましょう。PHP8以降では旧式コードがエラーを起こしやすいため、アップデート前に動作確認を行うか、バックアップを行っておくと再発を防げます。

1. アップデート途中で処理が途切れ、必要なコアファイルが欠落

WordPress の自動アップデートは「ファイル展開 → データベース更新 → .maintenance 削除」という流れで進みますが、通信切断や残容量不足で処理が途中停止すると、テーマやプラグインを読み込む前提のコアファイルが抜け落ちます。結果、PHP-FPM がエラーを吐き、Nginx などのゲートウェイが 502 を返します。

対処法は、まず FTP／SSH で .maintenance を削除してページを再読み込みし、復旧しなければ WP-CLI の wp core download –force –skip-content か、公式 ZIP を展開して wp-content を残したままコアを上書きします。操作前に必ずバックアップを確保し、上書き後に wp-admin/upgrade.php を開いてデータベースを再更新してください。

2. 新バージョンが要求するPHPバージョンや拡張モジュールが不足

WordPress 6.5 以降は PHP 8.1 以上が推奨され、古い PHP では未定義関数エラーが発生します。また intl や zip などの拡張モジュールが有効でないと、コアが読み込まれる前に PHP がクラッシュし 502 につながります。

対処法は、ホスティングのコントロールパネルや php -v で現在のバージョンを確認し、要件に満たない場合は PHP を引き上げます。バージョンを上げた後でも 502 が解消しない場合は php-fpm.log を参照し、足りないモジュールを yum／apt で追加インストールしてください。環境変更が難しい共有サーバーでは、ひとつ前の WordPress バージョンへロールバックし、ステージング環境で動作確認してから再アップグレードすると安全です。

DNS でCloudflareのプロキシ（オレンジ雲）が有効になっているレコードを一時的にグレー雲へ切り替え、CDN をバイパスして様子を見るのが最速です。

オリジン側のファイアウォールが Cloudflare の IP レンジを遮断していないか、オリジン証明書の期限が切れていないか、SSL/TLS モードが「フル（ストリクト）」になっているかも合わせて確認します。

Cloudflare 側でネットワーク障害が起きている場合はステータスページに掲載されるため、復旧見込みをチェックしてプロキシを再度有効化してください。

php-fpm の設定ファイル（www.conf など）で pm.max_children を現在の同時接続数より余裕を持たせて増やし、必要メモリを見積もったうえでサービスを再起動してください。あわせて Nginx の proxy_read_timeout と fastcgi_read_timeout をおよそ 60 秒に延長し、バックエンド処理が完了する前にタイムアウトしないよう調整すると安定します。

さらに根本的な解決策としては、Redis や Varnish などのフロントキャッシュを導入して PHP の実行回数を減らすか、オートスケール対応のホスティングへ移行してピークトラフィックに応じてインスタンスを自動拡張できる構成にするのが効果的です。

1. アップデート途中で処理が途切れ、必要なコアファイルが欠落

WordPress の自動アップデートは「ファイル展開 → データベース更新 → .maintenance 削除」という流れで進みますが、通信切断や残容量不足で処理が途中停止すると、テーマやプラグインを読み込む前提のコアファイルが抜け落ちます。結果として PHP-FPM が致命的エラーを吐き、Nginx などのゲートウェイが 502 を返します。

対処法は、まず FTP／SSH で .maintenance を削除してページを再読み込みし、復旧しなければ WP-CLI の wp core download –force –skip-content か、公式 ZIP を展開して wp-content を残したままコアを上書きします。操作前に必ずバックアップを確保し、上書き後に wp-admin/upgrade.php を開いてデータベースを再更新してください。

2. 新バージョンが要求するPHPバージョンや拡張モジュールが不足

WordPress 6.5 以降は PHP 8.1 以上が推奨され、古い PHP では未定義関数エラーが発生します。また intl や zip などの拡張モジュールが有効でないと、コアが読み込まれる前に PHP がクラッシュし 502 につながります。

対処法として、ホスティングのコントロールパネルや php -v で現在のバージョンを確認し、要件に満たない場合は PHP を引き上げます。バージョンを上げた後でも 502 が解消しない場合は php-fpm.log を参照し、足りないモジュールを yum／apt で追加インストールしてください。環境変更が難しい共有サーバーでは、ひとつ前の WordPress バージョンへロールバックし、ステージング環境で動作確認してから再アップグレードすると安全です。

1. Apacheを再起動

SSH／FTP でサイトルートの .htaccess を htaccess_bak などにリネームして Apache を再起動します。

2. 一行ずつ動作確認

502 が消えれば記述ミスが確定なので、公式の WordPress コア部分だけをコピーし、カスタムルールは一行ずつ戻して動作確認します。

3. 解決しない場合

502 が続く場合は原因が別層にあるため .htaccess を元に戻し、ログ調査へ進みます。

1. 情報収集

サービス提供会社のステータスページや X（旧 Twitter）の公式サポートアカウントで障害が起きていないかを確認しましょう。

2. 同サーバーのサイトを確認

同じサーバーに置いた別ドメインや管理画面にアクセスしてみて、そちらも 502 ならサーバー全体の障害と判断できます。

3. 障害告知がない場合

障害告知が出ていない場合はサポートへチケットを開き、502 Bad Gateway と表示された時刻と URL を伝えて復旧を依頼。運営が対応するまで待機し、完了後にキャッシュクリアと動作確認を行いましょう。

SSH で systemctl status mariadb（または mysqld）を確認し、サービスが停止していれば systemctl start mariadb で再起動します。クラウド型のマネージド DB を使っている場合は、コンソールのステータスページで稼働状況を確認し、保守通知や負荷アラートが出ていないかも合わせて確認してください。

FTP／SFTP で wp-config.php を開き、編集前のバックアップと比較して構文ミス（; や ‘ の欠落、不要な空白）がないかを確認し、修正後にファイルを上書きするだけで復旧します。編集前のバックアップがない場合は、公式サンプルをベースに DB 接続情報を移植して再生成すると確実です。

Nginx の設定ファイルを開き、fastcgi_pass または proxy_pass が PHP-FPM 側の listen アドレス（ソケット名や IP:ポート）と一致しているか確認してください。値がズレていれば修正し、設定を保存後に Nginx を再読み込みすれば「502 Bad Gateway」は解消します。