502 Bad Gateway（ゲートウェイエラー）

TL;DR — 502 Bad Gatewayは、あるサーバーが別のサーバーにページを要求し、悪い応答を受け取ったことを意味します。通常、「前面」のサーバーはCDNまたはプロキシで、「背面」のサーバーは実際のWebサイト（オリジン）です。エラーはGoogle Search Consoleではなく、ホスティング／インフラにあります。短時間の502は実務上のSEOリスクが通常限定的ですが、Googleは正確な「安全」期間を公表していません。長引くほど大きな問題になります。

502 Bad Gatewayとは何か

ページを読み込むとき、リクエストは通常、Webサイトへ直接は送られません。CDN（Cloudflareなど）、ロードバランサー、リバースプロキシ（Nginxなど）という仲介役を通ります。その仲介役が実際のサーバーにリクエストを転送し、応答を待って訪問者へ返します。

502 Bad Gatewayは、仲介役がサーバーにページを要求し、無効なもの、または何も返ってこない応答を受け取ったときに表示されます。平たく言えば、前面のサーバーが背面のサーバーから適切な応答を得られなかったということです。 Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

ここが重要な点です。502が出たからといって、Webサイトが自動的に停止しているわけではありません。サーバーは完全に正常で、直接のリクエストには問題なく応答しているかもしれません。しかし、前面のプロキシがそこへ到達できなければ（タイムアウト、設定ミス、またはCDN側の一時的な障害など）、訪問者には502が表示されます。

仲間のステータスコードとの違い

似て見える5xxエラーがいくつかあります。

• 500 — ページの構築中に、Webサイト自身のコードがエラーになった。
• 502 — サイトの前面にあるプロキシが、サイトから不正な応答を受け取った。
• 503 — サイトが意図的に利用できない（計画メンテナンス、過負荷）。
• 504 — プロキシがサーバーを待ったが、応答がまったくないままタイムアウトした。

これらは関連していますが、調べるべき場所はそれぞれ異なります。

502はSEOに悪影響を与えるか

通常、長引かなければ大きな影響はありません。Googleのクローラー（Googlebot）は、502をほかの5xxエラーと同じように扱います。エラーになっているURL数に比例してクロールを遅くし、サイトが再び2xxで応答し始めると速度を戻します。Googleは正確な「安全」期間を公表していませんが、短時間の502（数分から数時間）は、繰り返し発生する502より実務上のリスクがはるかに小さいものです。 Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

本当のリスクは、502が繰り返し発生するか、長時間続く場合に現れます。Google自身の表現は、サーバーエラーを**「persistently」** (翻訳)「継続的に」返すURLを削除するというものです。これを特定の日数とは定義していません。（GoogleのJohn Muellerは、ページが消え始めるおおよその時期として「multiple days」 (翻訳)「複数日」に言及し、サイトが回復すれば戻る傾向があるとも非公式に述べています。ただし、これは特定の事例についての1人の大まかな読みであり、公式ルールではありません。）

502への対処方法

• Search Consoleで「修正」しようとしないでください。 Search Consoleは事後に502を報告するだけです。修正はCDN、プロキシ、またはサーバーで行います。
• 自分だけか全員かを確認します。 インターネット全体は正常なのにサイトが停止しているなら、設定側の問題です。大規模CDNで障害が起きているなら、あなたの責任ではなく、待つ以外に自分側で直すこともありません。
• ホストまたはCDNのステータスページとサーバーログを確認します。 本当の答えはそこにあります。

層ごとの診断（CDNとプロキシとオリジンの違い）、Googleの文書が正確に述べていること、2025年11月のCloudflare障害中にJohn Muellerが述べたことまで知りたいなら、Advancedタブに切り替えてください。

TL;DR — 502はプロキシ／ゲートウェイ層の障害です。RFC 9110 §15.6.3は、ゲートウェイまたはプロキシがインバウンドサーバーから無効な応答を受け取ることと定義しています。オリジンアプリがエラーになった500や、オリジンが意図的に利用できない503とは異なります。Googleの文書は500、502、503を1つの5xxの扱いにまとめています。エラーになるURL数に比例してクロールレートが下がり、5xxのコンテンツは無視され、エラーが継続するとページがインデックスから外れます。2xxが再開すれば回復は段階的に進みますが、Googleは固定された期間を公表していません。期間は重要ですが、公式の閾値はありません。短い急増の実務上のリスクははるかに小さく、ページに本当のリスクをもたらすのは繰り返し発生するエラーです。Muellerの2025年11月の発言は、文書化されたSLAではなく、非公式に複数日程度としています。CDN、リバースプロキシ、オリジンという層で診断し、ブランド付きエラーページだけを信用せず、各ホップの証拠を突き合わせてください。

