Nginxエラーコード完全解説：502, 500, 504発生時の原因と対処法

Nginx主要エラーコード早見表：500, 502, 504の原因と解決への最短ルート

Nginxで発生する主要エラーの概要と初動対応

Nginxを利用していると遭遇する頻度の高い500番台のエラーコードは、Webサーバーとバックエンドアプリケーション間の通信、またはバックエンドアプリケーション自体の問題を示すものです。これらのエラーは、ユーザーからのリクエストを処理する「バケツリレー」のどこかで問題が発生していることを意味します。具体的には、500 Internal Server Errorはバックエンド内部の処理エラー、502 Bad Gatewayはバックエンドからの不正な応答や通信途絶、504 Gateway Time-outはバックエンドからの応答遅延が主な原因です。

エラー発生時には、まず落ち着いて状況を把握し、Nginxのエラーログとバックエンドアプリケーションのログを確認することが初動として最も重要です。推測に頼らず、具体的なエラーメッセージやタイムスタンプを手がかりに、問題の切り分けを進める必要があります。

主要エラーコード別早見表と原因

以下に、Nginxでよく発生する500番台のエラーコードについて、その主な原因と緊急時の確認ポイントをまとめました。これらの情報を基に、迅速な問題特定と対応を目指しましょう。

共通の緊急対応ステップ

どの5xxエラーが発生した場合でも、共通して行うべき緊急対応ステップがあります。まず、システム全体に広がる影響を最小限に抑えるため、サービスの一時的な停止や、以前の安定したバージョンへのロールバックを検討することが重要です。特に、最近デプロイされた変更や設定ファイルの修正がある場合は、それが原因である可能性が高いため、変更点を特定し元に戻す作業を最優先で行うべきでしょう。

次に、サーバーの稼働状況を監視ツールで確認し、リソース（CPU、メモリ、ディスクI/O、ネットワーク）に異常な負荷がかかっていないかをチェックします。これにより、エラーが単なるアプリケーションの問題なのか、それともサーバー自体のリソース限界に起因するのかを切り分ける手がかりが得られます。

出典：HTTP Semantics (RFC 9110) / Nginx Documentation

エラー発生時の標準調査手順：ログ確認から設定修正まで

Nginxエラーログの確認方法と読み解き方

Nginxのエラー発生時、最初に確認すべきはNginxのエラーログです。デフォルトでは通常 `/var/log/nginx/error.log` に出力されますが、設定ファイル（nginx.conf）によってパスが変更されている場合もあります。このログファイルには、Nginxが検出した問題の詳細が記録されており、エラーの種類、発生時刻、クライアントIP、リクエストURL、そして何よりも重要な「原因」を示すメッセージが含まれています。

ログを読み解く際は、最新のエラーメッセージから順に確認し、特に「upstream timed out」や「connect() failed」といったキーワードに注目してください。これらのメッセージは、Nginxがバックエンドサーバーと通信しようとした際に発生した具体的な問題を示しており、問題の所在を特定する上で非常に役立ちます。ログから得られる情報は、決して推測に頼らず、客観的な事実に基づいて次の調査ステップを決定するための羅針盤となります。

バックエンドサーバーのログも忘れずに

Nginxがリバースプロキシとして動作している場合、502 Bad Gatewayや504 Gateway Time-outのようなエラーは、Nginxそのものよりもバックエンドアプリケーションに根本的な原因があることが多いです。そのため、Nginxのエラーログだけでなく、PHP-FPM、Node.js、Python Gunicornなど、実際にリクエストを処理しているバックエンドサーバーのログも併せて確認することが不可欠です。

例えば、PHPを使用しているシステムでは `/var/log/php-fpm/error.log` や、アプリケーションフレームワーク固有のログファイル（例: Laravelの `storage/logs/laravel.log`）に、詳細なスタックトレースやデータベースエラー、メモリ不足といった情報が記録されている可能性があります。これらのログをNginxのログと照らし合わせることで、問題がNginxとバックエンド間の通信障害なのか、それともバックエンドアプリケーション内部の処理不具合なのかを正確に切り分けることができ、早期解決へと繋がります。

