502 Bad Gatewayは、手前のWebサーバーやCDNが、奥にあるPHPなどから正常な応答を受け取れなかったときのエラーです。訪問者なら再読み込みを連打せず数分待ち、管理者なら障害情報、発生範囲、PHPログ、直前の更新を確認します。503や504と似ていますが、502では「中継先から不正・切断された応答を受けた」点に注目します。
最初に答え：数分待って障害を除外し、PHPと直前変更を調べる
訪問者側でできるのは、時間を置く、別回線で確認する、運営者へ発生時刻とURLを伝えることです。管理者はサーバー障害情報とリソース状況を確認し、全ページならPHP・サーバー、特定操作だけならプラグインや外部APIを優先します。
- エラーが出た時刻とURLを記録し、更新を連打しない
- 別回線でトップ・記事・管理画面の発生範囲を確認する
- 契約サーバーとCDNの障害情報を確認する
- PHPエラーログとリソース使用量を同じ時刻で見る
- 直前に更新したプラグインがあれば一件だけ停止する
502・503・504の違いを復旧に使う
502は中継サーバーが奥の処理から正常な応答を受け取れない状態、503はサービスが一時的に要求を受けられない状態、504は奥の処理を待ったものの時間内に応答しなかった状態です。表示だけで断定はできませんが、ログを見る優先順位を決める手掛かりになります。
| 見え方 | 原因候補 | 最初の確認 |
|---|---|---|
| 数分で自然復旧 | 一時的なPHP再起動・障害 | 障害情報と再発時刻を記録 |
| 全ページで継続 | PHP-FPM・サーバー負荷 | リソースとPHPログ |
| CDN経由だけ発生 | CDNとオリジン接続 | CDN障害・SSL・DNS |
| 特定操作の直後 | プラグイン・外部API | 直前対象とログ |
訪問者としてできること・しないこと
同じURLを何度も更新すると、復旧途中のサーバーへ負荷を加える場合があります。5分ほど時間を置き、スマートフォン回線など別経路から一度確認します。自分の端末だけならブラウザーやネットワーク、全員なら運営側の可能性が高まります。
運営者へ連絡できる場合は、URL、表示文、発生時刻、端末や回線を伝えます。パスワードや管理画面URLは送らないでください。
スマホでも同じ502になっていました…。
私のパソコンだけじゃないなら、少しだけ原因に近づいたって思っていいのかな…？
うん、それならパソコンだけの問題ではなさそうだね。
何度も読み込まず、管理画面と公開ページを一度ずつ見れば十分だよ。
管理画面も開かないみたいです。
サーバーの情報を見るの、ちょっと難しそうなので一緒に順番を一緒に見てもらえるとうれしいです。
管理画面も同じなら、次はサーバー側を見ようか。
難しいところは全部分からなくていいよ、同じ時刻の記録を探せばいいからね。
管理者の手順1：障害・CDN・発生範囲を確認する
契約サーバーの障害・メンテナンス情報でサーバー番号を確認します。CDNを使っている場合は、CDN経由のURLとオリジンサーバーの状態を分け、証明書やDNS変更の直後ではないかも確認します。
トップ、静的画像、PHPで生成する記事、
/wp-admin/
のどこまで502かを確認します。画像は開くのにPHPページだけ失敗するなら、PHP側を優先します。
管理者の手順2：PHPログと負荷を確認する
サーバーパネルでCPU・メモリ・同時実行数を確認し、502の時刻に急増していないか見ます。PHPログでは「child exited」「connection reset」「memory exhausted」など、応答が切れた理由を探します。
容量不足で一時ファイルやログを書けない場合も処理が止まります。不要ファイルを闇雲に削除せず、使用量の大きい場所を特定します。
管理者の手順3：直前変更を一件だけ戻す
プラグイン更新直後なら、ファイルマネージャで該当フォルダ名だけを一時変更して停止します。全プラグインを一度に止めると、フォームや決済まで停止し、原因も分からなくなります。
停止で復旧したら、互換性、必要PHP、更新版を確認します。フォルダ名を戻して再有効化する前に、正常版または代替手段を用意してください。
ログに同じプラグインの名前が何度もありました。
これを止めればよさそうに見えるけど、記事まで消えたりしませんか？
記事が消える操作じゃないから大丈夫だよ。
名前とバージョンをメモして、その一つだけ止めて比べてみようか。
バージョンを控えておけば戻しやすいんですね。
こういうメモ、つい忘れちゃうので先に書いておきます。
うん、先に書いておくと戻す時も安心だね。
急いで有効に戻さず、更新内容を読んでからでいいよ。
502が再発するときの観察方法
自然復旧した後も、何時に、どのURLで、何秒ほど続いたかを記録します。バックアップ作成、画像一括処理、アクセス急増、cron実行など、同時刻に始まった処理があれば候補として並べます。毎回ほぼ同じ時刻なら定期処理、特定操作の直後ならアプリ処理を優先できます。
サポートへ渡すと解決が早い情報
契約サーバー番号、対象ドメイン、502の全文、発生時刻、対象URL、全ページか一部か、直前の更新、PHPログの該当行をまとめます。画面写真だけでなく文字でも残し、パスワードやCookieは含めません。「再起動してください」ではなく、上流接続が切れた原因と同時刻のリソース状況を確認したいと伝えます。
具体例：画像は開くのに記事だけ502になる場合
/wp-content/uploads/...
の画像URLは200で、記事URLと管理画面だけ502なら、Webサーバーまでは動き、PHPへの中継で失敗している可能性が高い状態です。PHPバージョン変更、プラグイン更新、メモリ不足、PHPプロセス上限を同時刻のログで確認します。
逆に画像も記事もCDN経由で502、オリジンへ直接確認すると正常なら、CDNからオリジンまでのDNS・TLS・接続制限を確認します。この比較によって、WordPressファイルを触る前に問題の層を決められます。
復旧後に再開する処理の順番
まず未ログインでトップと一記事、次に管理画面、最後に検索・フォーム・更新処理を一つずつ試します。一括更新や大量画像処理は、通常アクセスが安定してPHPログに新しい異常がないことを確認してから再開します。
無効化したらページが開きました…ほっとしました。
うれしくてすぐ有効に戻しそうになったけど、まだ待った方がいいですよね？
開けたなら、まずはよかったね。
でも今日は原因の名前と時刻を残しておこうか。次に同じことが起きても、ミカさんが困らないようにね。
更新情報を読んでから戻せばいいんですね。
まだ一人だと少し心細いけど、むやみに全部触らなくていいのは分かってきました。
成功したと判断するチェック
トップ、記事、管理画面、検索やフォームが連続して正常表示され、PHPログへ新しい切断エラーが増えず、負荷が平常範囲へ戻っている状態です。一時停止した機能がある場合は、正常版または代替まで用意します。
- 外部障害を確認した
- 静的ファイルとPHPページを比較した
- PHPログと負荷を同時刻で見た
- 直前変更を一件だけ検証した
- 動的機能まで復旧確認した
502が繰り返す場合に見るべき運用環境の条件
一時的な502だけで契約を変える必要はありません。アクセス増加や管理画面の重さが繰り返し、現在のサーバーで負荷状況を把握しにくい場合だけ、速度と管理のしやすさを比較します。
広告・PRを含みます。料金・特典は公式ページで最新条件をご確認ください。
よくある質問
502はアクセスした自分のせいですか？
通常はサーバーや中継側の問題です。更新連打は避け、発生時刻を運営者へ伝えてください。
再起動すれば必ず直りますか？
一時復旧しても重い処理や互換性問題が残れば再発します。ログで原因を確認します。
CDNを外せばよいですか？
CDN経由だけで起きる根拠がある場合に切り分けます。全解除前にSSL・DNS・オリジン状態を確認してください。
まとめ：502は中継先の応答を、発生範囲とログで追う
数分待って外部障害を除外し、静的画像とPHPページを比較します。全体障害ならPHP・負荷、CDN経由だけなら接続設定、更新直後なら対象一件を確認し、動的機能まで正常になれば完了です。
一度だけの502で復旧後の負荷・ログに問題がない人は、今回の操作が完了した時点で新しい契約を検討する必要はありません。新規サイトや運用環境全体を見直す場合だけ、条件を比較してください。
ConoHa WINGの公式情報を確認する