502が実際に示すもの

RFC 9110 §15.6.3は、502を、リクエストを満たそうとしてアクセスしたインバウンドサーバーから、ゲートウェイまたはプロキシが無効な応答を受け取った状態と具体的に定義しています。この仕様の境界は重要です。失敗をゲートウェイが観測した場所を示しますが、どのホップが原因だったかまでは必ずしも示しません。502ステータスは境界での障害の証拠であり、オリジンアプリが壊れている証明ではありません。この違いを、競合他社の「修正方法13選」の多くは曖昧にしています。そのため、以下の診断は平板な一覧ではなく、層に分けています。 Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

混同しやすい5xxコードを比較します。

• 500 Internal Server Error — オリジンアプリ自体がエラーになった（コードのバグ、未処理の例外、リソース枯渇）。オリジンは応答し、その内容は「I broke.」 (翻訳)「壊れました」でした。
• 502 Bad Gateway — プロキシが上流から不正または無効な応答を受け取った（RFC 9110 §15.6.3）。
• 503 Service Unavailable — オリジンが意図的に利用できない。計画メンテナンスで使う、意図的でGoogle公認の「come back later」 (翻訳)「後で戻ってきて」というコードで、できればRetry-Afterヘッダーを付けます。
• 504 Gateway Timeout — プロキシが上流を待ったものの、タイムアウトが切れるまでに何も受け取れなかった（RFC 9110 §15.6.5）。（502＝悪い応答、504＝時間内に応答がない。）

実務上の要点は、503が意図的に選ぶコードであり、502はインフラが壊れたときに起きるコードだということです。

Googlebotは502をどう扱うか

ここでは、他で見かける曖昧な「it can hurt rankings」 (翻訳)「ランキングに悪影響を与える可能性がある」ではなく、Googleの実際の文書に基づいて考える価値があります。GoogleのHTTP and network errors文書は502 (bad gateway)を5xxコードとして一覧に載せ、すべての5xxコードを同じように扱います。

• クロールレートが比例して下がる。 Googleはサイトのクロールレートを下げ、その低下幅はサーバーエラーを返す個別URLの数に比例します。少数の502は軽微ですが、サイト全体の502は明確な「slow down」 (翻訳)「速度を落とす」信号です。
• 5xxコンテンツは無視される。 5xxを返すURLからGoogleが受け取るものは無視されます。502のエラーページがあなたのコンテンツとしてインデックスされることはありません。
• インデックス保持は一時的。 すでにインデックスされたURLは最初は残りますが、Googleのインデックス登録パイプラインは、サーバーエラーを継続的に返すURLを削除します。
• 回復は自動的かつ段階的。 サーバーが再び2xxで応答し始めると、Googleはクロールレートを徐々に戻します。通常の回復に再送信、再審査リクエスト、「修正を検証」するための大げさな対応は必要ありません。そのボタンはGoogleに早く再確認させるだけです。

最も重要な要点は、502が500や503と同じように扱われることです。オリジンアプリではなくプロキシ／CDN層で発生するからといって「深刻度が低い」わけではありません。502に対する文書化された寛容さはありません。 Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

期間がすべて

502が実際に影響を与えるかどうかは、どれくらい続くかにかかっています。ただしGoogleは、固定された安全期間も、固定された削除閾値も公表していません。以下は実務上の補足であり、SLAではないと考えてください。

