WordPressサイトを開いたとき、突然「502 Bad Gateway」と表示されることがあります。公開ページも管理画面も見えないと、記事やデータベースが消えたのではないかと不安になりますが、502だけでデータ消失や不正アクセスとは判断できません。
502は、ブラウザとWordPressの間にあるCDN、リバースプロキシ、Webサーバーなどの中継役が、接続先の上流サーバーから正常な応答を受け取れなかった状態です。原因は一時的な障害、サーバー負荷、PHPの停止、接続設定、直前の更新など複数あります。
復旧を急いで、CDN停止、全プラグイン停止、PHP変更、サービス再起動、バックアップ復元を同時に行わないでください。変更を重ねると、何が原因で何が効いたのか分からなくなり、別の障害を増やすおそれがあります。
この記事では、変更前に証拠を残し、502が出る範囲と発生箇所を分けて、安全に復旧する順番を解説します。共有レンタルサーバーを使う初心者でも、サポートへ必要な情報を渡せるところまで進められます。
先に結論：502エラーは7段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | URL・時刻・操作・画面を保存する | 同時刻のログと照合できるようにする |
| 2 | サイト全体か特定画面だけかを分ける | 障害の範囲を絞る |
| 3 | サーバー会社・CDNの障害情報を見る | 自分の設定変更が不要な障害を先に除外する |
| 4 | エラーを返した層と上流を確認する | CDN・Webサーバー・PHPのどこを見るか決める |
| 5 | 直前の変更を一つだけ戻す | 原因と効果を追える状態で復旧する |
| 6 | 根拠がある場合だけWordPress側を切り分ける | 無関係なプラグイン停止を避ける |
| 7 | 重要機能とログを再確認する | 一時復旧や部分障害を見逃さない |
まず「直す操作」より「発生時の記録」を優先します。502が自然に消えても、PHPの再起動や同時処理数の上限が原因なら再発するためです。
502 Bad Gatewayとは？
HTTPの仕様を定めるRFC 9110では、502を「ゲートウェイまたはプロキシとして動作するサーバーが、要求を処理するために接続した上流サーバーから無効な応答を受け取った状態」と定義しています。
WordPressサイトの通信は、環境によって「訪問者のブラウザ→CDNやWAF→Webサーバー→PHP→WordPress」のように複数の層を通ります。途中の中継役が、次の層へ接続できない、応答の途中で切断される、正常なヘッダーを受け取れない場合などに502が返ることがあります。
「Bad Gateway」という表示でも、ドメイン設定だけが悪いとは限りません。また、WordPressが実行される前に失敗すれば、WordPressのデバッグログへ何も残らないことがあります。ログが空だからWordPress側もサーバー側も正常、と決めつけないことが大切です。
500・502・503・504の違いを先に分ける
| 表示 | 仕様上の意味 | 最初に見る場所 |
|---|---|---|
| 500 Internal Server Error | サーバーが予期しない状態に遭遇し、要求を完了できない | PHP・WordPress・Webサーバーのログと直前の変更 |
| 502 Bad Gateway | 中継役が上流から正常な応答を受け取れない | CDN・プロキシ・Webサーバー・PHP間のログ |
| 503 Service Unavailable | 過負荷やメンテナンスで現在は処理できない | 障害情報、メンテナンス、CPU・メモリ・同時実行数 |
| 504 Gateway Timeout | 中継役が上流から時間内に応答を得られない | 長時間処理、上流接続、タイムアウト、負荷 |
画面が500なら、原因の見方が異なります。WordPressの500 Internal Server Errorを安全に直す手順を確認してください。503の場合は、過負荷とメンテナンスを分けるWordPress 503 Service Unavailableの直し方へ進みます。
「重大なエラーが発生しました」と表示されるなら、502の画面とは別です。WordPress重大なエラーの安全な復旧手順で、復旧モードとPHPエラーを確認します。
最初の10分で行う安全な初動
502が出たら、エラー画面のスクリーンショット、完全なURL、発生時刻とタイムゾーン、直前に行った操作を保存します。閲覧中だったのか、記事保存、画像アップロード、更新、フォーム送信中だったのかも記録してください。
トップページ、別の記事、管理画面、既知の静的画像をそれぞれ一度だけ確認します。別端末または別回線での比較も一度にとどめます。静的画像だけ開き、WordPressの動的ページが502になる場合は、PHPなど動的処理の経路が候補になりますが、症状だけで確定はできません。
保存、注文、問い合わせ、会員登録などの送信操作で502が出た場合は、ボタンを連打しないでください。画面はエラーでも、サーバー側で処理が完了している場合があります。復旧後に重複投稿、二重注文、通知の重複がないかを確認します。
502が出る範囲から確認先を絞る
サイト全体と管理画面の両方が502になる
ホスティングやCDNの障害、Webサーバーと上流サービスの接続失敗、PHPサービスの停止・再起動、同時処理数の上限、移行後の接続設定などを優先します。WordPressの設定を触る前に、サーバー会社とCDNの公式障害情報、管理画面のリソース使用状況、Webサーバーのエラーログを確認します。
公開ページは見えるが管理画面や特定操作だけ502になる
バックアップ、検索、集計、インポート、画像処理など負荷の高い管理処理や、管理画面でだけ動くプラグインが候補です。失敗したURLと操作時刻を記録し、同じ時刻のPHP・Webサーバーログを照合します。ログイン周辺の症状もある場合は、WordPress管理画面へ入れないときの確認手順も役立ちます。
CDN経由のときだけ502になる
CDNと配信元サーバーの間を確認します。配信元が対象ホスト名へ応答できるか、接続先IPやポートを変更していないか、CDNの通信がファイアウォールやレート制限で拒否されていないかが確認対象です。
Cloudflareの公式資料は、502/504について配信元サーバー由来とCloudflare由来を分けて調査するよう案内しています。エラーページの見た目はカスタマイズできるため、ブランド表示だけで発生箇所を確定せず、ヘッダー、識別ID、配信元のログを合わせて確認してください。
原因別の安全な復旧順
1．サーバー・CDNの障害と一時的な負荷
公式障害情報と管理画面のCPU、メモリ、同時実行数、ディスク使用量を確認します。発生時刻にバックアップ、画像変換、インポート、cron、アクセス急増が重なっていないかも見ます。公式障害であれば、WordPress設定を変えず、案内された復旧見込みを待つのが安全です。
負荷が繰り返す場合は、原因の重い処理を特定してから対策します。キャッシュや画像最適化、プラグイン整理、サーバープランは順番に検討します。最初から上位プランへ変えるのではなく、WordPressが重い原因を切り分ける改善順を使って、再現条件とボトルネックを確認してください。
2．WebサーバーとPHPの接続
WebサーバーがPHPへ処理を渡す環境では、PHPサービスの停止、再起動の繰り返し、接続先ポートやソケットの不一致、権限、同時処理数の上限、上流からの接続切断が候補です。NginxのFastCGI公式資料でも、上流への接続先をTCPアドレスまたはUnixソケットで指定する構成が説明されています。
共有・管理型レンタルサーバーでは、PHPサービスの再起動や設定ファイル変更を自分で行えないことがあります。検索で見つけた設定値を貼り付けず、エラー時刻とURLを添えてサーバー会社へ調査を依頼してください。
3．直前のPHP・CDN・移行設定変更
PHPバージョン、CDN、DNS、SSL、ファイアウォール、移行先、Webサーバー設定を変えた直後なら、変更前の値を記録したうえで対象だけを戻します。複数項目を一度に戻すと原因を特定できません。PHP変更後なら、WordPressのPHPバージョンを安全に確認・更新する方法の切り戻し確認を使います。
4．プラグイン・テーマ・独自コード
更新・有効化・コード編集の直後で、特定ページや操作だけ再現し、PHPログや復旧モード通知に対象ファイルが示される場合は、WordPress側の候補が強まります。まずログが示す対象だけを停止し、確認済みの正常版へ戻します。
全プラグイン停止は、フォーム、キャッシュ、セキュリティ、計測も同時に止めます。管理画面へ入れるならテスト環境やトラブルシューティング機能で影響を限定し、入れない場合も対象が分かるならそのプラグインだけを扱います。安全な検証環境はWordPressテスト環境の作り方で確認できます。
5．不正な応答ヘッダー・圧縮・接続制限
上流から不正なヘッダーが返る、応答ヘッダーが大きすぎる、圧縮内容とContent-Lengthが合わない、ファイアウォールがCDNを拒否する場合もあります。ただし、ログに根拠がないままバッファー、タイムアウト、メモリを増やすのは危険です。対象のエラー記録を確認し、サーバー会社または構成管理者と調整します。
6．バックアップ復元は最後に判断する
CDN障害、PHPサービス停止、サーバー負荷、接続先不一致は、WordPressのバックアップを復元しても直りません。復元は、ファイルやデータベースの変更が原因と確認でき、戻す時点と影響範囲が分かる場合に限ります。
復元すると、バックアップ取得後の投稿、注文、問い合わせ、ユーザー情報を巻き戻す可能性があります。ファイルとデータベースを同じ時点のセットとして扱い、現状も保存します。準備はWordPressバックアップの取り方を確認してください。
公開画面へ詳細を出さずログを確認する
優先するのは、ホスティング管理画面のWebサーバーログ、PHPログ、リソース履歴、CDN・WAFログです。502がWordPress実行前に発生すれば、WordPressログだけでは追えません。
WordPress側の調査が必要な場合は、WordPress公式のデバッグ手順に従います。公式資料は変更前にステージング環境または適切なバックアップを確保し、本番サイトでデバッグ表示を常用しないよう注意しています。記録はログへ出し、公開画面にはエラー詳細を表示しません。
サポートや公開フォーラムへログを渡す前に、Cookie、認証ヘッダー、nonce、ユーザー名、IPアドレス、サーバーパス、データベース情報、秘密鍵、配信元IPを伏せてください。
やってはいけない対処
- 保存、注文、問い合わせ、更新操作を連打する
- CDN、WAF、全プラグインを同時に停止する
- PHPバージョン、メモリ、タイムアウト、バッファーを一度に変える
- ログを取る前にサービス再起動やキャッシュ全削除を繰り返す
- 検索で見つけたNginx・Apache・PHP設定をそのまま貼る
- ファイル権限を一律777にする
- 502だけを理由にデータベース修復やWordPress再インストールを行う
- 本番画面へエラー詳細を表示する
一つ変更したら、一つ検証し、結果と時刻を記録することが安全な復旧の基本です。
サーバー会社へ伝える情報
- 502の画面全文と対象URL
- 発生日時とタイムゾーン
- 常時か断続的か
- サイト全体・管理画面・特定操作のどこで出るか
- 直前の更新、移行、PHP、CDN変更
- CDN利用の有無と確認できた識別ID
- 伏せ字済みのログ抜粋
- 最後に正常だった時刻
- すでに行った確認と結果
「該当時刻のCDNまたはリバースプロキシ、Webサーバー、PHPのログを照合し、上流接続失敗、サービス再起動、同時処理上限がなかったか確認してください」と依頼すると、調査対象が伝わりやすくなります。
復旧後に確認する10項目
- トップページと502が出たURLが開く
- 複数の記事・固定ページが開く
- 管理画面へログインできる
- 下書きを一度保存できる
- 画像・CSS・JavaScriptが読み込まれる
- 問い合わせや購入など重要機能を一度確認する
- CDN経由でも正常に表示される
- 同じエラーがログへ増えていない
- 一時的に変更した設定が元へ戻っている
- 原因、修正内容、再発時の連絡先を記録した
一時的に直っただけかもしれないため、数時間後と翌日にも監視やログを確認します。障害が繰り返し、サーバー側の上限や保守体制が原因と確認できた場合は、レンタルサーバーを見直すべきタイミングを使って、移行の必要性を判断してください。
よくある質問
再読み込みやブラウザキャッシュ削除で直りますか？
一時障害との比較や、古いエラー画面が残っていないかの確認には使えますが、上流サーバー間の問題そのものは直しません。閲覧ページを一度比較したら時刻を記録し、サーバー側を確認します。送信操作は連打しないでください。
502はプラグインが原因ですか？
可能性はありますが、502だけでは断定できません。サイト全体で出るならサーバー、PHP、CDNを先に確認します。直前の更新とログが特定プラグインを示す場合だけ、対象限定で切り分けます。
WordPressのデバッグログが空なら正常ですか？
断定できません。WordPressが動き始める前に、WebサーバーとPHPの間で失敗すれば、WordPress側へ記録されない可能性があります。ホスティング側のWeb・PHPログも確認します。
PHPメモリを増やせば直りますか？
メモリ不足がログで確認できた場合の選択肢ですが、万能策ではありません。消費元を調べず上限だけ増やすと、再発やサーバー全体の逼迫につながることがあります。
Cloudflareの画面ならCloudflare障害ですか？
画面だけでは確定できません。Cloudflareの公式資料でも、配信元サーバーが502を返した場合とCloudflare側で発生した場合を分けています。画面、ヘッダー、識別ID、配信元ログを合わせて判断します。
502が自然に消えたら調査は不要ですか？
不要とは限りません。負荷上限、PHPの再起動、短い通信中断は再発するため、発生時刻のログとリソース状況を確認します。原因を記録しておけば、次回の復旧も早くなります。
まとめ
502 Bad Gatewayは、WordPressの故障名ではなく、中継役が上流から正常な応答を受け取れなかった結果です。まずURL、時刻、操作、発生範囲を残し、障害情報、CDN・Webサーバー・PHPのログ、直前の変更を順番に確認します。
複数の対処を同時に行わず、根拠がある対象を一つずつ直すことが、二次障害を防ぐ最短ルートです。復旧後は公開画面だけでなく、管理画面、保存、重要機能、ログまで確認してください。