設定変更と反映の基本

Nginxのエラー調査の結果、設定ファイル（`nginx.conf` や `conf.d` 以下のファイル）の修正が必要となるケースは少なくありません。しかし、設定ファイルを変更しただけでは、その内容はNginxに反映されません。必ず変更後に設定ファイルの構文チェックを行い、Nginxサービスを再読み込みまたは再起動する必要があります。

構文チェックは `nginx -t` コマンドで行います。これにより、設定ファイルに誤りがないかを確認でき、サービス停止のリスクを回避できます。構文に問題がなければ、`sudo systemctl reload nginx` （systemdを使用している場合）または `sudo service nginx reload` （SysVinitを使用している場合）コマンドで、Nginxサービスを停止することなく設定を反映させることが可能です。設定変更が反映されていないことが原因で問題が解決しないケースは非常に多いため、この手順を徹底することが重要です。

出典：Nginx Documentation / Nginx トラブルシューティングガイド (LINUX工房 他)

Nginxエラーコード別対処法：500, 502, 504の詳細原因と設定例

500 Internal Server Errorの深掘り

500 Internal Server Errorは、バックエンドサーバーがリクエストを処理する際に予期せぬエラーに遭遇したことを示します。このエラーの根本原因はNginxではなく、PHP、Node.js、Pythonなどのアプリケーションコードや、それらが利用するデータベース、外部APIに存在することがほとんどです。具体的な対処法としては、まずアプリケーション側のログを徹底的に確認し、どのコード、どのデータベースクエリ、どの外部サービスとの連携で問題が発生しているかを特定します。例えば、データベースの接続情報が誤っていたり、SQLクエリに構文エラーがあったり、PHPスクリプトで未定義の変数を使用していたりするケースが考えられます。

アプリケーションコードの修正が最も直接的な解決策ですが、Nginx側では、ユーザーに分かりやすいエラーページを表示する設定が可能です。`nginx.conf`の`http`ブロックや`server`ブロック内に`error_page 500 502 503 504 /50x.html;`のようなディレクティブを追加し、カスタムエラーページを指定することで、ユーザー体験の低下を最小限に抑えられます。

502 Bad Gatewayの具体的な解決策

502 Bad Gatewayは、Nginxがバックエンドサーバーから無効な応答を受け取った、または通信自体が確立できなかった場合に発生します。この問題の主な原因として、バックエンドプロセス（例: PHP-FPM）の停止、クラッシュ、または過負荷による応答不能が挙げられます。まず、バックエンドプロセスの状態を `systemctl status php-fpm` (または類似のコマンド) で確認し、必要であれば再起動を試みてください。

次に、Nginxのプロキシ設定を確認します。特に `proxy_pass` や `fastcgi_pass` ディレクティブで指定されているバックエンドのアドレスやポートが正しいか、またバックエンドがそのポートでリッスンしているかを確認します。ソケットファイルを使用している場合は、そのパスとパーミッションも重要です。さらに、バックエンドからの応答がNginxのバッファリング設定に合わない場合にも発生することがあります。Nginxの`http`ブロック内で`proxy_buffers`や`proxy_buffer_size`、`fastcgi_buffers`などの値を調整することで改善される可能性がありますが、安易な変更は他の問題を引き起こす可能性もあるため、注意が必要です。

504 Gateway Time-outの対応戦略

504 Gateway Time-outは、Nginxがバックエンドサーバーからの応答を規定時間内に受け取れなかった場合に発生します。これは、バックエンドアプリケーションの処理に時間がかかりすぎているか、ネットワーク遅延によって応答が遅延していることが原因です。この問題の解決には、Nginxとバックエンドアプリケーションの両方でタイムアウト設定を見直す必要があります。

