502 Bad Gatewayとは？閲覧者・運営者別の原因と対処法

502 Bad Gatewayは、ゲートウェイやプロキシとして動くサーバーが、上流のサーバーから無効な応答を受け取ったことを示します。時間内に上流応答を受け取れない504とは定義が異なります。閲覧者は少し待って確認し、運営者は発生範囲と拒否・失敗した層をログで特定するのが基本です。

502・500・503・504の違い

定義はRFC 9110のHTTPステータスに基づきます。製品ごとの実装やエラー変換があるため、画面のコードだけで最終原因を断定しません。アクセス拒否は403 Forbiddenの対処と分けて確認します。

閲覧者ができること

1. 通常の閲覧中なら少し待って再読み込みし、公式の障害・メンテナンス案内を確認します。
2. 一部ページだけか、サイト全体かを確認します。別ブラウザや回線での確認は、ローカルな表示・通信条件を切り分ける補助になります。
3. 解消しなければ、URL、時刻とタイムゾーン、表示文、request IDなどを管理者へ伝えます。

購入、決済、申込フォームの送信後にエラーが出た場合は、むやみに再送しません。結果が表示されなくても処理だけは受け付けられた可能性があるため、履歴や確認メール、窓口で結果を確かめます。

通常の502はサーバー間の問題を調べる必要があり、閲覧者のDNS設定変更を標準手順にはしません。キャッシュ削除なども、特定の端末だけ古い状態が残ると確認できた場合の補助的な対応です。

運営者は証拠を残してから変更する

最初に影響を受けたURL、発生時間、利用地域、再現率、request ID、直近のデプロイ・設定変更を記録します。「全体を再起動して直るか試す」前に、CDN→ロードバランサー→リバースプロキシ→アプリ→依存サービスのどの区間で失敗したかを調べます。

CDN経由とオリジンの応答を比べる場合は、正当な管理権限と運用手順の範囲で行います。Cloudflare環境でも、オリジン側・Cloudflare側のどちらで起きたかを調べる必要があります。Cloudflareの502・504調査ガイドが、発生時刻やホスト名、関連ログを集める際の基準になります。

ログと観測内容から原因を絞る

タイムアウトの延長やサーバー増強は、観測原因に対応する場合に選びます。遅いクエリや不正な応答が原因なら、待ち時間や台数だけを増やしても解決しないことがあります。製品によってタイムアウトがどのコードで表れるかも異なるので、502をすべて「待ち時間不足」としないでください。

CMS・WordPressなどでの確認

直近のプラグイン・テーマ・実行環境・設定変更を記録し、エラーログと対応付けます。停止や切り戻しはバックアップと復元手順を確認してから、影響を限定して行います。CMS本体、ホスティング、CDN、独自開発のどこまで誰が保守するかは、CMSの責任分界で整理できます。

キャッシュを検討する場合も、公開・非個人化の応答と、ログイン・決済・個人情報の応答を分けます。動的ページすべてを共有キャッシュへ入れるような一括対処は避け、対象・除外・更新条件を設計してください。転送先やループが関係するならリダイレクトの確認も行います。

復旧と再発防止を確認する

架空の問い合わせサイトで「ページは開くが送信APIだけ502」の場合、トップページの復旧だけで完了にはしません。フォーム成功・失敗・再読み込みを確認し、重複した問い合わせや決済がないかも調べます。ホスティング会社への連絡には、URL・発生時刻・ID・範囲・直近変更・試した操作を添えると、調査のやり取りを減らせます。

検索への影響に時間の保証はない

Googleは5xxが発生すると一時的にクロールを抑え、長く続けば既存URLの登録にも影響する場合があります。「数時間なら無影響」「何日で必ず削除」という固定の期限は置けません。GoogleのHTTPステータスの扱いを確認し、復旧後は実際の応答とSearch Consoleの登録・クロール状況を追います。障害時間、再クロール、検索実績の変化を分けて記録しましょう。

原因の記録を次の検知につなげる

障害記録には、利用者への影響と技術上の原因を分けて書きます。たとえば「フォームを送信できなかった」と「特定の外部API待ちで接続が終了した」は別の記録です。次回はどの監視で早く発見できるか、どの変更前テストで防げるかを一つずつ決めます。単に「再起動で復旧」と書くと、同じ原因かどうか次回判断しにくくなります。運用担当が変わっても追えるよう、ログの参照先と連絡先も残しましょう。