502 Bad Gateway とは？原因と解決方法

502 Bad Gateway エラーとは？

502 Bad Gateway は、あなたに応答しているサーバーがゲートウェイまたはプロキシとして動作しており、その背後のサーバーから不正な応答を受け取ったことを意味する HTTP ステータスコードです。HTTP の標準仕様（RFC 9110 の 15.6.3 節）もまさにそう定義しており、サーバーが「ゲートウェイまたはプロキシとして動作中に、リクエストを処理するためにアクセスしたインバウンドサーバーから不正な応答を受け取った」状態を指します。

現代のウェブサイトの多くは、少なくとも2つの層で構成されています。nginx、Apache、Cloudflare、クラウドのロードバランサーといったフロントサーバーがあなたの接続を受け付け、そのリクエストを PHP-FPM、Node.js アプリ、Python の Gunicorn、コンテナなどのアップストリームのアプリケーションに渡します。そのアップストリームが停止している、クラッシュした、あるいはプロキシが扱えない内容を返した場合、プロキシはあなたに渡せるものがないため 502 を返します。

重要なのは、ゲートウェイ自体は正常に動作しているという点です。ゲートウェイはリクエストを受け取り、応答を返しました。問題はその一段奥にあります。

502 エラーのさまざまな表示

ステータスコードはどこでも同じですが、表示されるページはどのプロキシが生成したかによって異なります：

どの表示であっても、フッターに書かれたプロキシの名前は有用な手がかりです。サイト管理者に、どの層を調べるべきかを教えてくれます。

502・500・503・504 の違いとは？

5xx 系のコードはどれも「サーバーの問題」を意味しますが、それぞれ異なる層を示しています：

簡単な覚え方：502 = アップストリームが接続を拒否した、接続を切った、または不正な応答を返した、504 = アップストリームが時間内に応答しなかった。関連するエラーは次のガイドで詳しく解説しています：500 Internal Server Error、503 Service Unavailable、504 Gateway Timeout。

502 Bad Gateway の原因

• アップストリームのアプリが動いていない。 PHP-FPM、Node、Gunicorn、またはコンテナがクラッシュした、デプロイ後に起動に失敗した、あるいは再起動中です。
• プロキシの転送先が間違っている。 proxy_pass や fastcgi_pass が、誤ったポート、アップグレード前の古い PHP ソケットパス、あるいは Docker コンテナ内の localhost を指しています。
• 一部のリクエストでアプリがクラッシュする。 特定のページがメモリ不足によるプロセスの強制終了や未処理の例外を引き起こし、応答する前に接続が閉じられます。
• すべてのワーカーが使用中。 PHP-FPM が pm.max_children に達し、新しいリクエストはソケットのキューで待たされます。大半はその後 504 でタイムアウトし、キューが満杯になると nginx は (11: Resource temporarily unavailable) をログに記録して 502 を返します。
• レスポンスヘッダーが大きすぎる。 大きな Cookie やサイズの大きいセキュリティヘッダーが、nginx の proxy_buffer_size からあふれています。
• ロードバランサー配下での keep-alive の不一致。 アプリがアイドル接続をロードバランサーの想定より早く閉じるため、ロードバランサーが閉じかけの接続にリクエストを送ってしまいます。
• ネットワーク変更後にプロキシがアップストリームへ到達できない。 プロキシを拒否するファイアウォールや、新しい IP に移ったアップストリームは 502（Connection refused、No route to host）になります。パケットを黙って破棄するファイアウォールは代わりに 504 になり、Cloudflare 配下ではこれらが 521 や 522 として表示されます。

訪問者として 502 エラーを解決する方法

他人のサーバーを修理することはできませんが、次の手順で問題が本当に相手側にあることを確認し、まれなローカル要因を取り除けます：