Nginx側では、`proxy_read_timeout`、`proxy_send_timeout`、`fastcgi_read_timeout`といったディレクティブの値を適切に延長することを検討します。これらの設定は、Nginxがバックエンドからの応答を待つ最大時間を定義します。例えば、`proxy_read_timeout 120s;` のように設定を増やすことで、長時間かかる処理にも対応できるようになります。しかし、単にタイムアウト時間を延ばすだけでは根本的な解決にはなりません。バックエンドアプリケーションのボトルネック（遅いデータベースクエリ、非効率なコード、外部APIへの同期呼び出しなど）を特定し、パフォーマンスを最適化することが最も重要です。また、PHP-FPMを使用している場合は、`request_terminate_timeout` の設定も併せて確認し、Nginxのタイムアウト値と整合性を取ることが望ましいでしょう。

出典：Nginx Documentation / Nginx トラブルシューティングガイド (LINUX工房 他)

Nginx設定の落とし穴：見落としがちなエラー原因と対策

設定ファイルの構文ミスと記述漏れ

Nginxのトラブルシューティングにおいて、最も基本的でありながら見落とされがちなのが、設定ファイル（`nginx.conf`や`conf.d`ディレクトリ下のファイル）の構文ミスや記述漏れです。セミコロン（`;`）の忘れ、ブロックの閉じカッコ（`}`）の欠落、ディレクティブ名のタイポなどが原因で、Nginxは期待通りに動作せず、起動失敗や5xxエラーを引き起こすことがあります。

この種のミスを防ぐ最も確実な方法は、設定ファイルを修正した後、必ず `sudo nginx -t` コマンドを実行することです。このコマンドは、Nginxの設定ファイルを解析し、構文エラーがないか、参照されているファイルが存在するかなどをチェックしてくれます。エラーが検出されれば具体的な行番号と内容が示されるため、迅速に問題を特定し修正できます。設定変更を反映する前にこのチェックを習慣化することで、意図しないサービス停止のリスクを大幅に軽減できます。

リソース不足とOSレベルの制限

Nginxやバックエンドアプリケーションが正常に動作しているように見えても、サーバー全体のリソース不足が原因で5xxエラーが発生することがあります。特に、大量のアクセスが集中したり、バックエンド処理が重くなったりすると、CPU、メモリ、ディスクI/O、そしてファイルディスクリプタ（ファイル記述子）の不足が顕在化します。

例えば、ファイルディスクリプタの不足は、多数の同時接続を処理するNginxで502エラーを引き起こす典型的な原因です。これはOSレベルの制限（`ulimit -n` で確認可能）とNginxの `worker_connections` ディレクティブの設定が関係しています。OSの制限値がNginxの設定よりも低い場合、Nginxは設定された数の接続を処理できなくなります。`top`, `htop`, `free -h`, `df -h` などのコマンドでサーバーのリソース状況を定期的に監視し、必要に応じてOSのカーネルパラメータやNginxの設定（例: `worker_connections` を増やす）を調整することが重要です。

プロキシ関連の高度な設定と注意点

Nginxは強力なリバースプロキシ機能を提供しますが、`proxy_buffering`、`proxy_cache`、SSL/TLS関連の設定など、高度な機能を誤って設定すると予期せぬエラーを引き起こすことがあります。例えば、`proxy_buffering off;` を安易に設定すると、バックエンドの応答が遅い場合にNginxがすべてのデータを待つことになり、クライアント側でタイムアウトが発生しやすくなる可能性があります。

また、HTTPSを使用している場合、SSL証明書の期限切れ、証明書チェーンの不備、SNI（Server Name Indication）の設定ミスなども、クライアント側で「このサイトにアクセスできません」といったメッセージや、場合によってはNginxが5xxエラーを返す原因となることがあります。これらの高度な設定を行う際は、Nginxの公式ドキュメントを熟読し、環境に応じた最適な設定を慎重に適用することが不可欠です。特に本番環境での大規模な変更は、事前に開発環境やステージング環境で十分にテストすることが強く推奨されます。

