ステータスコード502とは？意味や原因は？（Bad Gateway：サーバーエラー：対処法など）

Webサイトを開いた際に「502 Bad Gateway」と表示され、目的のページが見られなくなることがあります。

この表示は利用者の操作ミスとは限らず、Webサーバーやアプリケーション、通信経路など複数の要素が関係するサーバーエラーです。

突然の表示に慌てやすいものの、閲覧者とサイト運営者では確認する場所も対処法も異なります。

この記事では、502エラーの意味、発生原因、切り分けの進め方、再発を抑える運用までを分かりやすく整理します。

ステータスコード502の意味と結論

それではまずステータスコード502の意味と、最初に取るべき行動について解説していきます。

Bad Gatewayが示す通信の状態

ステータスコード502は、正式にはBad Gatewayと呼ばれるHTTPステータスコードです。

ブラウザなどから受けた要求を中継するサーバーが、奥にあるサーバーから正常な応答を受け取れなかった場合に返されます。

たとえば、利用者のブラウザがCDNやロードバランサーへアクセスし、その先のWebサーバーやアプリケーションサーバーへ接続する構成を考えてみましょう。

中継役のサーバーが不正な応答、途中で切れた応答、想定外の形式の応答を受信すると、利用者には502エラー画面が表示されることがあります。

つまり、502はページの存在そのものが必ず失われたことを示す表示ではありません。

多くの場合はサーバー間の通信不良や一時的な負荷増加が関係しています。

利用者と運営者で異なる優先対応

サイトを閲覧している立場なら、まずページを再読み込みし、少し時間を置いてから再度アクセスする方法が基本です。

一時的な混雑やサーバーの再起動中であれば、それだけで解消する場合があります。

何度試しても同じページだけが見られない場合は、ブラウザのキャッシュ削除、別ブラウザでの確認、別回線での接続も有効でしょう。

一方、サイト運営者は単純な再読み込みだけで終えず、監視画面、サーバーログ、CDNの障害情報、直近の設定変更を確認する必要があります。

アクセス集中が原因なのか、PHPやNode.jsなどのアプリケーション停止なのかで、必要な復旧作業は変わります。

502とほかのHTTPエラーの違い

HTTPステータスコードには、エラーの種類を示す番号があります。

502は5xx系に分類され、利用者側よりもサービス提供側の処理に原因がある可能性が高い番号です。

コード	主な意味	確認の中心
404	指定されたページが見つからない状態	URLや公開設定
500	サーバー内部で想定外のエラーが発生した状態	アプリケーションや設定
502	中継サーバーが先のサーバーから正常応答を得られない状態	プロキシと接続先の連携
503	サービスが一時的に利用できない状態	メンテナンスや負荷
504	接続先からの応答待ちが時間切れになった状態	処理時間や通信遅延

502と504は混同されやすいものの、502は応答内容の異常、504は応答待ちの制限時間超過として扱われることが一般的です。

ステータスコード502が発生する仕組み

続いては、502エラーがどのような経路で起こるのかを確認していきます。

リバースプロキシとバックエンドの関係

現在のWebサイトでは、Webサーバーの前段にリバースプロキシを置く構成が広く使われています。

リバースプロキシは外部からのアクセスを受け、内部のWebサーバーやアプリケーションへ振り分ける役割を持ちます。

Nginx、Apache、CDN、ロードバランサーなどが前段に配置されるケースも珍しくありません。

前段サーバーがバックエンドへ接続したとき、接続拒否、異常終了、壊れたヘッダー、TLS設定の不整合などを検知すると502になることがあります。

表示画面にNginxやCloudflareなどの名称が出る場合は、どの中継地点がエラーを返したかを知る手掛かりになります。

正常な応答が届かなくなる要因

バックエンドが動いていても、必ずしも正常な応答が返るとは限りません。

アプリケーションのプロセス数不足、メモリ不足、データベース接続の枯渇、外部APIの停止などが重なると、応答が途中で失敗する可能性があります。

