【保存版】Nginxトラブルシューティング完全ガイド。502/504エラーから「繋がらない」原因特定まで、プロの解決フローを全公開

「動かない！」と叫ぶその前に。プロは「ログ」と会話する。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
これまで「基本講座」「応用講座」を通して、Nginxの構築から高度な運用までを学んできました。
しかし、どんなに完璧に構築したつもりでも、システム運用にトラブルは付きものです。

「設定ファイルを変えたら起動しなくなった」「突然502エラーが出始めた」「特定の画像だけ表示されない」……。
画面に表示される冷酷なエラーメッセージを前に、頭が真っ白になった経験はありませんか？
トラブルシューティング能力こそが、インフラエンジニアの価値を決めると言っても過言ではありません。

本記事では、Nginxで発生する代表的なエラーコード（4xx/5xx）ごとの原因と対策、ネットワーク疎通トラブルの切り分け方、そして strace や tcpdump といったLinuxコマンドを駆使した高度な調査手法までを網羅します。

---

第1章：トラブルシューティングの鉄則（心構えと準備）

技術的な詳細に入る前に、トラブル対応時の「鉄則」を確認しましょう。
これを守るだけで、解決までの時間は半分になります。

1. 「何もしていないのに壊れた」は嘘

サーバーは勝手に設定を変えません。
「何もしていない」のではなく、「自分が意識していない変更（自動アップデート、ディスク容量枯渇、ログローテートの失敗など）」が起きているのです。
まずは直近の変更点（Change Log）やコマンド履歴（history）を確認しましょう。

2. 「推測」ではなく「計測」する

「たぶんメモリ不足だろう」で再起動するのは素人です。
必ずログやメトリクスで裏付けを取りましょう。

• 構文チェック: nginx -t （設定を変えたら必ず叩く癖をつける）
• ステータス確認: systemctl status nginx
• ログ確認: tail -f /var/log/nginx/error.log

3. 現状を再現する（最小構成で試す）

複雑な設定ファイル（nginx.conf）の中から原因を探すのは困難です。
問題が起きている箇所だけを切り出した、シンプルな設定ファイルで再現するかテストします。

---

第2章：エラーコード別・即効対策ガイド（HTTPステータスコード）

Nginxが返すエラーコードは、問題の所在を教えてくれる羅針盤です。
代表的なコードごとの原因と対策をまとめました。

403 Forbidden（閲覧禁止）

意味: 「そこにファイルはあるけど、見せる権限がないよ」

原因と対策:

1. ファイル権限（Permission）:
   Nginxの実行ユーザー（通常 nginx や www-data）が、ファイルやその親ディレクトリを読み取れるか確認します。
   namei -om /var/www/html/index.html コマンドで見ると分かりやすいです。
2. インデックスファイルの欠如:
   ディレクトリ（例: /）にアクセスした際、index.html や index.php が存在しない場合、ディレクトリ一覧表示（autoindex）がOFFだと403になります。
   index ディレクティブの設定を確認しましょう。
3. SELinux（最重要容疑者）:
   RHEL/AlmaLinux系の場合、SELinuxがブロックしている可能性が高いです。
   一時的に setenforce 0 して表示されるなら確定です。正しいコンテキスト（httpd_sys_content_t）を付与しましょう。
4. IP制限:
   allow / deny ディレクティブで自分のIPが拒否されていないか確認します。

404 Not Found（見つかりません）

意味: 「指定された場所にファイルがないよ」

原因と対策:

1. root と alias の勘違い:
   これは 基本講座 第3回 で解説した通り、Nginx最大の罠です。
   location /img/ { root /var/www; } と書くと、/var/www/img/ を探しに行きます。
   期待通り動かない場合は、エラーログを見て「Nginxが実際にどのパスを探しに行ったか」を確認してください。
2. try_files の設定漏れ:
   WordPressなどのCMSや、ReactなどのSPA（Single Page Application）では、実ファイルが存在しないURLへのアクセスを index.php や index.html に転送する必要があります。
   try_files $uri $uri/ /index.php?$args; が記述されているか確認しましょう。

