502エラー（Bad Gateway）とは？原因と対処法をわかりやすく解説

自社サイトにアクセスしたら、真っ白な画面に「502 Bad Gateway」とだけ表示されていた。問い合わせフォームを開こうとしたお客様から「エラーで見られません」と連絡が来た。広告を出稿している最中にランディングページが落ちていた——。こうした場面に出くわすと、原因がサーバーなのか、ブラウザなのか、それとも自分のパソコンなのかが分からず、どこから手をつけてよいか判断に迷います。

502エラーは、Webサイト運営で比較的よく遭遇するサーバー側のエラーです。多くは一時的なもので数分で復旧しますが、放置すれば機会損失や検索エンジンのクロールへの影響につながる可能性もあります。原因の切り分け方と、閲覧者・サイト管理者それぞれが取るべき手順を知っておけば、慌てずに対応できます。

この記事では、502エラー(502 Bad Gateway)の仕組みと他のHTTPステータスコードとの違い、主な発生原因、閲覧者向け・管理者向けの対処法、SEOやビジネスへの影響、そして再発を防ぐための予防策までを整理して解説します。

502エラー(502 Bad Gateway)とは
- エラーが発生する仕組み
- 500・503・504エラーとの違い
502エラーが起こる主な原因
【閲覧者向け】502エラーが表示されたときの対処法
【サイト管理者向け】502エラーの調査・対処手順
502エラーを放置するとどうなる？SEO・ビジネスへの影響
- 検索エンジンのクロール・インデックスへの影響
- ユーザー離脱・機会損失
502エラーを未然に防ぐための予防策
よくある質問
まとめ

502エラー(502 Bad Gateway)とは

502エラーとは、HTTPステータスコードのひとつで、ゲートウェイまたはプロキシとして動作しているサーバーが、上流(オリジン)のサーバーから無効な応答を受け取ったことを示すサーバーエラーです。「Bad Gateway」という英語表記のとおり、「間に立っているサーバーが、その先から受け取った返事をうまく解釈できなかった」状態を表しています。

MDN Web Docsの定義では、502は500 Internal Server Errorと同じく「サーバー側で何かが起きた」ことを示す包括的なエラーですが、リクエストの経路のどの地点で問題が起きたかが特定されている点が異なります。つまり、エラーを返しているのは手前のプロキシやロードバランサーであり、実際に不調なのはその奥にあるアプリケーションサーバーやデータベース側であるケースがほとんどです。

ブラウザ上では、環境によって以下のようにさまざまな文言で表示されます。表示テキストが違っても、意味するところは同じです。

表示例	主に見られる環境
502 Bad Gateway	汎用(Nginx / Apacheなど)
Error 502	CDN・プロキシ経由
HTTP Error 502 – Bad Gateway	Windows系サーバー / ブラウザ
502 Server Error / 502 Service Temporarily Overloaded	一部のクラウドサービス
Bad Gateway: The proxy server received an invalid response	リバースプロキシ環境

エラーが発生する仕組み

現代のWebサイトは、ブラウザとアプリケーションサーバーが1対1で直結しているわけではありません。実際には、次のように複数の層を経由して通信が行われています。

閲覧者のブラウザ
　↓
CDN・WAF(Cloudflare、CloudFrontなど)
　↓
ロードバランサー / リバースプロキシ(Nginx、ALB、Application Gatewayなど)
　↓
Webサーバー・アプリケーションサーバー(PHP-FPM、Node.js、Javaなど)
　↓
データベース・外部API

このうち、真ん中に位置する「ゲートウェイ役」のサーバーが、後段のサーバーにリクエストを転送したときに、応答が返ってこない、途中で接続が切れた、あるいは形式が壊れた応答が返ってきた場合に502を返します。

たとえばNginxをリバースプロキシとして使い、その裏でPHP-FPMを動かしている一般的な構成では、PHP-FPMのプロセスが落ちている、ワーカー数が枯渇している、応答ヘッダーがバッファサイズを超えている、といった状況で502が発生します。Nginxのエラーログに「upstream sent too big header while reading response header from upstream」といったメッセージが記録されるのは、この典型例です。

重要なのは、502は「閲覧者のパソコンやブラウザが壊れている」ことを意味しないという点です。原因の所在はサーバー側、より正確にはサーバー間の連携部分にあります。

500・503・504エラーとの違い

500番台のステータスコードは、いずれもサーバー側の問題を示します。ただし、示している状況はそれぞれ異なります。違いを理解しておくと、エラー画面を見た瞬間に「どこを疑うべきか」の当たりをつけられます。