特にアクセスが急増した場面では、処理待ちが増え、Webサーバーとアプリケーションサーバーの間の接続が不安定になりがちです。

WordPressでは、重いプラグイン、遅いデータベース検索、外部サービスへの問い合わせが同時に走ることも負荷要因になります。

アクセスが多い時間帯だけ発生するかを確認すると、容量や性能が原因かどうかを判断しやすくなります。

CDNとDNSが関係するケース

CDNは画像やHTMLなどの配信を高速化し、アクセス集中の負担を分散する便利な仕組みです。

ただし、CDNとオリジンサーバーの接続先設定が間違っていたり、オリジン側のファイアウォールがCDNからの通信を拒否していたりすると502の原因になります。

DNSの切り替え直後も注意が必要です。

古いIPアドレスを参照している利用者と新しいIPアドレスを参照している利用者が混在し、限られた環境だけで障害が起こることがあります。

証明書の更新、サーバー移転、CDN導入の直後に502が増えた場合は、通信経路の設定変更を優先して見直すとよいでしょう。

ステータスコード502の主な原因

続いては、実務で多く見られる原因を確認していきます。

サーバー高負荷とリソース不足

CPU使用率、メモリ使用量、ディスクI/O、同時接続数の上昇は、502エラーにつながる代表的な要因です。

共有サーバーでは、契約プランの上限に近づいたときに処理が遅くなる場合があります。

VPSやクラウド環境では、インスタンスの性能不足、オートスケール設定不足、コンテナのメモリ制限なども確認対象です。

一時的なアクセス増加であれば、キャッシュの活用やCDN配信で改善することがあります。

恒常的な負荷なら、サーバースペックの見直しやアプリケーションの最適化が必要です。

アプリケーションとPHPの異常

PHP-FPM、Node.js、Java、Pythonなどのアプリケーションプロセスが停止すると、Webサーバーは処理を渡せなくなります。

WordPressでは、PHPのメモリ上限不足、テーマの不具合、プラグイン同士の競合、更新後の互換性問題が引き金になることがあります。

エラーログにプロセス終了、メモリ不足、接続失敗、fatal errorなどが記録されていないかを確かめましょう。

直前にプラグインやテーマを更新した場合は、変更前の状態との差分を確認することも大切です。

ただし、原因が特定できないまま複数の設定を同時に変えると、復旧後の検証が難しくなります。

変更は一つずつ行い、再現の有無を記録する運用が安全です。

ネットワークとセキュリティ設定の不整合

サーバー自体が稼働していても、ネットワーク設定によって通信が遮断される場合があります。

ファイアウォール、WAF、アクセス制限、IP許可リスト、ポート設定、SSL証明書の構成などが主な確認項目です。

ロードバランサーからバックエンドへの通信だけが遮断されると、外部からは502として見えることがあります。

また、セキュリティ対策で特定のリクエストを拒否した結果、意図せず正規利用者の通信まで止まるケースもあります。

設定を緩める前に、どのIP、どのURL、どの時刻で拒否されたのかをログから確認する姿勢が欠かせません。

閲覧者ができるステータスコード502の対処法

続いては、サイトを利用する側が試せる対処法を確認していきます。

再読み込みと時間を置いた再試行

最初に試したいのは、ページの再読み込みです。

一時的な通信失敗や短時間のサーバー負荷であれば、数分後の再試行で正常に表示されることがあります。

何度も連続で更新するより、少し間隔を空けたほうがサイトへの負荷を増やしにくいでしょう。

急いで確認したいページなら、検索結果のキャッシュ、公式SNS、障害告知ページなどで状況を確認する方法もあります。

多くの利用者が同時に見られない状態なら、サイト側の復旧を待つことが基本になります。

ブラウザと回線の切り分け

特定の端末だけで502が表示される場合は、ブラウザのキャッシュやCookieが影響している可能性があります。

シークレットウィンドウで開く、別のブラウザで試す、キャッシュを削除するといった操作を行いましょう。

自宅のWi-Fiとモバイル通信を切り替えて確認する方法も、通信環境の切り分けに役立ちます。