500 Internal Server Error（サーバー内部エラー）

意味: 「Nginxは悪くない。後ろにいるアプリか、設定ファイルがおかしい」

原因と対策:

1. バックエンドアプリのバグ:
   PHPやPythonなどのプログラムがクラッシュしています。Nginxのログだけでなく、アプリケーション側のログ（例: /var/log/php-fpm/error.log）を確認してください。
2. リライトルールの無限ループ:
   rewrite ディレクティブの設定ミスで、内部リダイレクトがループしている可能性があります。エラーログに “rewrite or internal redirection cycle” と出ていないか確認します。
3. ファイルディスクリプタ枯渇:
   大規模サイトの場合、worker_rlimit_nofile の上限に達している可能性があります。

502 Bad Gateway（不正なゲートウェイ）

意味: 「バックエンド（APサーバー）に繋ごうとしたけど、通信できなかったよ」

原因と対策:

1. バックエンドがダウンしている:
   systemctl status php-fpm や pm2 status でアプリが起動しているか確認します。
2. ポート番号/ソケットパスの間違い:
   proxy_pass や fastcgi_pass の指定先が正しいか確認します。
3. Unixドメインソケットの権限:
   TCPではなくソケット（.sock）で通信している場合、ソケットファイルの所有者や権限がNginxから書き込み可能になっているか確認します（ls -l /run/php-fpm/www.sock）。
4. ヘッダーサイズオーバー:
   Cookieなどが肥大化して、バックエンドへのリクエストヘッダーが大きすぎる場合、proxy_buffer_size や fastcgi_buffer_size を増やす必要があります。

504 Gateway Time-out（タイムアウト）

意味: 「バックエンドに繋がったけど、いつまで待っても返事が来ないから諦めたよ」

原因と対策:

1. 処理が重すぎる:
   データベースの集計処理や、外部API連携などで時間がかかっていませんか？
   アプリの処理を高速化するか、Nginxの待機時間を延ばします。
   proxy_read_timeout 600s;
2. バックエンドのリソース不足:
   PHP-FPMのワーカープロセスが全て埋まっていて、順番待ちが発生している可能性があります。

413 Request Entity Too Large

意味: 「アップロードされたファイルがデカすぎるよ」

対策:
client_max_body_size 20M; のように上限を増やします。

---

第3章：「繋がらない」「遅い」の深層心理（ネットワークとパフォーマンス）

エラーコードすら返ってこない場合や、単に遅い場合の調査方法です。

1. そもそも繋がらない（Connection Refused / Timed out）

ブラウザで「サイトにアクセスできません」と出る場合。

• Nginxは起動しているか？
  ps aux | grep nginx でプロセスを確認。
• ポートは開いているか？
  ss -tlnp | grep 80 で、Nginxが80/443番ポートをLISTENしているか確認。
  もし 127.0.0.1:80 となっていたら、外部からアクセスできません。listen 80; （IP指定なし）になっているか確認しましょう。
• ファイアウォール（Firewalld / AWS Security Group）:
  サーバー内部だけでなく、クラウド側のファイアウォールでもポートが許可されているか確認が必要です。
  curl -v http://localhost が通るのに外部から通らないなら、ファイアウォールが原因です。

2. 無限リダイレクトループ（ERR_TOO_MANY_REDIRECTS）

CDN（CloudflareやAWS CloudFront）やロードバランサーを使用している環境で頻発します。
詳細は 補足記事：CDN連携の極意 で解説していますが、X-Forwarded-Proto ヘッダーを正しく評価していないことが原因です。

3. サイトがとにかく遅い

「遅い」の原因は多岐にわたります。Linuxトラブルシューティング単発記事 も併せて参照してください。

• リソース不足: top コマンドでCPU負荷（Load Average）やメモリ使用率を確認。
• ディスクI/O: iostat でディスクの書き込み待ちが発生していないか確認。
• 名前解決の遅延: Nginxの設定内でドメイン名を使っている場合（proxy_pass http://api.example.com;）、DNS解決に時間がかかっている可能性があります。resolver ディレクティブで高速なDNSサーバー（8.8.8.8など）を指定します。