• 短い急増（数分から数時間） → Googleのクロールレート低下はエラーになるURL数に応じて大きくなるため、短時間かつ小規模な急増の実務上の影響は限定的で、通常はSearch Consoleで追いかける価値がありません。Googleの文書が短いエラーを正式に免除しているわけではなく、厳格な線引きではなく程度の問題です。
• 繰り返し発生する、または継続するエラー → Googleの「サーバーエラーを継続的に返す」という表現が当てはまり、ページがインデックスから外れ始める可能性がある期間です。Googleは「継続的に」を特定の日数とは定義していません。Muellerの公開コメント（下記）は、サイトが健全になれば回復はかなり速いとしつつ、非公式にはmultiple days (翻訳)「複数日」程度としています。ただし、これは特定のサイトやCDNすべてに適用できる文書化されたルールではなく、特定の事例に対する1人の実務家の読みです。

これは、2025年11月のCloudflare障害と大まかに重なります。このとき多数のサイトが自らの責任ではなく5xxを返しました。MuellerはBlueskyで、5xxではクロールが遅くなるが「ramps back up」 (翻訳)「再び上がる」と公開返信しています。正確な文言と、第三者の要約経由で伝えられ元のスレッドで検証されていない「multiple days」 (翻訳)「複数日」という別のコメントを含む、出典上の注意点はQuotesタブを参照してください。短く、プロバイダーが障害を確認した停止は最善に近いケースです。目に見える障害で、通常は自然に解消し、プロバイダーが回復を確認して自分の2xxレスポンスも再開したら、合理的な対応は、反応的にインフラを変更するのではなく、通常は変更を控えることです。

層ごとに502を診断する

502はサーバー間の通信障害なので、最も速く見つける方法は、平板なチェックリストを進めるのではなく、CDN、リバースプロキシ、オリジンの順にスタックを下って調べることです。（Decision Treesタブでこの手順を確認できます。）

始める前に1つ注意があります。ブランド付きのエラーページ、ヘッダーにあるプロバイダー名、障害の「見た目」は、どのホップが失敗したかを示す1つの証拠にすぎず、証明ではありません。「CDNだ」「オリジンだ」と結論づける前に、レスポンスヘッダー、リクエスト／トレースID、ホップの両側にある時刻付きログと突き合わせてください。

CDN／エッジ層

• 上流のタイムアウト：エッジノードが時間内にオリジンから応答を得られなかった。
• エッジがオリジンにまったく到達できない。DNS解決の失敗、SSL/TLSハンドシェイクの失敗、またはオリジンのファイアウォール／セキュリティがCDNのIP範囲をブロックしている。
• 文書化された原因はプロバイダーごとに異なります。Cloudflareのトラブルシューティング文書は自社のエッジネットワーク固有のオリジン接続やタイムアウトのシナリオを説明し、AWS CloudFrontはTLS、DNS、ポート、オリジン関数に関する独自の原因を文書化しています。あるプロバイダーの原因一覧が別のプロバイダーにも当てはまると仮定せず、使っているCDNの文書を確認してください。
• CDNプロバイダー自身の障害（Cloudflare、Fastly、AWSなど）。サーバーの健全性とは無関係なサイト横断の大量502です。エラーページのブランド表示だけでなく、プロバイダーのステータスページで確認してください。

リバースプロキシ／ロードバランサー層（Nginx、Apache mod_proxy、HAProxy）

• バックエンドのタイムアウトまたは接続拒否。
• 間違った場所を指す、設定ミスのproxy_pass／上流ブロック。
• バックエンドプールの枯渇。上流ワーカーがすべて使用中。
• プロキシとバックエンド間のSSL/TLS不一致。

オリジンサーバー層

• アプリケーション／PHP-FPMのクラッシュまたは再起動、あるいはOOMによる強制終了（メモリ上限超過）。
• データベース接続の枯渇。
• 短時間の利用不可を引き起こすデプロイ／再起動。
• WAFまたはセキュリティプラグインが、正当なプロキシやクローラーのIPを攻撃者のように扱ってブロックしている。通常のブラウザーは正常に動くのに、プロキシ（またはGooglebot）だけが502を受け取るため、見つけにくい原因です。

最後のパターンは指摘する価値があります。**Googlebotだけ、またはCDN経由のリクエストだけが502になり、通常のブラウザーはならない場合、真の障害ではなく、ボット固有のブロックまたは応答の変化が起きています。**オリジンへの直接アクセスとCDN経由をテストし、すでに古い可能性があるServer error (5xx)レポートから継続的な影響を推測するのではなく、Search ConsoleのURL InspectionライブテストでGooglebotが実際に見るものを確認してください。

