502エラー（Bad Gateway）とは？意味とBad Gatewayの原因解決手順を解決！
ゲートウェイ経由で502が発生する際の重要ポイント
502 Bad Gatewayは、リバースプロキシやCDNが上流サーバーから期待どおりの応答を受け取れないときに返されます。まずは経路上のどこで失敗したかを特定し、上流サーバーの応答不正か、ネットワークやTLSの問題かを切り分けます。断続発生ならスパイクやヘルスチェック設定も疑います。
502エラーの定義（意味としくみ）
HTTP 502はゲートウェイ／プロキシ役のサーバーが、上流アプリやオリジンから不正・不完全・タイムリーでない応答を受けたことを示します。構成例として、CDN→ロードバランサー→アプリ→DBの多段経路で、任意の上流がダウン・ハング・ミス設定だと発生します。ヘッダーサイズ超過やKeep-Alive不一致、TLSハンドシェイク不調も典型要因です。
実務での論点（原因・使い分け・よくある落とし穴）
原因はアプリ障害だけに限りません。ネットワークや名前解決、WAFやプロキシのタイムアウト、バックエンドの過負荷など多層で起きます。観測では上流別にメトリクスとログを分離し、相関IDでリクエストを追跡できると復旧が速くなります。
- ユーザー側の対処：数十秒待って再読み込み、別ネットワークで再試行、ブラウザー拡張の一時停止。継続する場合はサイト側の障害情報を確認
- 開発・管理者側：CDN／LB／アプリの各層ログとヘルスチェックを確認し、どの層で502が生成されたかを特定。リバースプロキシ経路ごとにタイムアウトとバッファ設定を見直し
- 上流確認：DNS解決・TLSバージョンや証明書、Keep-Alive、ヘッダーサイズ上限、アップストリームのキュー滞留を点検
- 負荷対策：オートスケール、コネクションプール調整、サーキットブレーカーとリトライ（ジッター付き）でスパイクを平滑化
- 運用：エラーページに発生時刻・リクエストIDを表示し、監視では502率・上流別失敗率・p99遅延を可視化
比較・使い分け表（502・500・503・504）
| 項目 | 意味 | 用途 |
|---|---|---|
| 502 Bad Gateway | ゲートウェイが上流から不正応答 | プロキシ／CDN／LB経路での上流起因の失敗を示す |
| 500 Internal Server Error | アプリ内部の予期せぬ例外 | 単一アプリ内の障害や未処理例外に使用 |
| 503 Service Unavailable | 一時的な停止・過負荷 | メンテや容量不足。Retry-After併用が望ましい |
| 504 Gateway Timeout | 上流応答の時間切れ | 遅延が主因のときに返す（処理継続の可能性） |
SEO・運用上の注意
502は一時的障害として検索エンジンが再試行しますが、連発するとクロール効率が低下します。メンテナンスでは503＋Retry-Afterの方が意図を伝えやすく、502は避けます。エッジやCDNでのエラーレスポンスは原則キャッシュせず、キャッシュ禁止設定と重要URLの優先監視を行います。
よくある質問（FAQ）
502と504の違いは何ですか？
502は上流から不正な応答を受けた状態、504は上流応答の時間切れです。前者は応答内容の不整合、後者は遅延が主因で、対処の焦点が異なります。
断続的な502は何を疑うべきですか？
スパイクによる上流過負荷、コネクション枯渇、DNSやTLSの不安定、ロードバランサーのヘルスチェック誤判定を確認します。上流ごとのメトリクス分離が有効です。
CDN利用時に502が出ます。どこから調べれば良いですか？
CDNのエラーログでオリジン到達の成否とレスポンスコードを確認し、オリジン側のタイムアウト・証明書・ヘッダー上限を点検します。CDN→オリジン間の経路に的を絞るのが近道です。
ユーザーに案内する文言のポイントは？
一時的障害である旨、再試行目安、障害情報へのリンク、リクエストIDの提示を入れます。過度な技術用語を避け、復旧手順を簡潔に示すと離脱を抑えられます。
502エラーのまとめ
502はゲートウェイ配下の上流起因で発生する一時的失敗です。ユーザーは短時間の再試行で様子見し、管理者は経路ごとのログ・メトリクスで原因層を特定します。再発防止にはタイムアウト設計、スケール戦略、相関IDの付与が有効で、迷ったときは上流経路の切り分けを徹底することが近道です。
