502 Bad Gatewayの意味、500・503など他の5xxサーバーエラーとの違い、502を含む5xxエラーがSEOに与える影響を解説します。
502 Bad Gatewayとは
502 Bad Gateway(以下、502)は、ゲートウェイまたはプロキシとして機能しているサーバーが、上流のサーバーから不正な応答を受け取ったことを示すHTTPステータスコードです。サーバーエラー(5xx番台)に分類され、リクエストを最終的に処理するサーバーまでの中継経路で問題が発生したことを意味します。
502が返される仕組み
ブラウザが特定のURLにアクセスすると、リクエストは複数のサーバーや中継機器を経由してWebサーバーに到達します。CDN・リバースプロキシ・ロードバランサーなどの中継機器が、その先(上流)のサーバーに対してリクエストを転送し、応答を受け取ってブラウザに返します。この上流サーバーから応答を受け取れない、または不正な応答が返ってきた場合、中継機器は502を返します。
5xx番台のステータスコードの分類
HTTPステータスコードのうち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が表示された場合、訪問者として試せる対処法は以下の通りです。
- ブラウザを更新(リロード)して再度アクセスを試みる
- 数分待ってから再アクセスする(過負荷が原因なら時間経過で解消することがある)
- ブラウザのキャッシュとCookieをクリアして再アクセスする
- 別のブラウザ・別のネットワーク(モバイル回線等)からアクセスを試す
- X(旧Twitter)等で同じサイトの障害情報が報告されていないか確認する
これらを試しても解消しない場合、サイト運営者側の障害が継続している可能性が高いと判断できます。
サイト運営者の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に与える影響は以下です。
5xxはGooglebotにとってクロール阻害要因になる
GooglebotがクロールしたURLが5xxを返した場合、その時点ではコンテンツを取得できないため、インデックス更新が遅延します。短時間の障害であれば影響は限定的ですが、長期化するとサイト全体のクロール頻度が下げられる可能性があります。
サーバーエラーが継続するとクロール頻度が下がる
Googleは、サーバーが頻繁に5xxを返すサイトに対してクロール頻度を抑制します。これはサーバーへの負荷を考慮した動作で、結果的にインデックス更新が遅くなる原因になります。
サーバーエラー（5xx）と5xxとして扱われるネットワークエラーとDNSエラーは、Googleのクロールに対してマイナスの影響を及ぼします。Googleはできるだけ多くのページをクロールしますが、サイトの帯域に過度の負担をかけないようにします。
https://developers.google.com/search/docs/crawling-indexing/http-network-errors?hl=ja
5xxが継続するとインデックスから除外される可能性がある
5xxの状態が長期間続くと、対象URLが最終的にGoogleのインデックスから除外されることがあります。早期の復旧と、復旧後のSearch Consoleでの再クロール依頼が望ましい対処です。
502エラーが発生しているURLを確認する方法
自サイトで502エラーが発生しているURLは、以下の方法で確認できます。
Google Search Consoleのページレポートで確認する
Google Search Consoleの「ページ」レポートでは、Googlebotがクロール時に検出した5xxエラーを「サーバーエラー(5xx)」として一覧で確認できます。
- Google Search Consoleにログインする
- 左メニュー「ページ」を選択する
- 「ページがインデックスに登録されなかった理由」内の「サーバーエラー(5xx)」を選択する
- 表示される影響を受けたURLの一覧から、対処すべきURLを特定する
このレポートは502・503・504などの5xxを統合表示するため、具体的なステータスコードの種類は、サーバー側のアクセスログを参照して特定します。
URL検査ツールで個別に確認する
特定URLに対するGooglebotの最新ステータスを確認したい場合は、Google Search ConsoleのURL検査ツールを使用します。
ライブテストを実行後、「その他の情報」タブのHTTPレスポンスから、現時点でのHTTPステータスコードを確認できます。
kunugi SEO Checkerで確認する
弊社のChrome拡張機能「kunugi SEO Checker」を使うと、パネルデータのタブに、各URLのステータス(502・200・503等)が表示されるため、ステータスコードを短時間で確認できます。
ただし、kunugi SEO Checkerで確認できるステータスコードは、ご自身が利用している端末・ネットワーク下での結果となります。別端末・別ネットワーク・モバイル回線など複数経路からアクセスして再現性を確認しましょう。
kunugi SEO Checkerでのステータスコード確認手順
- 確認したいサイトを開く
- kunugi SEO Checkerを起動する
- パネルデータのステータスコードを確認する
サーバーログとあわせて死活監視ツールで早期検知する
502エラーが頻繁に発生する場合は、死活監視ツールでリアルタイムに検知する仕組みを作るとよいでしょう。
- UptimeRobot：無料プランで5分間隔の監視と通知が可能
- Pingdom：レスポンスタイムとステータスコードの統合監視が可能
関連記事
404 not foundとは？意味・原因・対処法とSEOへの影響
301リダイレクトの設定方法と確認手順
Google Search ConsoleのURL検査ツールの使い方