502を修正し、再発を防ぐ

修正は層ごとに異なり、実施すべき人も役割によって変わります。

• 訪問者 — 修正することはありません。1回再読み込みし、ローカルの問題が疑われるなら別のネットワークを試し、それ以外は待ちます。ブラウザー側の変更でサーバー間の障害を修復することはできません。
• インフラにアクセスできないサイト所有者 — まず範囲を確認し、ステータスページ／ログを確認します（下のチェックリストを参照）。その後、修正を推測せず、ホスト、CDNサポート、または開発チームにエスカレーションします。
• ホスト／CDN／アプリケーション所有者 — プロキシ／上流設定を修正し、オリジンが実際のボトルネックならタイムアウトとバックエンド容量を引き上げ、再起動でプール全体が一時的に停止しないようデプロイを分散します。**WAFの許可リスト、ファイアウォール変更、プロキシ／上流設定の編集は承認が必要な変更として扱ってください。**ログとプロバイダーの証拠がファイアウォールまたはアクセス制御の失敗を実際に示した後にだけ適用し、初動の推測で行ってはいけません。CDNやクローラーを許可リストに追加しても、一般的な502修正にはなりません。

再発防止では、地味な対策が有効です。アラート付きの稼働監視、サーバーとプロキシのエラーログ監視、Search Consoleのクロール統計にあるHost statusとServer error (5xx)の傾向の確認、CDNとDNSプロバイダーのステータスページとの急増の照合を行えば、「自分の問題」と「相手の障害」を数秒で区別できます。

このクラスターでは、関連コードをすぐ隣に置いて整理しておくと便利です。オリジンの500、意図的な503、タイムアウトの504です。

AI summary

Advanced版の要約です。

• 502＝プロキシ／ゲートウェイ層の障害。 RFC 9110 §15.6.3は、ゲートウェイまたはプロキシがインバウンドサーバーから無効な応答を受け取る状態と定義しています。これは境界での障害の証拠であり、どのホップ（CDN、プロキシ、オリジン）が原因かの証明ではありません。オリジンが正常でも訪問者には502が表示されることがあります。
• 原因は異なっても、文書上は同じファミリー。 500（オリジンアプリのエラー）、502（プロキシが悪い応答を取得、RFC §15.6.3）、503（オリジンが意図的に利用不可）、504（プロキシが時間内に応答を取得できない、RFC §15.6.5）です。Googleの文書は500、502、503を1つの5xxの扱いにまとめていますが、そのファミリーのルールを超えたステータス別の同等性までは文書化していません。
• Googlebotの反応。 エラーになるURL数に比例してクロールレートが下がり、5xxコンテンツは無視され、インデックス済みURLは短期的には保持されますが、エラーが継続すると削除されます。2xxが再開するとクロールは段階的に戻ります。Googleは正確な安全期間も、回復の時期も保証していません。
• 期間は重要ですが、公式閾値はありません。 短い急増の実務上のリスクははるかに小さく、現実のリスクは繰り返し発生するエラーです。Muellerの2025年11月の非公式コメントは、インデックスからの削除を「multiple days」 (翻訳)「複数日」程度としています。これは特定の事例についての実務家の読みであり、文書化されたSLAではありません。
• ブランドだけを信用せず、層をまたいで証拠を突き合わせて診断します。 CDN（タイムアウト、DNS／SSLの失敗、プロバイダー障害。CloudflareとAWS CloudFrontはそれぞれプラットフォーム固有の異なる原因を文書化） → リバースプロキシ（不正なproxy_pass、プール枯渇、接続拒否） → オリジン（アプリ／PHP-FPMのクラッシュ、OOM、DB枯渇、プロキシ／クローラーIPをブロックするWAF）です。どの層が失敗したか結論づける前に、ホップの両側のヘッダー、トレースID、時刻付きログを照合してください。
• 万能の修正ではありません。 GSCは事後に502を報告するだけで、修正はできません。訪問者にも修正できません。インフラにアクセスできないサイト所有者は設定を編集せずエスカレーションすべきで、破壊的な変更（WAFの許可リスト、ファイアウォールやプロキシの編集）はログ／プロバイダーの証拠に基づいて行い、初動の推測にしてはいけません。Googlebotだけ、またはCDN経由だけが502なら、全体障害ではなくボット固有のブロックを疑います。

