DevToolBox

502 Bad Gateway とは?原因と直し方

最終更新日: 2026-09-29公開日: 2026-07-26執筆: DevToolBox編集部

30秒で分かる答え / Quick answer

症状
ブラウザに 502 Bad Gateway が表示されてサイトが開けない
原因
nginx や Cloudflare などの中継サーバーが、後ろのアプリから正しい HTTP 応答を受け取れなかった(アプリ停止・メモリ不足・ポート違い・タイムアウト・TLS 不一致)
対処
訪問者は数分待って再読み込み(自分の端末の問題ではない)。運営者は後ろのアプリの稼働とログ → proxy_pass のポート → タイムアウト値の順に確認する

502 Bad Gatewayは、Webサイトの中継サーバーが、その先のサーバーから 正常な応答を得られなかったことを表すHTTPステータスです。訪問者と運営者では対処が異なります。

A 502 means the gateway could not obtain a valid response from its upstream. Visitors should retry later; operators should inspect the upstream service.

HTTP Status Codes

502の正式な意味や、503・504など他のHTTPステータスとの違いを検索できます。

今すぐ試す →

TL;DR

502 の原因を切り分け

いくつかの質問に答えるだけで、訪問者側か運営者側か、どこを見ればよいかが分かります。

ブラウザ内でのみ処理
あなたの立場
回答すると診断結果がここに表示されます。

1. 訪問者として見た場合の対処

まず、自分だけかサイト全体かを切り分けます。502は基本的にサイト側のエラーですが、 キャッシュやネットワーク経路により、自分の環境だけエラーを見続けることもあります。

確認結果次の行動
1回再読み込み直る一時障害。操作を続ける
別サイトを開く他も開かない端末や回線を確認
別回線・別端末同じ502サイト側の復旧を待つ
公式障害情報告知あり連続リロードせず待つ

リロード、別回線、キャッシュ削除の順で試す

数十秒から数分待って1回再読み込みします。改善しなければ別回線または別端末で確認し、 自分のブラウザだけなら対象サイトのキャッシュを削除します。決済直後は送信を連打しないでください。

502はウイルスではない

502が表示されたこと自体にウイルスの心配は不要です。これはサーバー間の通信状態です。 ただし、ソフトの導入やパスワード入力を求める不審なページは502とは別問題として閉じてください。

いつ治るかは運営者次第

アクセス集中なら数分で戻ることがありますが、クラッシュ、設定、証明書の問題は修正まで続きます。 訪問者には正確な復旧時刻は不明です。公式の障害情報を確認してください。

2. 502が返る仕組み

要求はクライアントからCDNやLB、リバースプロキシを経てアプリへ届きます。 中継役が上流へ接続できない、不正応答を受ける、応答途中で切断されると502を返します。

経路役割502との関係
ClientブラウザやAPI502を受け取る
CDN / LB配信・振り分けオリジン不正応答で502
Reverse Proxynginxなど接続拒否・切断で502
ApplicationNode、PHP、Java停止やOOMで応答不能

The path is client → CDN or load balancer → reverse proxy → application. The intermediary emits 502 when the upstream connection or response is unusable.

503はサービス自身が一時的に処理不能、504は上流の応答が期限内に届かない状態です。502・503・504の比較も参照してください。

図1: リクエスト経路のどこで502が発生するか
502が発生する経路上の位置Client、CDN/LB、リバースプロキシ、アプリケーションと続く経路のうち、リバースプロキシからアプリケーションへの接続が失敗または不正応答になった場合に、手前の中継役が502をクライアントへ返すことを示す図ClientCDN / LBリバースプロキシアプリケーションX接続失敗/不正応答/切断502 Bad Gateway として応答

3. 運営者向けの原因一覧

原因兆候確認
上流停止 / OOM全要求失敗ログ、OOM、メモリ
接続拒否connect() failedIP、ポート、ソケット
応答不正途中切断上流ログ、制限値
keep-alive不整合断続的上流側を長くする
TLS証明書更新後から失敗期限、SAN、SNI

中継と上流のログを同じ時刻・リクエストIDで突き合わせます。ECONNREFUSEDとETIMEDOUTを分けると、 待受不在か、通信経路・過負荷かを絞れます。

4. 環境別の切り分け

