Nginxで502 Bad Gatewayが出たときの原因と解決方法｜確認する順番を解説
Webサイトを開こうとしたときに、突然
502 Bad Gateway
と表示されることがあります。
NginxをWebサーバーやリバースプロキシとして利用している環境では、比較的よく遭遇するエラーの一つです。
ただし、502が表示されたからといって、Nginxそのものが壊れているとは限りません。
Nginxの先にあるアプリケーションやPHP-FPM、別のWebサーバーなどから正常な応答を受け取れない場合にも502が発生します。
そのため、Nginxの設定だけを何度も変更するのではなく、
Nginx → 接続先 → サービス → ポート → ログ
という順番で原因を切り分けることが重要です。
502 Bad Gatewayとは？
502 Bad Gatewayは、ゲートウェイやプロキシとして動作しているサーバーが、上流のサーバーから正常な応答を受け取れなかったときなどに返されるHTTPステータスコードです。
Nginxをリバースプロキシとして使っている場合、イメージとしては次のようになります。
ブラウザ
↓
Nginx
↓
アプリケーション
ブラウザからNginxへのアクセス自体は成功していても、Nginxから後ろのアプリケーションに接続できなければ、502が返されることがあります。
つまり、
「Nginxには到達しているが、その先との通信に問題がある」
というケースをまず考えると分かりやすいでしょう。
最初にNginxが動いているか確認する
まず、Nginxのサービス状態を確認します。
systemdを利用しているLinux環境では、次のコマンドが使えます。
sudo systemctl status nginx
ここでNginxが停止している場合は、当然ながらWebサイトも正常に処理できません。
ただし、502が表示されている場合は、Nginx自体は動作しているケースも多くあります。
そのため、
Nginxが動いている＝問題なし
とは考えず、次にNginxがどこへ通信しようとしているのかを確認します。
Nginxの設定でupstreamを確認する
502の原因を調べるうえで重要なのがupstreamです。
たとえば、Nginxの設定に次のような記述があるとします。
location / {
proxy_pass http://127.0.0.1:3000;
}
この場合、Nginxは受け取ったリクエストを127.0.0.1:3000へ転送します。
もし3000番ポートでアプリケーションが動いていなければ、Nginxは接続先から正常な応答を受け取れません。
その結果、502が表示される可能性があります。
そのため、502が発生したら、
「Nginxの後ろに何が動いているのか」
を確認することが重要です。
接続先のアプリケーションが動いているか確認する
Nginxから転送されるアプリケーションが停止していないか確認します。
たとえばNode.jsなどのアプリケーションを利用している場合は、アプリケーション側のサービス状態やプロセスを確認します。
systemdで管理している場合は、
sudo systemctl status アプリケーション名
のように確認できます。
Dockerを利用している場合は、
docker ps
で現在動作しているコンテナを確認できます。
ここで、本来動いているはずのアプリケーションが停止していないかを確認します。
アプリケーションが停止しているなら、Nginxの設定を変更する前に、なぜアプリケーションが停止したのかを調べる必要があります。
ポートが一致しているか確認する
502が発生したときに意外と見落としやすいのがポート番号です。
Nginxの設定で、
proxy_pass http://127.0.0.1:3000;
となっているなら、接続先のアプリケーションが3000番ポートで待ち受けている必要があります。
アプリケーション側が8000番ポートで動いているのに、Nginxが3000番ポートへ接続しようとしていれば通信できません。
つまり、
Nginx
↓
127.0.0.1:3000
と、
アプリケーション
↓
127.0.0.1:8000
のように設定が食い違っていないか確認します。
待ち受けポートを確認する
Linuxでは、どのポートでサービスが待ち受けているかを確認できます。
たとえば、
sudo ss -lntp
を実行すると、TCPポートの待ち受け状況を確認できます。
ここでNginxが接続しようとしているポートが本当に開いているかを確認します。
たとえばNginxが3000番ポートへ接続しようとしているのに、そのポートで何も待ち受けていなければ、接続先側に問題がある可能性が高くなります。
PHP-FPMを利用している場合
WordPressなど、PHPを利用する環境ではPHP-FPMが原因になっている場合もあります。
NginxからPHP-FPMへ処理を渡している場合、PHP-FPMが停止していたり、Nginx側の接続先設定と実際のPHP-FPMのソケットが一致していなかったりすると、正常に処理できません。
たとえばNginxの設定に、
fastcgi_pass unix:/run/php/php-fpm.sock;
のような指定がある場合は、実際にそのソケットが存在するか確認します。
環境によってPHPのバージョンやソケット名は異なるため、設定に書かれているパスをそのまま正しいものだと判断しないことが重要です。
PHP-FPMのサービス状態も確認します。
sudo systemctl status php-fpm
ただし、環境によってサービス名が異なる場合があります。
UbuntuなどではPHPのバージョンを含む名前になっていることもあるため、実際の環境に合わせて確認してください。
Nginxのエラーログを確認する
502の原因を調べるとき、特に重要なのがNginxのエラーログです。
環境によってログの保存場所は異なりますが、一般的なNginx環境では、
/var/log/nginx/error.log
などに保存されます。
ログを確認する場合は、
sudo tail -n 50 /var/log/nginx/error.log
のような方法があります。
ここで、
connect() failed
connection refused
upstream timed out
no live upstreams
などのメッセージが出ていないか確認します。
エラーメッセージによって、接続先の停止、タイムアウト、upstream設定など、調べるべき場所をさらに絞り込めます。
設定ファイルを変更した直後なら構文を確認する
Nginxの設定を変更した直後に問題が発生した場合は、設定ファイルの内容も確認します。
設定変更後は、いきなりNginxを再起動するのではなく、まず構文チェックを行う方法があります。
sudo nginx -t
設定に問題がなければ、テスト結果から正常であることを確認できます。
もしエラーが表示された場合は、指摘された設定ファイルや行を確認します。
設定を変更した直後に502が発生したのであれば、
「変更前は正常だったか」
も重要な手がかりになります。
Docker環境で502が出る場合
NginxとアプリケーションをDockerで動かしている場合は、ホスト側とコンテナ側の通信関係にも注意が必要です。
たとえば、
Internet
↓
Nginx
↓
Docker container
↓
Application
という構成では、Nginxがどこへ接続するよう設定されているのかを確認します。
コンテナが停止していないかは、
docker ps
で確認できます。
さらに、停止したコンテナも含めて確認したい場合は、
docker ps -a
を使います。
コンテナが起動していても、アプリケーション内部でエラーが発生している可能性があります。
その場合は、
docker logs コンテナ名
などでアプリケーション側のログも確認します。
502が出たときの確認順序
ここまでの内容を、実際のトラブル対応用にまとめると次の順番になります。
1．Nginxの状態を確認
sudo systemctl status nginx
Nginxが動作しているか確認します。
2．設定ファイルを確認
sudo nginx -t
設定変更後であれば、構文エラーがないか確認します。
3．upstreamを確認
proxy_passやfastcgi_passなどを確認し、Nginxがどこへ接続しようとしているか確認します。
4．接続先サービスを確認
アプリケーションやPHP-FPMなどが停止していないか確認します。
5．ポートやソケットを確認
Nginxの設定と、実際の待ち受けポート・ソケットが一致しているか確認します。
6．Nginxのエラーログを確認
sudo tail -n 50 /var/log/nginx/error.log
エラーの内容から原因を絞り込みます。
7．アプリケーション側のログを確認
Nginxではなく、接続先のアプリケーションでエラーが起きていないか確認します。
この順番で確認すると、闇雲に設定を変更する必要がなくなります。
502エラーが出たときにやってはいけないこと
502が表示されたからといって、すぐにNginxを再インストールしたり、設定をすべて書き換えたりするのはおすすめできません。
特に、
- 設定ファイルをバックアップせず変更する
- 原因を確認せずNginxを再インストールする
- エラーログを確認せず再起動を繰り返す
- PHP-FPMやアプリケーションを無条件に再起動する
- Dockerコンテナやボリュームを確認せず削除する
といった対応は避けたほうが安全です。
まずログとサービス状態を確認し、どこで通信が止まっているのかを特定してから対応することが重要です。
502と504は何が違う？
Nginxを利用していると、502と一緒に504 Gateway Timeoutを見かけることがあります。
大まかに考えると、
- 502 Bad Gateway：上流サーバーから正常な応答を受け取れない
- 504 Gateway Timeout：上流サーバーからの応答を待っている間にタイムアウトする
という違いがあります。
ただし、実際の原因は構成によって異なります。
そのため、ステータスコードだけで原因を断定するのではなく、Nginxのエラーログや接続先サービスの状態も確認することが大切です。
まとめ
Nginxで502 Bad Gatewayが表示されたときは、Nginxだけを疑うのではなく、Nginxの後ろにあるupstreamまで含めて確認することが重要です。
まず、
sudo systemctl status nginx
sudo nginx -t
でNginxの状態と設定を確認します。
その後、
proxy_passやfastcgi_passの接続先- アプリケーションの状態
- PHP-FPMの状態
- ポートやソケット
- Nginxのエラーログ
- アプリケーション側のログ
を順番に確認します。
502は「Nginxが壊れた」という意味ではありません。
Nginxまでは正常に動いていても、その先のサービスとの通信に問題がある場合があります。
エラーが発生した直前に設定変更やサーバー再起動などを行っていた場合は、その変更内容も重要な手がかりになります。
焦って設定を変更するのではなく、Nginx → upstream → サービス → ポート → ログという順番で確認すると、原因を切り分けやすくなります。
Nginxの502 Bad Gatewayは何が原因ですか？
代表的な原因として、upstreamのアプリケーションが停止している、接続先ポートが間違っている、PHP-FPMが停止している、Nginxの設定が実際のサービス構成と合っていないなどがあります。
Nginxを再起動すれば502は直りますか？
原因によります。設定変更後など一時的な問題で解決する場合もありますが、接続先のアプリケーションが停止している場合などは、Nginxを再起動しても解決しません。
502が出たら最初にどのログを見ればいいですか？
まずNginxのエラーログを確認すると、upstreamへの接続失敗やタイムアウトなどの手がかりを得られます。その後、必要に応じてアプリケーションやPHP-FPMなどのログも確認します。
WordPressで502が表示される場合はどうすればいいですか？
WordPressがPHPを利用している環境では、PHP-FPMの状態やNginxのfastcgi_pass設定、PHP側のログなどを確認します。また、サーバーのメモリ不足などが原因になっている可能性もあるため、システム全体の状態も確認する必要があります。