公式ドキュメント

検索エンジンが502を含む5xxエラーをどう扱うかについての一次資料です。

Google

• HTTPステータスコードがGoogleのクローラーに与える影響 — 主要な文書です。502 (bad gateway)を500、503と並べ、クロールレートとインデックス登録に共通する扱いを説明しています。
• 計画停止への対処方法 — 意図的な停止には、502、404、200ではなく、Retry-Afterヘッダー付きの503が適切なコードである理由を説明しています。502と503の違いに役立ちます。
• robots.txt仕様 — サーバーエラーの扱い — robots.txt自体が5xxを返した場合のGoogleの扱いを説明しています。

仕様

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — 仕様レベルの定義です。リクエストを満たそうとしてアクセスしたインバウンドサーバーから、ゲートウェイまたはプロキシが無効な応答を受け取ることを示します。失敗が観測された境界は示しますが、どのホップが原因かは示しません。

Bing／Microsoft

• Bing Webmaster Tools — Help Center — Bingは接続失敗を含むサーバー側（5xxクラス）のクロール問題を、クロールエラーの報告で表示します。

原文からの引用

Googleによる記録に残る発言です。各リンクは引用箇所へ直接移動します。

Google — 502を含む5xxの扱い

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (翻訳)「5xxと429のサーバーエラーは、Googleのクローラーにクロールを一時的に遅くさせます。Google検索では、すでにインデックスされているURLはインデックスに保持されますが、最終的には削除されます。」 — Google Search Central、How HTTP status codes affect Google’s crawlers。 Jump to quote
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.” (翻訳)「Googleはサイトのクロールレートを下げます。クロールレートの低下は、サーバーエラーを返す個別URLの数に比例します。Google検索では、Googleのインデックス登録パイプラインが、サーバーエラーを継続的に返すURLをインデックスから削除します。」 — 同じ文書で、500、502、503を扱う表の行です。 Jump to quote
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (翻訳)「サーバーが2xxステータスコードで応答し始めると、Googleはサイトのクロールレートを徐々に上げます。」 — 同じ文書です。 Jump to quote

John Mueller、Google（Bluesky、2025年11月18日 — Cloudflare障害による5xx急増についてのスレッドへの返信）

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (翻訳)「そうです。5xxではGoogleのクロールが遅くなりますが、再び上がります。」 View the post
• “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” (翻訳)「5xxが複数日続くと、外れ始める可能性があります。ただ、その場合でもかなり速く戻ります。」 同じやり取りを扱ったMatt G. SouthernのSearch Engine Journal記事経由で伝えられたものです。最終的な引用として扱う前に、元のスレッドで確認してください。 報道記事を読む

502 Bad Gatewayレスポンスのチェックリスト

502がブラウザー、監視、またはSearch ConsoleのServer error (5xx)レポートに現れたら、この一覧を実行します。役割タグ：**[Any]はインフラへのアクセスがあるかどうかに関係なく実行でき、[Host/CDN/App owner]**はそれが必要です。

• [Any] 本当に現在のエラーか確認する。今URLを再現します。Server error (5xx)レポートは、すでに解消した障害の後を追っている可能性があります。
• [Any] 範囲を確認する。1つのURL、セクション、サイト全体のどれですか。（クロールへの影響はエラーになるURL数に応じて大きくなります。）
• [Any] 自分の設定に触る前に、CDN／DNSプロバイダーのステータスページでプロバイダー全体の障害を確認する。
• [Host/CDN/App owner] オリジンへの直接アクセスとCDN経由をテストする。オリジンが直接2xxで応答するのにCDNが502を返すなら、問題はエッジまたはその間にあります。
• [Host/CDN/App owner] ブラウザーは正常なのにボット／CDNのIPだけが502を受け取っていないか確認する。これは障害ではなく、可能性のあるWAF／ファイアウォールのブロックを示します。何かを許可リストに追加する前に、ファイアウォール／WAFログで確認してください。許可リスト追加は一般的な修正ではなく、証拠に基づいて行うもので、先に行ってはいけません。
• [Host/CDN/App owner] プロキシのエラーログ（Nginx／Apache／HAProxy）で、上流のタイムアウトまたは接続拒否の記録を読む。
• [Host/CDN/App owner] 時刻の前後にあるオリジンログで、アプリのクラッシュ、OOMによる強制終了、DB接続の枯渇を読む。
• [Any] GSCのURL InspectionライブテストでGooglebotが見るものを確認する。
• [Host/CDN/App owner] ログ／プロバイダーの証拠が示す層にだけ、層固有の修正を適用する。WAF、ファイアウォール、タイムアウト、プロキシ設定の変更はインフラ変更であり、初動の推測ではありません。
• [Any] 修正後は回復させる。2xxレスポンスによってクロールは徐々に戻ります。Googleは正確な回復期間を公表していません。「Validate Fix」は「修正」ではなく、早く再確認させるためだけに使います。
• [Host/CDN/App owner] 今後、計画的な停止には502ではなく503を使っていることを確認する。