環境原因最初の確認
nginx上流停止、PHP-FPMソケットerror.logと待受
AWS ALBkeep-alive不整合ALBとターゲットログ
Docker未起動、ポート違い状態、ログ、接続
Kubernetes未Ready、targetPort違いPod、Endpoints、probe
WordPressプラグイン、PHPメモリPHPログ、直前の変更

nginx

connect() failedは待受先へ接続不能です。upstream prematurely closed connectionは 応答途中の切断で、クラッシュ、OOM、タイムアウトを疑います。PHP-FPMのソケットパスと権限も照合します。

connect() failed (111: Connection refused) while connecting to upstream
upstream prematurely closed connection while reading response header from upstream

AWS ALB

ターゲットのkeep-aliveがALBのidle timeoutより短いと、ターゲットが先に閉じた接続をALBが再利用して502になります。 ターゲットのkeep-aliveをALBより長くします。

Docker / Kubernetes

コンテナ未起動、内部ポート違い、ヘルスチェックを確認します。KubernetesではServiceのtargetPort、Endpoints、readiness probe、Ingressログを順に見ます。

WordPress

プラグインやテーマ更新、PHP-FPM停止、PHPメモリ不足を確認します。PHPログのfatal errorや memory exhaustedを確認してから問題の変更を修正します。

5. nginxの確認コマンドと設定例

sudo nginx -t
sudo systemctl status nginx
sudo systemctl status app
sudo tail -n 100 /var/log/nginx/error.log
ss -lntp
curl -i http://127.0.0.1:3000/health

直接のcurlが失敗すれば上流側、成功するのにnginx経由だけ失敗すればproxy_passやネットワークを確認します。

upstream app_backend {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_pass http://app_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

6. アンチパターン

再起動だけで原因を放置する

再起動で一時復旧しても、OOM、接続リーク、負荷、設定不整合は再発します。終了理由とログを保存し、根本原因を直します。

タイムアウトを無限に延長する

遅い要求が接続やワーカーを占有します。接続確立、応答待ち、keep-aliveを区別して失敗箇所だけを調整します。

7. よくある質問 / FAQ

502 Bad Gatewayは自分だけ?

別端末・別回線でも同じならサイト側の可能性が高いです。自分だけならキャッシュや回線を確認します。

アクセス集中で502になる?いつ治る?

上流がOOM、クラッシュ、接続上限超過を起こすと502になります。数分で戻る場合も、運営者の修正が必要な場合もあります。

502と504の違いは?

502は上流への接続不能または不正応答、504は上流の応答が制限時間内に完了しない状態です。

8. English summary

502 Bad Gateway means that a gateway, load balancer, CDN, or reverse proxy could not obtain a valid response from an upstream server. Visitors should retry later. The error itself is not evidence of a virus.

Operators should correlate proxy and application logs, then check the process, port, socket, OOM events, TLS, health checks, and keep-alive mismatch. Keep an ALB target's keep-alive timeout longer than the ALB idle timeout.

よくある質問 / FAQ

502 Bad Gatewayは自分だけ?
別端末・別回線でも同じサイトだけ502なら、サイト全体の障害である可能性が高いです。自分の端末だけなら再読み込み、別回線、キャッシュ削除を試します。
ウイルスの心配は?
502 Bad Gateway自体はウイルス感染を示しません。ゲートウェイと上流サーバー間の通信エラーなので、502だけを理由に感染を疑う必要はありません。
いつ治る?
一時的な過負荷なら数分で戻ることがありますが、プロセス停止や設定ミスは運営者が修正するまで続きます。正確な復旧時刻は運営者次第です。
What does 502 Bad Gateway mean?
It means a gateway or reverse proxy received an invalid response, or no usable response, from an upstream server.
nginxで502が出た時に最初に見る場所は?
nginxのerror.logと上流アプリのログを同じ時刻で確認します。connect() failedなら待受先、upstream prematurely closed connectionならクラッシュ、OOM、タイムアウトを調べます。
AWS ALBで502が出る定番の原因は?
ターゲットのkeep-aliveがALBのidle timeoutより短く、ターゲットが先に閉じた接続をALBが再利用するケースです。ターゲット側をALBより長く設定します。

参考資料 / References

関連ツール / Related tools

関連ガイド / Related guides