確認方法	分かること	次の対応
再読み込み	一時的な障害かどうか	時間を置いて再試行
別ブラウザ	拡張機能やキャッシュの影響	キャッシュ削除や設定確認
別回線	社内回線やプロバイダーの影響	ネットワーク管理者へ相談
別端末	端末固有の問題かどうか	端末設定を見直す

ただし、複数端末と複数回線で同じエラーが出るなら、利用者側で解決できる範囲は限られます。

運営者への連絡時に伝える情報

問い合わせる場合は、単に見られないと伝えるよりも、状況を具体的に共有したほうが復旧につながります。

表示されたURL、発生日時、使ったブラウザ、端末、画面に出たメッセージを伝えるとよいでしょう。

スクリーンショットが取れる場合は添付すると、エラー画面の提供元や表示内容を確認しやすくなります。

パスワード、決済情報、個人情報を画面に含めたまま共有しない点には注意が必要です。

サイト運営者の調査と復旧手順

続いては、運営者が502エラーを切り分ける手順を確認していきます。

障害範囲と発生時刻の把握

最初に、すべてのページで起きているのか、一部URLだけなのかを確認します。

管理画面、API、画像配信、特定の検索ページなど、影響範囲によって疑うべき場所が変わるためです。

監視ツールやアクセスログで、最初に増えた時刻とアクセス数の変化を確認しましょう。

デプロイ、プラグイン更新、DNS変更、証明書更新、サーバー再起動など、同時刻付近の作業履歴も重要な情報です。

障害の開始時刻が明確になるほど、ログの確認範囲を絞り込めます。

ログと稼働状況の確認

Webサーバーのエラーログ、アクセスログ、アプリケーションログ、データベースログを時刻順に確認します。

Nginxならupstream関連の記録、Apacheならproxy関連の記録、PHP-FPMならワーカープロセスの停止や上限到達の記録が手掛かりになります。

サーバー監視では、CPU、メモリ、ディスク容量、ネットワーク、プロセス数、レスポンス時間を確認してください。

ログに出ているエラー文だけで即断せず、前後のイベントも見ることが大切です。

最初に起きた異常と、その後に連鎖したエラーを分けると、根本原因を見失いにくくなります。

設定変更と段階的な復旧

原因候補が絞れたら、影響を小さく抑えながら復旧を進めます。

たとえばアプリケーションの停止ならプロセスの再起動、設定不整合なら設定修正、負荷過多ならキャッシュ有効化やリソース増強が候補になります。

WordPressで特定プラグインが疑わしい場合は、可能であれば検証環境で停止時の挙動を確認します。

本番環境で作業する場合も、バックアップやロールバック手段を準備したうえで実施することが必要です。

復旧後はトップページだけでなく、フォーム送信、ログイン、検索、APIなど重要な機能も確認しましょう。

HTTPステータスが200に戻っただけでは、すべての機能が正常とは限りません。

ステータスコード502を防ぐ運用とまとめ

最後に、ステータスコード502を防ぐ運用と要点をまとめます。

502 Bad Gatewayは、中継サーバーが接続先から正常な応答を得られないときに発生するサーバーエラーです。

閲覧者は再読み込み、時間を置いた再試行、別ブラウザや別回線での確認を行い、それでも改善しない場合はサイト側の復旧を待つ流れになります。

運営者は、影響範囲、発生時刻、直近の変更、サーバー負荷、各種ログを順に確認することが重要です。

原因としては、サーバー高負荷、アプリケーション停止、PHP-FPMの不調、CDN設定、DNS、ファイアウォール、証明書設定などが考えられます。

障害を減らすには、死活監視と性能監視を整え、アラートを受け取れる状態にしておくことが有効です。

さらに、キャッシュの活用、CDNの適切な設定、負荷試験、バックアップ、更新前の検証環境を用意すると、突発的なトラブルに強くなります。

原因を段階的に切り分けることが、短い復旧時間と安定したサイト運営につながります。