私の502はCDN、プロキシ、オリジンのどの問題か？

502はサーバー間の障害なので、推測するのではなく、スタックを上から下へたどって診断します。エッジから始め、内側へ進んでください。

Q1. CDNまたはDNSプロバイダーは、現在障害を報告していますか？

• はい →最も可能性が高いのはプロバイダー全体の障害です（2025年11月のCloudflare事象が典型例です）。通常、あなた側で直すことはありません。オリジンが正常であることを確認し、回復を待ちます。2xxレスポンスが再開するとGoogleのクロールレートは徐々に戻りますが、正確な期間は公表されていません。ここで止めます。
• **いいえ →**続行します。

Q2. CDN／プロキシを迂回した直接リクエストで、オリジンは2xxを返しますか？

• いいえ — オリジンも失敗 →問題はオリジン層にあります。ログでアプリ／PHP-FPMのクラッシュ、OOMによる強制終了、データベース接続の枯渇、悪いデプロイを確認します。プロキシからの見え方によっては、これが500や504として表示されることもあります。ここで止めます。
• **はい — オリジンは直接なら正常だが、CDN／プロキシが502を返す →**続行します。オリジンは正常で、その前段の何かがきれいな応答を取得できていません。

Q3. 通常のブラウザーは動くのに、Googlebot／CDNのIPだけが502になりますか？

• はい →プロキシまたはクローラーのIP範囲を攻撃者として扱うWAFまたはファイアウォールのブロックを疑います。まずファイアウォール／WAFログで確認し、正当なCDNと検証済みクローラーのIP範囲だけを許可リストに追加します。確認なしに許可リストへ追加してはいけません。ここで止めます。
• **いいえ — プロキシ経由の全員が502 →**続行します。

Q4. リバースプロキシのログは上流について何を示していますか？

• **タイムアウト／接続拒否 →**プロキシはバックエンドに到達できるものの、時間内に有効な応答を得られていません。バックエンド容量またはタイムアウトの問題です（プール枯渇、短すぎるタイムアウト）。容量／タイムアウトを引き上げるか、遅いバックエンドを修正します。
• 上流への接続でホスト／DNSが間違っている、またはSSLハンドシェイクに失敗 →****プロキシ設定の誤りです。proxy_pass／上流ブロック、またはプロキシ↔バックエンドのTLS設定を修正します。

層がどこであっても、SEO上の後始末は同じで、ほとんど手をかけません。URLが2xxを返せば、Googleは自動的にクロールを再開します。再送信は必要ありません。

502に関する神話と避けるべきミス