---

第4章：ログ解析のプロテクニック

ログはただ眺めるものではありません。必要な情報を抽出するものです。

エラーログのレベルを知る

nginx.conf の error_log /var/log/nginx/error.log warn; の末尾がログレベルです。
debug > info > notice > warn > error > crit > alert > emerg
トラブル時は一時的に info や debug に変更することで、より詳細な情報を得られます（ただしディスク容量に注意）。

アクセスログから攻撃者を炙り出す

例えば、「サイトが重い」時に、特定のIPが大量アクセスしていないか確認するコマンドです。

# アクセス数が多いIPトップ10を表示
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

特定のステータスコード（例：500エラー）のログだけを抽出するコマンドです。

grep " 500 " /var/log/nginx/access.log | tail -n 20

---

第5章：設定ファイル（conf）のハマりポイント集

Nginxの設定には、直感に反する挙動（罠）がいくつかあります。

1. 「If is Evil」（if文は魔物）

Nginx公式が警告するほど、location ブロック内での if ディレクティブは予期せぬ挙動を引き起こします。
基本的に if は使わず、try_files や map 、return などで代替できないか検討しましょう。

2. add_header の継承ルール

「親ブロックで設定したヘッダーが、子ブロックで消えた！？」
Nginxの仕様では、現在のブロック（location）に add_header が一つでも書かれていると、親ブロック（http/server）の add_header は一切継承されません。
子ブロックでも必要なヘッダーはすべて書き直す必要があります。

3. location の優先順位

「正規表現（~）」と「前方一致（^~）」の優先順位を間違えて、意図しないlocationが適用されているケースです。
基本講座 第2回 の「優先順位ランキング」をもう一度復習してください。

---

第6章：実際のトラブルシューティング事例（ケーススタディ）

最後に、私が現場で実際に遭遇した事例を紹介します。

事例1：特定端末だけ画像が表示されない

• 現象: PCでは見えるが、iPhoneだけで画像が表示されない。
• 調査: error.log にエラーなし。アクセスログを見るとステータス200。
• 原因: 画像の拡張子が .webp だったが、Nginxの mime.types にWebPの定義がなく、Content-Type: application/octet-stream（ダウンロード扱い）として返されていた。
• 解決: mime.types に image/webp webp; を追加。

事例2：デプロイ直後に502多発

• 現象: アプリをデプロイした後、Nginxが502エラーを吐き始めた。
• 調査: アプリは起動している。Nginxのエラーログに connect() to unix:/var/run/app.sock failed (13: Permission denied)。
• 原因: デプロイツールがソケットファイルを再作成した際、所有者が root になってしまい、Nginxユーザーから書き込めなくなっていた。
• 解決: ソケットの所有者を www-data に変更し、デプロイスクリプトを修正。

事例3：深夜のバッチ処理中にサイトが重くなる

• 現象: 毎日AM3:00頃、サイトの応答速度が極端に落ちる。
• 調査: top コマンドでLoad Averageが高いが、CPU使用率は低い。iostat を見るとディスク書き込みが100%張り付き。
• 原因: 同時刻に走っていたDBのバックアップ処理とログのローテーションが重なり、ディスクI/Oが枯渇していた。
• 解決: バックアップ時間をずらし、ionice コマンドでバックアップ処理のI/O優先度を下げた。

---

まとめ：トラブルは成長の糧

お疲れ様でした！
かなり濃密な内容でしたが、これらを理解していれば、Nginxのトラブルの9割は解決できるはずです。

トラブルシューティングは、最初は怖くて焦るものです。
しかし、ログを読み解き、仮説を立て、検証して解決するというプロセスを繰り返すことで、あなたのエンジニアとしてのスキルは飛躍的に向上します。
「エラーが出た！ラッキー、これでまた詳しくなれるぞ」くらいの気持ちで向き合ってみてください。

あなたのサーバー運用が、平穏無事であることを祈りつつ、何かあった時はまたこの記事に戻ってきてください。
Happy Debugging!