502 Bad Gatewayとは
502 Bad Gateway（以下、502）は、ゲートウェイやプロキシとして動くサーバーが、上流のサーバーから正常な応答を受け取れなかったことを示すHTTPステータスコードです。サーバーエラー（5xx番台）に分類され、リクエストを最終処理するサーバーまでの「中継経路」で問題が起きたときに返されます。
502が返される仕組み
ブラウザからのリクエストは、CDN・リバースプロキシ・ロードバランサーなどの中継機器を経由して上流のWebサーバーへ転送されます。このとき上流サーバーから応答が返らない、または不正な応答が返ってきた場合に、中継機器が502を返します。エラーの起点が中継と上流の「あいだ」にある点が、サーバー本体の処理異常で返る500との決定的な違いです。同じ中継機器の配下にあるURL群でいっせいに502が出やすいのも、この仕組みによります。
（5xxの位置づけ：500=サーバー本体の処理異常／502=中継と上流間の通信障害／503=一時的な利用不可／504=中継から上流への応答タイムアウト）
502エラーが発生する主な原因
502エラーは、中継機器と上流サーバーの間に問題があるときに発生します。代表的な原因は以下の通りです。
上流サーバーが応答していない
上流のWebサーバーがダウンしている、または再起動中で応答できない状態の場合、中継機器は502を返します。サーバー本体の障害やプロセスの停止が該当します。
アクセス集中によるサーバー過負荷
キャンペーンや話題性のある掲載などで、想定以上のアクセスが集中すると、上流サーバーがリクエストを処理しきれずに応答が崩れ、中継機器が502を返すケースがあります。SNSでのバズやニュースサイトへの掲載などの、突発的なトラフィック増加が典型例です。
中継機器(プロキシ・CDN)の設定や障害
リバースプロキシ(Nginx等)の設定ミス、CDN(Cloudflare等)のエッジサーバーと上流サーバー間の通信障害、ロードバランサーのバックエンドプール設定の誤りも、502エラーの原因になります。
ファイアウォール・セキュリティソフトによる通信ブロック
WAFやファイアウォールが、中継機器から上流サーバーへの通信を意図せずブロックしている場合に502エラーが発生します。アクセス元IPの許可リスト変更や、サーバー側のセキュリティ設定変更後に発生しやすい原因です。
DNS解決の問題
中継機器が上流サーバーのドメイン名をIPアドレスに解決できない、またはDNS応答に異常がある場合にも502が返されます。DNSレコードの設定変更直後や、DNSサーバー側の障害が該当します。
訪問者として502エラーに遭遇した場合の対処法
他社サイトの閲覧中に502が表示された場合、訪問者として試せることは次の通りです。502は一時的な過負荷が原因なら時間の経過で解消することがあるため、少し待ってからの再アクセスが有効な場合があります。
- ブラウザを更新（リロード）して再度アクセスする
- 数分待ってから再アクセスする（過負荷が原因なら解消することがある）
- ブラウザのキャッシュとCookieをクリアして再アクセスする
- 別のブラウザや別のネットワーク（モバイル回線等）から開き、自分だけかを確かめる
これらでも解消しないときは、サイト側の障害が続いている可能性が高いと判断できます。
サイト運営者の502エラー対処法
自サイトで502エラーが発生した場合、原因の所在に応じて対処方針が分かれます。
上流サーバーの稼働状況を確認する
最初に確認するのは、上流のWebサーバーが稼働しているかどうかです。SSH接続やコンソールアクセスができる状態か、Webサーバープロセス(Apache、Nginx、PHP-FPM等)が起動しているかを確認します。停止していれば、プロセスを再起動します。
サーバーログを確認する
WebサーバーのアクセスログとエラーログをタイムスタンプベースでGoogle Search Consoleの障害発生時刻と突き合わせ、上流サーバー側で発生していたエラーを特定します。Nginxの場合は /var/log/nginx/error.log などが参照対象です。
中継機器(プロキシ・CDN)の設定を確認する
CloudflareやAWS CloudFrontなどのCDNを利用している場合、エッジサーバーから上流(オリジン)サーバーへの接続設定、タイムアウト値、SSL証明書の状態を確認します。Nginxリバースプロキシの場合は proxy_pass ディレクティブの指定先が正しいかも確認します。
ファイアウォール・WAFの設定を確認する
中継機器から上流サーバーへの通信が、ファイアウォールやWAFでブロックされていないかを確認します。アクセス元IPの許可リストや、特定のリクエストパターンをブロックする設定が原因になっていることがあります。
502エラーに関するよくある誤解と注意点
502エラーに関して、SEO担当者・サイト運営者が混同しやすいポイントを整理します。
「自分だけ502」と「全員502」の見分け方
特定のユーザーだけが502を見ているのか、全員が見ているのかで原因の絞り込みが変わります。
別端末・別ネットワーク・モバイル回線など複数経路からアクセスして再現性を確認しましょう。再現性がない場合は、ユーザー側のネットワークやキャッシュが原因の可能性があります。
計画メンテナンス時は503を使う
計画的なメンテナンスで一時的にアクセスを止めるときは、502ではなく503を返します。503ならRetry-Afterヘッダーで再開予定を示せるため、Googlebotがクロールを過剰に行わずに済みます。一方、502を返すと「中継サーバー間の障害」と判断され、意図と異なる扱いを受けかねません。
CDN利用時は中継機器側のキャッシュも疑う
CloudflareなどのCDNを利用している場合、502がCDNエッジ側のキャッシュとして残ることがあります。上流サーバーが復旧してもユーザー側で502が続く場合は、CDN管理画面でキャッシュをパージします。
5xxエラーがSEOに与える影響
502を含む5xxエラーは、SEOにマイナスに働きます。502は中継経路の障害なので復旧自体は早いことが多い一方、CDNやプロキシの障害が長引くと、その配下のURLがまとめて影響を受けます。
クロール時に502が返るとインデックス更新が遅れる
Googlebotがクロールした瞬間に502が返ると、その時点ではコンテンツを取得できず、インデックスへの反映が遅れます。中継機器の一時的な不調なら影響は限定的ですが、配下の多くのURLが同時に502を返す状態が続くと、影響範囲は広がります。
502が頻発するとサイト全体のクロール頻度が下がる
Googleは、繰り返し5xxを返すサイトに対してクロール頻度を抑えます。サーバーへの負荷を避けるための動作で、結果としてインデックス更新が遅くなります。
サーバーエラー（5xx）と5xxとして扱われるネットワークエラーとDNSエラーは、Googleのクロールに対してマイナスの影響を及ぼします。
https://developers.google.com/search/docs/crawling-indexing/http-network-errors?hl=ja
長期化したURLはインデックスから外れることがある
502が長期間続いたURLは、最終的にインデックスから除外される場合があります。中継機器やCDNの設定を早期に復旧させ、復旧後はSearch Consoleで再クロールを依頼します。
502エラーが発生しているURLを確認する方法
自サイトで502が発生しているURLは、次の方法で確認します。502は中継機器の配下でまとめて発生しやすいため、複数URLを横断して確認し、中継側のログと突き合わせると原因にたどり着きやすくなります。
Search Consoleの「ページ」レポートで5xxを洗い出す
「ページ」レポートでは、検出された5xxが「サーバーエラー(5xx)」として表示されます。確認の手順は、左メニュー「ページ」→「ページがインデックスに登録されなかった理由」→「サーバーエラー(5xx)」と開き、影響URLを絞り込む流れです。500・502・503・504は統合表示されるため、502であることはアクセスログやCDN・プロキシのログで確定させます。
URL検査ツールで個別URLの現在のコードを見る
特定URLの最新状態は、URL検査ツールのライブテストで確認します。実行後、「その他の情報」タブのHTTPレスポンスに現時点のステータスコードが表示されます。
kunugi SEO Checkerで手早くコードを確認する
「kunugi SEO Checker」のパネルデータタブで、表示中ページのステータスコードを確認できます。502は経路やキャッシュの影響を受けやすいため、別端末・別ネットワーク・モバイル回線など複数経路からアクセスし、全員に出ているのか自分だけかを切り分けます。
← 記事一覧へ戻る