コード	名称	意味	主に疑うべき箇所
500	Internal Server Error	サーバー内部で予期しないエラーが発生した	アプリケーションのプログラム、設定ファイル
502	Bad Gateway	ゲートウェイ／プロキシが上流から無効な応答を受け取った	上流サーバーのダウン、プロセス異常、接続設定
503	Service Unavailable	サーバーが一時的に利用できない(過負荷・メンテナンス)	サーバーの処理能力、メンテナンス設定
504	Gateway Timeout	ゲートウェイ／プロキシが上流から時間内に応答を得られなかった	処理時間の長いプログラム、タイムアウト設定

覚え方としては、500は「アプリ自体の不具合」、503は「キャパシティの問題」、502と504は「サーバー間の通信経路の問題」と整理すると分かりやすくなります。502と504はよく似ていますが、502は「壊れた応答が返ってきた」、504は「応答が何も返ってこなかった」という違いがあります。MDNの解説でも、プロキシがオリジンからHTTP応答をまったく受け取れなかった場合は502ではなく504を返す、と説明されています。

502エラーが起こる主な原因

502エラーの原因はひとつではありません。実務でよく見られるものを、発生頻度の高い順に整理します。

アクセス集中によるサーバー負荷

テレビ番組やSNSでの紹介、大型キャンペーンの開始、メルマガの一斉配信直後など、短時間にトラフィックが集中すると、サーバーの処理能力を超えたリクエストが発生します。PHP-FPMのワーカープロセスがすべて使い切られると、新しいリクエストは処理を待つのではなく即座に502として返されることがあります。

BtoBサイトでも、展示会やウェビナー開催直後、プレスリリース配信直後にアクセスが急増して502が出るケースは珍しくありません。「アクセス集中は502の原因になるか」という疑問への答えは、なり得るです。ただし後述するように、原因はそれだけではありません。

サーバーの一時的な不具合・メンテナンス

レンタルサーバーやクラウド基盤側の障害、計画メンテナンス、プロセスの再起動中などでも502は発生します。この場合、自社では何も変更していないのにエラーが出るため、まずは契約しているホスティング事業者やクラウドベンダーの障害情報ページを確認するのが近道です。

また、アプリケーションのデプロイ(更新作業)中に、旧プロセスが停止して新プロセスが立ち上がるまでの数秒間だけ502が返る、という現象もよく見られます。

プロセス・アプリケーションのクラッシュ

上流のアプリケーションプロセス自体が異常終了しているケースです。メモリ不足(OOM)による強制終了、無限ループ、外部APIやデータベースへの接続失敗などが引き金になります。Apacheのリバースプロキシ構成では「proxy: error reading status line from remote server」といったログが残ることがあり、バックエンドが接続を切ったタイミングとプロキシの送信タイミングが競合して発生する場合もあります。

DNS設定やドメイン・IPアドレスの変更

サーバー移転やドメイン移管の直後、DNSの設定が正しく反映されていないと、プロキシが正しいIPアドレスに接続できず502が発生します。DNSの変更は世界中のキャッシュに反映されるまで時間がかかるため、切り替え直後の数時間から数十時間は不安定になることがあります。

AWS CloudFrontの公式ドキュメントでも、502の原因としてオリジンへのDNS解決の問題やSSL/TLSのネゴシエーション失敗(暗号スイートやプロトコルバージョンの不一致、証明書の不備)が挙げられています。

ファイアウォール・セキュリティ設定の問題

WAF(Web Application Firewall)やファイアウォール、ネットワークのアクセス制御が、本来通すべき通信をブロックしてしまうと502につながります。Azure Application Gatewayの公式トラブルシューティング情報では、ネットワークセキュリティグループ(NSG)やユーザー定義ルート(UDR)、カスタムDNSがバックエンドへの到達を妨げると、ヘルスプローブが失敗して502が返る、と説明されています。

同様に、ヘルスチェックの設定ミスも代表的な原因です。ヘルスプローブが正常とみなすのは通常HTTPステータス200〜399の範囲であるため、チェック先のパスがリダイレクトや認証で別のコードを返す設定になっていると、正常なサーバーが「異常」と判定されてしまいます。

閲覧者側でも、セキュリティソフトやVPN、企業ネットワークのプロキシが通信を遮断して502が表示される場合があります。

WordPressのプラグインや設定ミス

WordPressで運用しているサイトでは、以下が典型的な原因になります。