• 神話：「502 is a Google/SEO problem I fix in Search Console.」 (翻訳)「502はSearch Consoleで直すGoogle／SEOの問題だ。」違います。502はホスティング／インフラの障害で、Search Consoleは事後に報告するだけです。修正はCDN、プロキシ、オリジンで行います。「Validate Fix」 (翻訳)「修正を検証」はGoogleに再確認を依頼するだけで、何かを修復するものではありません。
• 神話：「A 502 always means my server is down.」 (翻訳)「502は常にサーバーが停止していることを意味する。」違います。オリジンは直接のリクエストに2xxを返していても、訪問者はCDN経由で502を見ることがあります。タイムアウト、上流設定の誤り、CDN自身の障害などが原因です。サーバーがクラッシュしたと考える前に、オリジンへの直接アクセスをテストしてください。
• 神話：「502 is less serious than 500 for SEO.」 (翻訳)「502はSEO上500より深刻ではない。」違います。Googleの文書では、500、502、503に同じクロールレート低下と、エラーが続く場合の同じ最終的なインデックス削除が適用されます。502に対する文書化された寛容さはありません。
• 神話：「A one-time 502 will deindex my page.」 (翻訳)「1回の502でページがインデックスから外れる。」違います。クロールは遅くなり、その後戻ります。インデックスからの削除にはエラーが継続する必要があります。Googleの文書はこの語を使いますが、正確な日数は定義していません。Muellerの2025年11月の非公式コメントはmultiple days (翻訳)「複数日」程度とし、削除されたページは「pop back in fairly quickly」 (翻訳)「かなり速く戻る」と述べています。これは1つの事例についての実務家の読みであり、公式閾値ではありません。
• 神話：「502 and 503 mean the same thing.」 (翻訳)「502と503は同じ意味だ。」違います。503は計画メンテナンスで使うべき意図的な「service unavailable」 (翻訳)「サービス利用不可」コードです（Retry-After付き）。502は意図しないプロキシ障害です。両者を監視で混同すると、予想されたメンテナンス期間の陰に実際のインシデントを隠してしまいます。
• 神話：「Clearing my browser cache fixes a site-wide 502.」 (翻訳)「ブラウザーキャッシュを消せばサイト全体の502が直る。」これは自分の表示を調べる訪問者向けの助言です。CDN／プロキシ／オリジンが本当に失敗しているなら、ブラウザー側の操作で他の人の状態は変わりません。
• アンチパターン：反射的に「Validate Fix」を押してGSCを更新する。 一時的な急増（またはCDN障害）の間は、回復を確認する以外に何もしないことが、最も速く正しい対応である場合が多いです。Googleは戻りを自動的に処理します。

インシデント対応手順：サイトが502を返している

1. 範囲を確認する。 Website Down Checkerで影響を受けたURLを1つ確認し、Bulk HTTP Status Code Checkerで複数のURLをテストします。ブラウザーだけが失敗するなら、サイト全体のインシデントにエスカレーションする前に、ローカルネットワークまたはDNSの問題を解消します。公開URLの多くが502を返すなら続行します。
2. 失敗したレスポンスを記録する。 時刻、URL、ステータス、レスポンスヘッダー、CDNのリクエストIDを保存します。断続的なエラーなら、1回の再試行成功を回復と見なさず、リクエストを繰り返します。
3. ゲートウェイを特定する。ブランド表示は1つの信号であり、証明ではありません。 CDN、リバースプロキシ、ロードバランサーの痕跡をヘッダーとブランド付きエラーページから読み取りますが、どのホップが失敗したかを結論づける前に、プロバイダーのステータスページと自分のログで確認します。ブランド付きページとヘッダーはプロバイダー固有で、原因を普遍的に証明するものではありません。プロバイダーが障害を報告しているなら、そのインシデント手順に従い、それ以外はオリジンへ向かって調べます。
4. エッジとオリジンを比較する。 公開ホスト名を通常どおり要求し、次にcurl --resolveで同じホスト名を既知のオリジンIPへ直接送ります。オリジンが成功するのにエッジが502を返すなら、CDNとオリジン間の接続、TLS、プロキシ設定を調べます。両方が失敗するなら、アプリケーションとオリジンのログへ進みます。
5. ログを時刻で照合する。 接続拒否またはTLS失敗はゲートウェイとオリジンの境界を示し、不正または突然切断された上流応答はオリジンサービスを示します。Search Consoleではなく、失敗している層を修正します。
6. 回復を確認する。 代表的なURLで公開アクセスとオリジンへの直接アクセスを再実行します。2xxレスポンスが安定していれば、Googlebotが自動的にクロールを再開する間、ログとSearch Consoleを監視します。502が再発したら、むやみに再試行を増やすのではなく、新しい時刻を使って手順4に戻ります。

プロンプト：502障害のバッチを層別に分類する

