症状

nginxのエラーログに upstream timed out (110: Connection timed out) が記録され、502 Bad Gateway または 504 Gateway Timeout が発生する。

結論：まずこれを確認

  1. バックエンド（upstream）サーバーが起動しているか確認
  2. バックエンドの応答時間がnginxのタイムアウト設定を超えていないか確認
  3. ネットワーク経路に問題がないか確認

トラブルシューティングフロー

    flowchart TD
    A[upstream timed out 発生] --> B{バックエンドは起動している?}
    B -->|No| C[バックエンドを起動]
    B -->|Yes| D{バックエンドに直接アクセス可能?}
    D -->|No| E[ネットワーク/ファイアウォール確認]
    D -->|Yes| F{応答時間は正常?}
    F -->|遅い| G[バックエンドの処理を改善<br>またはタイムアウト延長]
    F -->|正常| H{nginx設定は正しい?}
    H -->|No| I[proxy_pass設定を確認]
    H -->|Yes| J[負荷状況を確認]

よくある原因

  • バックエンドサーバーの停止 - upstream先のプロセスが落ちている
  • バックエンドの処理遅延 - 重いクエリやAPIで応答が遅れている
  • タイムアウト設定が短すぎる - デフォルト60秒では足りない処理がある
  • ネットワーク到達性の問題 - ファイアウォールやセキュリティグループでブロック
  • バックエンドのコネクション枯渇 - 同時接続数の上限に達している
  • DNSの名前解決失敗 - upstream指定のホスト名が解決できない
  • ソケットファイルのパーミッション - Unix socketを使う場合の権限問題

確認手順

ステップ1: エラーログの詳細を確認する

    # エラーログの最新エントリを確認
sudo tail -50 /var/log/nginx/error.log | grep -i "upstream"

# 特定の時間帯のエラーを抽出
sudo grep "upstream timed out" /var/log/nginx/error.log | tail -20

🔍 チェックポイント: upstream timed out の後に続くIPアドレスとポートを確認。これがタイムアウトしているバックエンド。

ステップ2: バックエンドサーバーの状態を確認する

    # プロセスの稼働確認（例: PHP-FPM）
sudo systemctl status php-fpm

# プロセスの稼働確認（例: Node.js / PM2）
pm2 status

# ポートのリッスン状態を確認
sudo ss -tlnp | grep -E ":(8080|9000|3000)"

🔍 チェックポイント: バックエンドプロセスが起動しており、指定ポートでリッスンしていれば正常。

ステップ3: バックエンドへの直接接続を確認する

    # TCP接続テスト
nc -zv 127.0.0.1 8080

# curlで応答時間を計測
curl -w "Time: %{time_total}s\n" -o /dev/null -s http://127.0.0.1:8080/health

# Unix socketの場合
curl --unix-socket /var/run/php/php-fpm.sock http://localhost/status

🔍 チェックポイント: 接続成功かつ応答時間が数秒以内なら、バックエンド自体は正常。

ステップ4: nginx設定のタイムアウト値を確認する

    # 現在のタイムアウト設定を確認
sudo nginx -T | grep -E "(proxy_connect_timeout|proxy_send_timeout|proxy_read_timeout|fastcgi_read_timeout)"

🔍 チェックポイント: 設定値が表示されない場合はデフォルト値（60秒）が適用されている。

ステップ5: タイムアウト設定を調整する

    # /etc/nginx/nginx.conf または該当するserver/locationブロック内

# リバースプロキシの場合
proxy_connect_timeout 60s;
proxy_send_timeout 120s;
proxy_read_timeout 120s;

# FastCGI（PHP-FPM等）の場合
fastcgi_connect_timeout 60s;
fastcgi_send_timeout 120s;
fastcgi_read_timeout 120s;
  
    # 設定の構文チェック
sudo nginx -t

# 設定を反映
sudo systemctl reload nginx

🔍 チェックポイント: nginx -t で syntax is ok と test is successful が表示されれば設定に問題なし。

ステップ6: バックエンドの負荷状況を確認する

    # CPU・メモリ使用率
top -bn1 | head -20

# バックエンドプロセスの接続数（例: PHP-FPM）
sudo netstat -anp | grep php-fpm | wc -l

# slow logの確認（PHP-FPMの場合）
sudo tail -50 /var/log/php-fpm/slow.log

🔍 チェックポイント: CPU使用率が常時90%以上、またはメモリ枯渇が見られる場合はリソース不足。

NG行動（やってはいけないこと）

  • タイムアウトを極端に長くする（600秒以上） - 根本原因を隠蔽し、コネクション枯渇を招く
  • エラーログを確認せずに設定を変更する - 原因特定ができず、問題が再発する
  • 本番環境でnginxを再起動（restart）する - reload を使うこと。restart は接続が切断される
  • バックエンドを確認せずにnginxだけ調査する - 多くの場合、原因はバックエンド側にある

よくある質問（FAQ）

Q1: proxy_read_timeout と fastcgi_read_timeout の違いは？

A: proxy_read_timeout はHTTPプロキシ（proxy_pass）用、fastcgi_read_timeout はFastCGI（PHP-FPM等）用。使用しているupstream方式に合わせて設定する。

Q2: タイムアウト値はどのくらいに設定すべき？

A: バックエンドの最大処理時間 + 余裕（10〜20秒）を目安にする。ただし、処理時間が長すぎる場合は、バックエンド側の最適化を優先する。

Q3: 502と504の違いは何？

A: 502 Bad Gateway はバックエンドからの応答が不正または接続失敗。504 Gateway Timeout はバックエンドからの応答がタイムアウト設定内に返らなかった場合に発生する。

関連するエラー・症状

解決しない場合

公式ドキュメント

確認すべきログファイル

  • /var/log/nginx/error.log - nginxエラーログ
  • バックエンドのアプリケーションログ
  • /var/log/syslog または /var/log/messages - システムログ

次に調べるキーワード

  • nginx upstream prematurely closed connection
  • nginx no live upstreams
  • nginx worker_connections not enough