プラグイン同士の競合：更新直後に502が出た場合、まず疑うべき箇所
PHPメモリ上限の不足：重い処理を行うプラグインがメモリを使い切りプロセスが停止する
テーマやfunctions.phpの記述ミス：処理が終わらず応答が壊れる
キャッシュ系・セキュリティ系プラグインの設定：CDNやWAFとの二重構成で衝突する

WordPressはPHP-FPM上で動作していることが多く、ワーカーが枯渇したりプロセスがクラッシュしたりすると、そのまま502として表面化します。PHPのメモリ上限を256M程度まで引き上げることで解消する例も報告されています。

ネットワーク・プロキシ側の問題

企業内ネットワークのプロキシサーバー、ISP側の一時的な障害、CDNとオリジンサーバーの間の通信不良なども502の原因になります。Cloudflareのようなプロキシ型CDNを使っている場合、オリジンサーバーが応答しない、負荷が高すぎる、圧縮の扱いに不整合がある(gzip圧縮したのにContent-Lengthヘッダーが更新されていないなど)といったケースで502が返ります。

【閲覧者向け】502エラーが表示されたときの対処法

自分が閲覧している側で502が出た場合、原因の大半は相手側のサーバーにあるため、こちらでできることは限られます。それでも、次の手順を試す価値はあります。

ページの再読み込み・時間を置く

502の多くは一時的なものです。まずはブラウザの再読み込み(Windowsは「F5」または「Ctrl + F5」、Macは「Command + R」)を試します。それでも改善しない場合は、5分から30分ほど時間を置いてから再度アクセスしてみましょう。サーバーの再起動や負荷の緩和により、自然に復旧することがよくあります。

ブラウザのキャッシュ・Cookieを削除する

古いキャッシュやCookieが残っていると、エラー画面が保存されたまま表示され続けることがあります。ブラウザの設定からキャッシュとCookieを削除し、再度アクセスします。手軽な確認方法として、シークレットモード(プライベートウィンドウ)で開いてみるのも有効です。ここで正常に表示されるなら、キャッシュが原因だった可能性が高いといえます。

別のブラウザ・端末やネットワークで確認する

「自分だけに502が表示されているのか、全員に表示されているのか」を切り分けることは重要です。

別のブラウザ(ChromeとFirefoxなど)で開く
別の端末(スマートフォンなど)で開く
別のネットワーク(Wi-Fiからモバイル回線に切り替える)で開く

自分だけに表示される場合は、ブラウザ拡張機能、セキュリティソフト、VPN、社内プロキシ、DNSキャッシュなど、手元の環境が関与している可能性があります。VPNや広告ブロッカーを一時的に無効にして確認するとよいでしょう。全員に表示される場合は、サイト側の問題です。

【サイト管理者向け】502エラーの調査・対処手順

自社サイトで502が発生した場合は、次の順序で切り分けを進めると効率的です。

直近の変更履歴(プラグイン更新・設定変更等)を確認する

「いつから発生しているか」と「その直前に何をしたか」を照合します。プラグインやテーマの更新、コードのデプロイ、サーバー設定の変更、DNSレコードの変更、WAFルールの追加——これらの直後にエラーが始まったのであれば、その変更が原因である可能性が高くなります。原因が特定できるまでは、直前の変更を一時的に元に戻す(ロールバックする)ことが最も早い復旧手段になります。

サーバーの稼働状況・エラーログを確認する

次に、サーバー側のログを確認します。502の原因究明では、ログが唯一の確かな手がかりです。

確認対象	見るべきポイント
Webサーバーのエラーログ(Nginx / Apache)	upstream関連のエラーメッセージ、接続拒否、タイムアウト
アプリケーションログ(PHP-FPM等)	プロセスのクラッシュ、メモリ不足、致命的エラー
リソース使用状況	CPU使用率、メモリ使用量、ディスク容量、同時接続数
アクセスログ	502が返っている時間帯とリクエスト数の相関
ホスティング事業者の障害情報	基盤側の障害・メンテナンスの有無

AWSのApplication Load Balancerを使っている場合は、アクセスログをelb_status_code = "502"で絞り込み、target_status_codeと合わせて確認することで、ターゲット側で何が起きていたかを判断できます。Azure Application Gatewayでは、ポータルの「バックエンドの正常性(Backend health)」で異常なインスタンスの有無を確認するのが第一歩です。

CDN・WAFの設定を確認する

