問題の概要Nginxのエラーログ（/var/log/nginx/error.log）を確認すると、以下のような行が繰り返し記録されていることがあります。
connect() failed (111: Connection refused) while connecting to upstream, client: 1.2.3.4, server: example.com, upstream: "http://127.0.0.1:3000/"
簡単に言えば、Nginxがバックエンドのドアを叩いても、誰も応答していない状態です。これはバックエンドの処理が遅い「504 Gateway Timeout」とは異なります。111エラーは即座の拒絶です。指定されたポートで何も待機していないか、オペレーティングシステムがアクティブに接続を遮断しています。
主な原因- サービスのクラッシュ: Node.js、PM2、Gunicornなどのプロセスが予期せず終了したか、起動していません。- ポートの不一致: アプリケーションは8080ポートで動作しているのに、Nginxが3000ポートを探しています。- localhostの罠: Nginxがlocalhost（IPv6の::1）経由で接続しようとしているのに対し、アプリが127.0.0.1（IPv4）のみで待機しています。- セキュリティの壁: SELinuxやファイアウォールが、Nginxとアプリ間の内部通信をブロックしています。## ステップバイステップの修正方法### 1. バックエンドが実際に動作しているか確認する設定ファイルを変更する前に、アプリケーションのプロセスが生きているか確認してください。クラッシュしている場合、Nginxは通信相手がいません。
# アプリのsystemdステータスを確認
sudo systemctl status my-backend-app
# PM2を使用している場合
pm2 status
# 従来の方法
ps aux | grep node
ステータスがinactive（停止）やfailed（失敗）の場合は、再起動してください。あわせてアプリケーションのログを確認し、構文エラーや環境変数の不足が原因でクラッシュしていないかチェックしましょう。
2. 待機ポート（Listening Port）の確認サービスが「アクティブ」であっても、期待したポートにバインドされていないことがあります。ssコマンドを使用して、ネットワークスタックで何が起きているか正確に把握します。
sudo ss -tlpn | grep :3000
次のような行が表示されれば正常です。
LISTEN 0 128 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=1234,fd=19))
結果が表示されない場合: アプリが3000ポートで待機していません。.envファイルやサーバー設定内のPORT=3000の設定を確認してください。
3. Nginx設定の監査通常は /etc/nginx/sites-available/ にあるサイト設定を開きます。proxy_passの行を注意深く確認してください。
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
}
"localhost"の使用は避けましょう。 最近のLinuxシステムでは、localhostがIPv6アドレスの::1に解決されることがよくあります。バックエンドがIPv4（127.0.0.1）のみにバインドされている場合、Nginxは接続に失敗します。明示的なIPアドレス 127.0.0.1 を使用する方が、このDNSの曖昧さを避けられるため安全です。
設定をテストして適用します：
sudo nginx -t
sudo systemctl reload nginx
4. SELinuxの調整 (RHEL/CentOS/AlmaLinux)Red Hat系のシステムでは、SELinuxが「見えない壁」になっていることがよくあります。デフォルトでは、Nginxが外部へのネットワーク接続を行うことを禁止しています。
現在の設定を確認します：
getsebool httpd_can_network_connect
もしoffと返ってきたら、それが原因です。以下のコマンドで永続的に有効化します：
sudo setsebool -P httpd_can_network_connect 1
最終確認Nginxとバックエンドが同じ言語で話しているか確認しましょう。サーバーのコマンドラインから簡単なテストを実行します。
# サーバーからバックエンドに通信できるか？
curl -I http://127.0.0.1:3000
# Nginx経由でバックエンドに到達できるか？
curl -I http://localhost
最初のコマンドで 200 OK が返るのに2番目のコマンドが失敗する場合、Nginxの proxy_pass ロジックにまだ誤りがあります。両方成功すれば、問題解決です。