URL、時刻、ステータス、レスポンスヘッダー、公開エッジの結果、オリジンへの直接アクセス結果、対応するログ抜粋を含むCSVを貼り付けます。まず秘密情報、Cookie、認証ヘッダー、非公開のオリジンアドレスを削除してください。

You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.

For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.

Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.

DATA:
[PASTE SANITIZED CSV HERE]

決定的な根本原因レポートではなく、トリアージキューが返るものと考えてください。提案されたすべてのチェックを、実際のヘッダーとログで検証します。

公開側の502を再現する

macOS／Linuxのシェルで実行します。本文をダウンロードせずにレスポンスヘッダーを表示し、リダイレクトにも従わないため、最初のレスポンスを確認できます。

curl -sS -D - -o /dev/null https://www.example.com/affected-path

PowerShell版：

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheck

アプリケーションがHEADを別の方法で処理する場合は、通常のGETを使って本文を破棄します。

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headers

CDN経路と既知のオリジンを比較する

203.0.113.10を、自分が管理するオリジンIPに置き換えます。--resolveは、そのIPに接続しながら、HTTP HostヘッダーとTLS名には公開ホスト名を保持します。

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/affected-path

このテストのために保護されたオリジンを公開したり、ファイアウォールを弱めたりしないでください。すでに承認されたネットワークから実行します。公開側が502でオリジンへの直接アクセスが成功するなら、障害はCDN／プロキシ経路に絞られます。両方の経路が失敗するなら、オリジンまたはアプリケーションを調べます。

502を絞り込むツール

• Website Down Checker — 外部のCloudflare vantage pointからURLに到達できるかを確認し、時間、リダイレクト、限定されたDNS証拠を取得します。インフラを変更する前に、「自分だけに起きているのか」を確認できます。
• Bulk HTTP Status Code Checker — 代表的なURLセットをテストし、完全なリダイレクト経路とレイテンシーを確認して結果をエクスポートします。単一ルートの障害と広範な502インシデントを切り分けるために使います。
• CDNまたはロードバランサーのダッシュボード — 失敗したレスポンスのリクエストIDと時刻をエッジログおよびプロバイダーのステータスと照合します。
• オリジンのアプリケーションとサーバーログ — 上流がリクエストを受け入れたか、応答を返したか、接続をリセットしたか、または不正な応答を返したかを確認します。これで層についての仮説を根本原因に変えられます。

502だけから失敗した層を特定できるツールはありません。公開エッジの証拠を、承認済みのオリジンへの直接リクエストと時刻付きログと比較してください。

自分で確認する：502 Bad Gateway

502とは何か、SEOにどう影響するかについての簡単な5問です。それぞれ回答を選んでから、答えを確認してください。

時間をかける価値のあるリソース

私の関連する記事

• HTTPステータスコードとSEOの包括ガイド — 502とその他の5xxファミリーがどこに位置し、各コードが検索エンジンに何を伝えるかを説明します。
• テクニカルSEO入門ガイド — サーバーの健全性とクロールが大きな全体像でどうつながるかを説明します。
• robots.txtとSEO：知っておくべきこと — robots.txtが5xxを返した場合は特別に扱われるため、関連する記事です。

業界からの情報

• HTTPステータスコードがGoogleのクローラーに与える影響 （Google Search Central）— 一次資料です。502 (bad gateway)を500／503とまとめ、クロールレートとインデックス登録に関する正確な文言を示しています。
• 計画停止への対処方法 （Google Search Central）— 503と502の違い、および意図的な停止に503を使う理由です。
• Cloudflare障害による5xx急増：SEOへの影響 （Matt G. Southern、Search Engine Journal）— Muellerのコメントを含む、2025年11月の障害の実例です。
• 502 Bad Gateway：MDNリファレンス （MDN Web Docs）— ステータスコードの中立的な仕様レベルの定義です。
• RFC 9110 §15.6.3 — 502（Bad Gateway） （IETF）— 基礎となるHTTP意味論の仕様です。
• 502 Bad Gatewayエラーの修正方法 （Kinsta）— ブラウザー／サイト所有者向けの修正を扱う、ホスト視点の詳細なトラブルシューティングです。
• 502 Bad Gatewayの意味と開発者向けの修正方法 （Webflow）— 開発者向けの原因と修正の概要です。

変更履歴