CDNやWAFを経由している場合は、CDNを一時的にバイパスして(オリジンのIPやテスト用ホスト名で直接アクセスして)、オリジン単体では正常に応答するかを確認します。オリジンが正常なら、原因はCDN／WAF側の設定にあると判断できます。SSL/TLS設定の不一致、オリジン証明書の期限切れ、タイムアウト値の設定、WAFルールによる過剰なブロックなどが典型的なチェックポイントです。

DNS設定を確認する

サーバー移転やIPアドレス変更を行っていた場合は、DNSレコード(Aレコード、CNAMEレコード)が正しい向き先になっているかを確認します。digやnslookupといったコマンド、あるいはオンラインのDNSチェックツールで、実際に返っているIPアドレスを確かめます。TTLの設定によっては反映に時間がかかるため、変更直後は反映待ちの可能性も考慮します。

タイムアウト・バッファ設定を見直す

ログに「upstream timed out」「upstream sent too big header」といったメッセージが出ている場合は、Nginx側のfastcgi_read_timeoutやfastcgi_buffer_sizeなどの設定値がボトルネックになっています。バックエンドの処理時間やレスポンスヘッダーのサイズに合わせて、これらの値を適切に引き上げることで解消することがあります。ただし、値を大きくするのは対症療法であり、根本的には処理そのものの重さを見直す必要があります。

502エラーを放置するとどうなる？SEO・ビジネスへの影響

502は「そのうち直るだろう」と軽視されがちですが、頻発や長時間の継続は無視できない影響を及ぼします。

検索エンジンのクロール・インデックスへの影響

Googlebotが5xx系のエラーに繰り返し遭遇すると、サーバーに負荷をかけないようクロール頻度を落とすと説明されています。短時間の障害であれば、キャッシュされた情報が保持され、順位への影響はほとんどないと考えられています。しかし、エラーが数日単位で続くと、該当ページがインデックスから外れたり、順位が下がったりする可能性があると言われています。

また、クロールバジェット(Googleがサイトに割り当てるクロールの量)が、失敗するリクエストに費やされてしまうため、新しく公開したページの発見が遅れるという副次的な影響も考えられます。Google Search Consoleの「ページ」レポートに「サーバーエラー(5xx)」が継続的に計上されている場合は、早めの対応が望ましいでしょう。

ユーザー離脱・機会損失

BtoBサイトにおける502の実質的なダメージは、SEOよりもむしろ機会損失です。

問い合わせフォームや資料請求ページが開けず、リードを取り逃す
広告からの流入がエラー画面に着地し、広告費が無駄になる
商談前に企業サイトを確認した見込み顧客に、管理体制への不安を与える
既存顧客向けの会員サイトやツールが使えず、サポート問い合わせが増える

特に、リスティング広告やSNS広告を運用中にランディングページが502になると、クリック課金は発生しているのにコンバージョンはゼロという状態になります。監視の仕組みを持たずに一晩気づかなかった、という事態は避けたいところです。

502エラーを未然に防ぐための予防策

完全にゼロにすることは難しいものの、発生頻度と影響時間は運用の工夫で大きく減らせます。

サーバースペック・契約プランの見直し

慢性的に負荷が高い状態であれば、根本的にリソースが足りていません。CPU・メモリの使用率を定期的に確認し、ピーク時に余裕がない場合は上位プランへの変更や、共用サーバーからVPS・クラウドへの移行を検討します。キャンペーンやウェビナーなど、アクセス増が予測できるイベントの前には、事前にスケールアップしておくのが定石です。

監視・アラート体制の整備

502が起きたこと自体よりも、「気づくのが遅れること」のほうが損害を生みます。外形監視(外部から定期的にURLへアクセスして応答を確認する仕組み)を導入し、5xxエラーを検知したらメールやチャットツールへ通知が飛ぶようにしておきます。監視間隔は1分から5分程度が一般的です。あわせて、サーバーのCPU・メモリ・プロセス数にも閾値アラートを設定しておくと、障害の予兆を捉えられます。

CDN・WAF・ロードバランサーの活用

CDNを導入して静的ファイルを配信させれば、オリジンサーバーの負荷を大きく減らせます。ロードバランサーで複数台構成にしておけば、1台が不調でも他のサーバーがリクエストを引き受けられます。オートスケーリングを設定しておけば、アクセス急増に自動で追随できます。

ただし、これらの中間層は正しく設定されて初めて機能します。ヘルスチェックのパスとタイムアウト値、CDNとオリジンのタイムアウトの整合性は、導入時に必ず確認しておきましょう。

プラグイン・ソースコードの定期点検