• 30〜60秒待ってから再読み込みする（Ctrl + R、Mac は Cmd + R）。多くの 502 は、デプロイや再起動が続く間だけのものです。
• 全員にとってダウンしているか確認する。 DNS Robot の 鯖落ちチェッカー は11か所からページを開き、HTTP ヘッダーチェッカー は当社のサーバーが受け取る正確なステータスコードを表示します。そちらでも 502 が出るなら、原因はあなたではなくサイトです。
• 強制再読み込みする。 Ctrl + Shift + R（Mac は Cmd + Shift + R）で行います。キャッシュされたエラーページが表示されているまれなケースに備えた手順です。
• DNS をフラッシュする。 サイトが最近ホストを移転した場合に、新しいサーバーへ到達できるようにします。各システムでの手順は DNS をフラッシュする方法 をご覧ください。
• VPN やプロキシをオフにする。 特に職場のネットワークでは、あなた自身のプロキシが失敗している「ゲートウェイ」である可能性があります。
• 別のブラウザや、モバイルデータ通信のスマートフォンで試す。 そこで表示されるなら、そのサイトの Cookie を削除してください。

自分のサーバーで 502 Bad Gateway を解決する方法

サーバー側から見ると、502 は比較的直しやすいエラーです。プロキシが通常、何が問題だったかをログに記録しているからです（ロードバランサーの keep-alive の競合と Cloudflare 自身の 502 は例外です）。次の3つのチェックを順に進めてください。4番目は実例です。

1. プロキシのエラーログを読む

502 を再現してから、プロキシのエラーログの末尾50行を読みます（コマンドは表の下にあります）。次の nginx メッセージは、それぞれ別の対処につながります：

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. アップストリームのアプリが動いているか確認する

# PHP-FPM（バージョンは環境に合わせて変更）
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# PM2 で動かしている Node.js
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # 再起動を繰り返しているコンテナを探す
docker logs --tail 50 <container>

# メモリの使いすぎで強制終了されていないか？
sudo dmesg -T | grep -i "killed process"

サービスが停止していたら起動し、停止した理由を突き止めます。失敗したデプロイ、新しいリリースの構文エラー、あるいは OOM キラー（メモリ不足によるプロセスの強制終了）などです。PHP-FPM のログに server reached pm.max_children setting とあれば、すべてのワーカーが使用中だったことを意味します。pm.max_children を上げるのはサーバーに十分な RAM がある場合だけにし、そうでなければワーカーを占有している遅いリクエストを探してください。

3. proxy_pass が正しいポートやソケットを指しているか確認する

nginx に指定された接続先と、実際に待ち受けているものを比較します：

# nginx はどこへプロキシしているか？
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# 実際に待ち受けているのは何か？
sudo ss -tlnp            # TCP ポートとそのプロセス
ls -l /run/php/          # PHP-FPM のソケットファイル

よくある不一致は2つあります。1つは、PHP をアップグレードした後、ソケットが php8.3-fpm.sock に変わったのに nginx が php8.1-fpm.sock を指したままになっているケースです。もう1つは Docker 内で、proxy_pass http://localhost:3000 がアプリではなく nginx コンテナ自身を指しているケースで、この場合は Compose のサービス名（http://app:3000）を使います。

4. 実例：dnsrobot.net で 502 が発生したケース

これは 2026年9月30日に私たち自身に起きたことです。新しいブログ記事をまとめて公開した後、そのうちのちょうど1本だけが nginx 1.24 経由で 502 Bad Gateway を返し、他のページはすべて正常でした。nginx の背後にある Next.js アプリにポート 3000 で直接リクエストすると、同じページが 200 OK で返ってきました。つまりアプリは正常で、失敗していたのはゲートウェイでした。

答えは nginx のエラーログの1行にありました：upstream sent too big header while reading response header from upstream。そのページのレスポンスヘッダーは 4,087 バイトあり、その大半は長い Content-Security-Policy ヘッダーと preload 用の Link ヘッダーでした。nginx はレスポンスの先頭部分（すべてのヘッダーを含む）を、proxy_buffer_size で設定されたバッファに読み込みます。この値の既定はメモリ1ページ分で、私たちのサーバーでは 4 KB でした。残りの余裕はわずか 9 バイトしかなく、ステータス行を含むヘッダー全体がバッファからあふれたのです。