出典：Module ngx_http_core_module – nginx / Nginx トラブルシューティングガイド (LINUX工房 他)

【ケース】タイムアウトエラーで頻発するサービス停止を改善した事例

事例の概要と問題発生の背景（架空のケース）

これは、中小規模のECサイトを運営する企業における架空のケースです。同社では、ピークタイム（特にセール期間中）になると、ユーザーからの注文処理が頻繁に504 Gateway Time-outエラーとなり、サービスが一時的に停止する問題に悩まされていました。Nginxはリバースプロキシとして機能し、バックエンドにはPHP-FPMとMySQLデータベースが稼働していました。普段のアクセスでは問題なかったものの、注文確定ボタンを押してから数分待たされた後、エラーページが表示されるという状況が頻発し、ユーザーからのクレームが増加していました。

最初の調査では、Nginxのログに「upstream timed out (110: Connection timed out)」が大量に記録されており、Nginxがバックエンドからの応答を待ちきれずにタイムアウトしていることが明確でした。しかし、NginxのCPUやメモリ使用率には異常が見られず、問題がNginx本体ではなく、バックエンド側にある可能性が高いと推測されました。

調査から改善策の実施まで

さらなる深掘りとして、バックエンドであるPHP-FPMのログとMySQLのスロークエリログを確認しました。その結果、以下のボトルネックが特定されました。まず、PHP-FPMのログでは、特定の注文処理を行うスクリプトが「max_execution_time」を超過して強制終了しているログが多数見つかりました。さらに、MySQLのスロークエリログからは、注文履歴と在庫を紐づける複雑なクエリが、数秒から数十秒かかる場合があることが判明しました。

これらの調査結果に基づき、以下の改善策を実施しました。

1. Nginxのタイムアウト設定の調整: 段階的に`proxy_read_timeout`を30秒から60秒へ延長。これは、一時的な対処としてユーザー体験を少しでも向上させるため。
2. PHP-FPMのタイムアウト設定の調整: `request_terminate_timeout` をNginxのタイムアウト値に合わせて延長し、Nginxとの整合性を確保。
3. データベースクエリの最適化: 最も時間のかかる注文履歴関連のクエリに対して、インデックスの追加やJOIN処理の見直しを実施。
4. アプリケーションコードの改善: 注文処理ロジック内の外部APIへの同期呼び出しを非同期処理に一部変更し、処理時間を短縮。

これらの施策は、緊急度と効果のバランスを考慮し、段階的に適用されました。

改善後の効果と継続的なモニタリング

改善策実施後、まず目に見えて効果が現れたのは、ピーク時の504 Gateway Time-outエラーの劇的な減少でした。特にデータベースクエリの最適化とアプリケーションコードの改善により、バックエンドの処理時間が大幅に短縮され、Nginxのタイムアウト設定延長がなくても安定稼働するようになりました。結果として、セール期間中の注文キャンセル率が低下し、ユーザー満足度が向上しました。

この事例から得られた教訓は、単にNginxのタイムアウト値を延長するだけでなく、根本原因であるバックエンドアプリケーションの処理速度を改善することの重要性です。また、このような問題の再発を防ぐため、企業は以下の継続的なモニタリングと対策を導入しました。具体的には、サーバーパフォーマンスモニタリングツールを導入し、CPU、メモリ、ディスクI/O、ネットワークに加え、PHP-FPMプロセス数やMySQLのクエリ実行状況を常時監視する体制を確立しました。さらに、定期的な負荷試験を実施し、システムのボトルネックを早期に発見・改善するPDCAサイクルを回すことで、より強固なインフラ体制を構築することができました。

出典：職業情報提供サイト（job tag）厚生労働省 / Nginx トラブルシューティングガイド (LINUX工房 他)