WordPressサイトでは、次の運用ルールを決めておくと事故が減ります。

項目	推奨する運用
プラグインの数	使っていないものは停止ではなく削除する
更新作業	本番環境に直接適用せず、ステージング環境で検証してから反映する
バックアップ	更新前に自動バックアップを取得し、すぐ戻せる状態にする
PHPバージョン	サポート対象のバージョンを維持し、メモリ上限も適正値に設定する
重い処理	大量データの集計やバッチ処理は、Webリクエスト内で完結させずキューや非同期処理に逃がす

よくある質問

502エラーはウイルスが原因ですか？

502エラー自体は、ウイルス感染やサイバー攻撃を直接示すものではありません。サーバー間の通信が正常に完結しなかったことを示すHTTPステータスコードであり、閲覧しただけで端末が危険にさらされるものでもありません。

ただし、セキュリティソフトやVPN、ファイアウォールの設定が原因で通信が遮断され、結果として502が表示されることはあります。また、DDoS攻撃による過負荷が502の引き金になる可能性はゼロではないため、頻発する場合はアクセスログでの確認をおすすめします。

502エラーと503エラーの違いは何ですか？

502は「間に立つゲートウェイやプロキシが、その先のサーバーから無効な応答を受け取った」状態、503は「サーバー自体が一時的に利用できない(過負荷やメンテナンス)」状態を指します。503はメンテナンス時に意図的に返すこともある一方、502は基本的に想定外の異常です。ユーザーから見ればどちらも「サイトが見られない」ですが、調査すべき箇所が異なります。

自分だけに502エラーが表示される場合の原因は？

他の端末やネットワークからは正常に見えるのに自分だけエラーになる場合は、ブラウザのキャッシュ・Cookie、ブラウザ拡張機能、セキュリティソフトやVPN、社内プロキシ、DNSキャッシュなどが関係している可能性があります。シークレットモード、別ブラウザ、モバイル回線での確認、DNSキャッシュのクリアといった手順で切り分けられます。

502エラーはどれくらいで直りますか？

原因によって異なります。プロセスの一時的な不調や再起動が原因なら数分で復旧することが多く、アクセス集中であれば負荷が落ち着けば自然に解消します。一方、DNS設定の誤りやプログラムの不具合が原因の場合は、修正しない限り復旧しません。10分から30分待っても改善しないなら、一時的な現象ではなく設定・実装側の問題を疑うべき段階です。

502エラーが出ているかどうかを常時把握する方法はありますか？

外形監視ツールを使えば、外部から定期的にURLへアクセスし、5xxエラーを検知した時点で通知を受け取れます。あわせてGoogle Search Consoleの「ページ」レポートで「サーバーエラー(5xx)」の推移を確認すれば、検索エンジン側から見たエラーの発生状況も把握できます。

まとめ

502エラー(502 Bad Gateway)は、ゲートウェイやプロキシとして動作するサーバーが、上流のサーバーから無効な応答を受け取ったときに返されるHTTPステータスコードです。原因はサーバー側、特にサーバー間の通信部分にあり、閲覧者の端末が壊れているわけではありません。

500は「アプリケーション内部の不具合」、503は「一時的な利用不可・過負荷」、504は「上流からの応答が時間内に返らない」を示し、502は「壊れた応答が返ってきた」状態を表します。この違いを押さえておくと、原因の当たりをつけやすくなります。

主な原因は、アクセス集中による負荷、サーバーやプロセスの一時的な不具合、DNS設定やIPアドレスの変更、ファイアウォール・WAFやヘルスチェックの設定ミス、WordPressのプラグイン競合やPHPのメモリ不足、そしてCDNやプロキシ経由の通信トラブルなどです。

閲覧者側の対処は、再読み込み、時間を置く、キャッシュとCookieの削除、別ブラウザ・別端末・別ネットワークでの確認が基本です。サイト管理者側は、直近の変更履歴の確認、サーバーのエラーログとリソース状況の確認、CDN・WAFのバイパス検証、DNS設定の確認、タイムアウトやバッファ設定の見直しという順で切り分けを進めます。

502を長時間放置すると、検索エンジンのクロール頻度が下がり、継続すればインデックスや順位に影響が及ぶ可能性があるほか、問い合わせの取りこぼしや広告費の無駄といった機会損失が生じます。サーバースペックの見直し、外形監視とアラートの整備、CDN・ロードバランサーの活用、プラグインとコードの定期点検を組み合わせ、発生頻度と気づくまでの時間を減らしていくことが、安定したサイト運用につながります。