WordPressで502 Bad Gatewayが出る原因と対処法|サーバー・PHP・プラグインを確認

WordPressで502 Bad Gatewayが出る原因と対処法を解説するアイキャッチ WordPress

この記事は、WordPressで502 Bad Gatewayが出たときに、どの層で応答が途切れたかを切り分ける記事です。WordPress本体だけでなく、Webサーバー、PHP、CDN・プロキシなど複数の層で発生するため、最初に発生範囲と時刻を記録します。500・503・504など別のエラーならWordPressトラブル解決ロードマップから症状別に確認してください。

変更前に復旧手段を確認: 設定を触る前にWordPressバックアップと復元を確認し、直前に更新した場合は更新前チェックも参照してください。別の症状はトラブル解決一覧から選べます。

YOHAKU 5-STEP CHECK

確認する順番

  1. 別ブラウザ・別回線でも再現するか確認
  2. ホスティングの障害情報を確認
  3. 直前のPHP・プラグイン変更を確認
  4. CDN・キャッシュの有無を確認
  5. 再発時はログと時刻を照合

502 Bad Gatewayとは?最初に確認する4つ

502は、ゲートウェイやプロキシとして動くサーバーが、上流のサーバーから正常な応答を受け取れなかったことを示します。WordPressのプラグインが原因と、この番号だけで断定することはできません。

  1. 発生範囲を記録:公開トップ・問題のURL・管理画面のどこで出るかを分けます。別ブラウザや別回線でも確認し、短時間に何度も再読み込みしません。
  2. 契約先の障害情報を確認:該当するサーバー・時刻・復旧案内を確認します。告知がないだけで障害なしとは判断せず、継続・再発や業務への影響があれば問い合わせます。
  3. 直前の変更を照合:PHP・プラグイン・テーマ・バックアップ等の実施時刻を並べます。更新直後でも原因確定とはせず、ログと同じ操作の結果を確認します。
  4. CDN・プロキシの利用を確認:利用していれば、表示された識別番号・時刻と、契約先側のログを担当者に照合してもらいます。DNSやWAF全体を推測で変更しません。

502・503・504の違い / サポートへ渡すメモ

502・503・504を分ける

  • 502 Bad Gateway:上流からの応答が不正だった場合。この記事で発生範囲・時刻・直前変更を記録します。
  • 503 Service Unavailable:サービスが一時的に利用できない場合。
  • 504 Gateway Timeout:上流からの応答を時間内に得られない場合。
  • 500 Internal Server Error:サーバー内部で処理できない問題が起きた場合。

数字が変わった場合は、その時刻と操作も記録します。コードだけで障害箇所やデータ消失の有無は分かりません。

502の判断早見表

状況 最初に見る場所 次の行動
サイト全体で502 ホスティング障害情報・負荷 設定変更をせず復旧状況を確認
特定操作だけ502 直前の更新・PHP処理 同じ操作で再現するか記録
断続的に発生 発生時刻・アクセス・ログ 時刻を添えてサポートへ相談

自分で触る範囲と相談する範囲

ブラウザ変更、障害情報の確認、直前の更新履歴の確認までは初心者でも安全に進めやすい範囲です。PHP設定、Webサーバー設定、CDN設定を変更する段階では、元の値を記録し、復元方法が分からなければ先にホスティング会社へ相談します。

502が続くときにサポートへ渡すメモ

分かる範囲だけ記入し、必要な部分を選択してコピーできます。入力しても送信・自動保存されません。パスワード・認証コード・顧客情報は記入しません。画面の画像やログを共有する場合も、秘密情報を含まないか確認します。

相談先は契約サーバー会社や保守担当です。このページは入力内容を受け取る窓口ではありません。不明な値を推測して埋める必要はありません。

似た症状が出る場合は、503 Service Unavailable、504 Gateway Timeout、PHPメモリ不足もあわせて確認してください。アクセス制限や短時間の連続リクエストが疑われる場合は、429 Too Many Requestsと症状を見比べると切り分けやすくなります。

502で避けたい確認の仕方

  • 原因確認前にプラグインを大量停止する
  • PHP設定を推測で変更する
  • 502だけでデータ消失と判断する

502が出なくなった後に再確認する場所

  1. 失敗した操作:同じページと操作で再確認し、確認した時刻と結果を記録します。送信・注文などの操作は、処理済みか確認してから行い、重複させません。
  2. 公開画面と管理画面:片方が開けることだけで復旧とせず、業務で必要な側も確認します。未確認の機能は残します。
  3. 変更と再発:設定を変更した場合は内容を1つずつ記録し、再発した時刻と照合します。一時的に開けた結果だけで、原因が解消したとは断定しません。

確認結果はサポートへ渡すメモへ残します。業務への影響が続く、再発する、確認できない範囲がある場合は、契約先や保守担当へ相談してください。

CDNを使っている場合の切り分け

CDNやリバースプロキシを使っている場合は、CDN側とオリジンサーバー側で状況が異なることがあります。Cloudflareの公式案内も参照し、発生時刻・タイムゾーン・対象URLを契約先や担当者へ伝えます。オリジン側の確認は担当者へ依頼し、調査のためにアクセス制限を外したり、非公開の接続情報を公開したりしません。

ただし、原因確認前にCDNを無効化したりDNSを書き換えたりすると別の障害を増やすことがあります。元の設定と復旧方法が分からない場合は、先にホスティング会社や担当者へ確認します。

よくある質問

502が出たらWordPressを再インストールすべきですか?

最初に行う対応ではありません。発生範囲・障害情報・直前変更・ログを確認し、データを消す操作は避けます。

502が出たとき、キャッシュ削除は最初にしてよいですか?

キャッシュが原因候補の場合は有効ですが、サイト全体で502が出ているならサーバー・PHP・上流通信も確認します。キャッシュ削除だけを何度も繰り返さず、発生範囲を先に記録します。

管理画面だけ502なら何を見ますか?

管理画面で動く更新処理、バックアップ、インポート、管理系プラグインなどとの関係を確認します。公開画面が正常なら、サイト全体の障害とは分けて考えます。

一度直ったあともサーバー会社へ相談した方がいいですか?

繰り返す場合や業務影響が大きい場合は、復旧後でも発生時刻とURLを添えて相談する価値があります。短時間の一度だけなら記録を残し、再発時に照合できるようにします。

参考情報