修正は、アプリへプロキシしている location ブロックへの3行の追加でした。nginx -t を実行してリロードした後、そのページは 200 を返すようになりました：

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # 大きなヘッダー用の領域（以前は既定の 4k）
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

教訓：サイトの他の部分は正常なのに一部のページだけ 502 を返す場合は、アプリを疑う前に、そのページの大きなヘッダーや大きな Set-Cookie 値といったサイズの上限を探してください。

ロードバランサー配下の Node.js：ランダムに発生する 502

AWS Application Load Balancer などのロードバランサーの背後で Node.js を動かしていて、アプリのログにエラーがないのにときどき 502 が出る場合は、keep-alive のタイムアウトを確認してください。Node の HTTP サーバーは、アイドル状態の keep-alive 接続を既定で 5秒後に閉じます（server.keepAliveTimeout、Node.js 26 以前。Node 24.6 と 22.19 ではこれに 1 秒の keepAliveTimeoutBuffer が加わり、次のメジャーリリースでは既定値が 65 秒に引き上げられます）。一方、AWS ALB はアイドル接続を 60秒間開いたままにします。そのため、Node が接続を閉じるちょうどその瞬間にロードバランサーがその接続を再利用することがあり、そのリクエストは 502 として返ってきます。

解決策は、アプリのタイムアウトをロードバランサーより長くすることです：

const server = app.listen(3000)
// ロードバランサーのアイドルタイムアウトより長くする（ALB の既定値：60秒）
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // Node 18 より前でのみ必要。以降では設定しても問題なし

Cloudflare での 502 Bad Gateway

Cloudflare を利用している場合は、まず誰がエラーページを生成したかを確認します（Cloudflare の 502/504 ガイド）：

• Cloudflare のブランド入りページ（Browser ✓ / Cloudflare ✓ / Host ✗）：オリジンサーバー自身が Cloudflare に 502 または 504 を返しました。上記のサーバー側の手順でオリジンを修正してください。Cloudflare がオリジンにまったく接続できない場合は、502 ではなく 521 または 522 になります。
• 「502 Bad Gateway」とだけ表示され、その下に「cloudflare」と書かれたシンプルなページ： Cloudflare 自身が生成したものです。Cloudflare のドキュメントは2つの原因を挙げています。オリジンが壊れた gzip コンテンツ、または Content-Length が更新されていない gzip コンテンツを送っている場合（テストするにはオリジンで圧縮をオフにします）と、Cloudflare の1つのデータセンターへの突発的なトラフィック急増（自然に収まります）です。
• nginx や Apache の名前が表示されるページ： 多くの場合、リクエストが Cloudflare を経由せずにサーバーへ届いています。DNS レコードがプロキシされていない（グレーの雲）か、オリジンを直接見ている状態です（Cache Rule で「Origin error page pass-through」を有効にしている場合を除く）。
• ホストを移転しましたか？ Cloudflare の DNS でオリジンの A レコードを更新してください（オリジン IP の誤りは通常 521、522、523 として表示されます）。DNS Lookup がオリジンを表示するのは、グレーの雲（DNS only）のレコードだけです。プロキシされたレコードは Cloudflare 自身の IP で応答します。

502 エラーは SEO に悪影響がありますか？

短時間の障害なら影響はありません。Google のドキュメントによると、5xx のサーバーエラーが返されると、クローラーは一時的にクロールの速度を落とします。すでにインデックスに登録されているページは当面インデックスに残りますが、エラーが続くと、Google は最終的にそれらの URL をインデックスから削除します。

つまり、デプロイ中に数分続く 502 は無害です。一方、重要なページで何日も続く 502 や、何週間も断続的に発生する 502 は、クロールの減少や順位の低下につながる可能性があります。主要な URL を監視し、障害の後には Search Console のクロールの統計情報レポートを確認してください。