Nginx設定のテスト方法とサーバーステータスの監視方法

Nginx設定のテスト方法とサーバーステータスの監視方法を知っておくと、小さなミスが障害に発展するのを防げます。セミコロンの欠落、誤った証明書パス、重複したサーバー名などがリロードを失敗させる可能性がありますが、Nginxには問題を早期に発見するための信頼できるツールが用意されています。

特に本番サーバーでは、設定変更の前後にこれらのチェックを実行してください。

Nginx設定構文のテスト

最初に実行するコマンドは次のとおりです。

sudo nginx -t

これにより、読み込まれた設定ファイルが検証され、Nginxがそれらを解析できるかどうかが報告されます。成功した結果は次のようになります。

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

テストが失敗した場合は、リロードしないでください。エラーメッセージを注意深く読んでください。Nginxは通常、ファイルパスと行番号を含めて表示します。

nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/example.com:42

行番号は出発点であり、常に完全な答えとは限りません。実際の問題は、数行前のセミコロンや括弧の欠落である可能性があります。

このコマンドは、以下の変更後いつでも使用してください。

nginx.conf
conf.d内のファイル
sites-enabled内のファイル
TLS証明書パス
プロキシアップストリーム定義
インクルードスニペット

アクティブな設定の全体像を表示するには、次を実行します。

sudo nginx -T

これにより、メインファイルとインクルードされたファイルが出力されます。これは、忘れていたファイルでディレクティブが設定されている場合に特に便利です。

テスト合格後に安全にリロード

sudo nginx -tが成功したら、Nginxをリロードします。

sudo systemctl reload nginx

リロードは通常、再起動よりも安全です。Nginxは新しい設定で新しいワーカーを起動し、古いワーカーは既存のリクエストを処理し終えます。つまり、ユーザーが接続の中断を目にする可能性が低くなります。

リロードが失敗した場合は、サービスステータスを確認します。

sudo systemctl status nginx

次に、ジャーナルを確認します。

sudo journalctl -u nginx --since "10 minutes ago"

実用的なワークフローは次のようになります。

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx

この3ステップの習慣により、構文エラーをキャッチし、変更を適用し、サービスが正常に動作し続けていることを確認できます。

日常的なサービス運用については、Nginxサービスの制御コマンドの基本を参照してください。

Nginxがトラフィックを処理しているかの監視

サービスステータスは、Nginxが実行中かどうかを示します。ユーザーが正しい応答を受け取っていることを証明するものではありません。プロセスと実際のHTTP動作の両方を確認してください。

サービスがアクティブであることを確認します。

systemctl is-active nginx

Nginxが期待されるポートでリッスンしていることを確認します。

sudo ss -ltnp | grep nginx

ポート80、ポート443、または設定で使用されているカスタムポートのリスナーが表示されるはずです。

次に、ローカルでHTTP応答をテストします。

curl -I http://localhost

HTTPSおよび名前付きサーバーブロックの場合は、ホスト名を含めます。

curl -I https://example.com

DNSがまだサーバーを指していない場合は、解決済みのアドレスでテストできます。

curl -I --resolve example.com:443:203.0.113.10 https://example.com

IPをサーバーのアドレスに置き換えてください。これにより、パブリックDNSの変更が有効になる前にNginxサーバーブロックをテストできます。

アクセスログとエラーログの監視

ログは、リロード後にNginxが何をしているかを示します。一般的な2つのファイルは次のとおりです。

/var/log/nginx/access.log
/var/log/nginx/error.log

エラーログをリアルタイムで追跡します。

sudo tail -f /var/log/nginx/error.log

アクセスログをリアルタイムで追跡します。

sudo tail -f /var/log/nginx/access.log

アクセスログは、どのリクエストが来ているか、Nginxがどのステータスコードを返しているかを示します。エラーログは、アップストリーム接続の失敗、ファイルの欠落、権限の問題、リクエスト本文の制限、TLSの問題、設定に関連する実行時警告を示します。

単一の行だけでなく、パターンに注目してください。

多くの404応答は、ルートまたはロケーションブロックが間違っている可能性があります。
多くの502応答は、アップストリームアプリがダウンしている可能性があります。
多くの499応答は、応答が完了する前にクライアントが諦めている可能性があります。
繰り返される権限エラーは、ファイルの所有者またはディレクトリの実行ビットが間違っている可能性があります。
TLSハンドシェイクエラーは、証明書またはプロトコルの不一致を示している可能性があります。

複数のドメインをホストしている場合は、サーバーブロックごとに個別のログを設定してください。これにより、監視がよりクリーンになり、インシデント対応が迅速化されます。

基本的なNginxステータスチェックの有効化

Nginxには、多くのビルドに軽量なステータスモジュールが含まれています。利用可能な場合は、ローカルのみのステータスエンドポイントを公開できます。

server {
    listen 127.0.0.1:8080;

    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

次に、サーバーからクエリを実行します。

curl http://127.0.0.1:8080/nginx_status

これにより、アクティブな接続とリクエストカウンターが表示されます。このエンドポイントはプライベートに保ってください。適切なネットワーク制御で保護されていない限り、公開しないでください。

本番監視では、Nginxのメトリクスとログを通常の可観測性スタックに接続してください。基本的なチェックは便利ですが、ダッシュボードとアラートは、離れている間に問題をキャッチするのに適しています。

構文だけでなく実際のシナリオをテスト

構文チェックは、動作が間違っていても成功する可能性があります。変更後は、変更した特定のパスまたはドメインをテストしてください。

リダイレクトを変更した場合は、古いURLと新しいURLの両方をテストします。

curl -I http://example.com/old-path

プロキシ設定を変更した場合は、APIルートをテストします。

curl -i https://api.example.com/health

静的ファイルの処理を変更した場合は、実際のアセットをリクエストします。

curl -I https://example.com/assets/app.css

よくあるシナリオとして、新しいシングルページアプリケーションを追加し、nginx -tが成功したとします。ホームページは機能しますが、/dashboardをリフレッシュすると404が返されます。これは構文の問題ではありません。通常、ロケーションブロックにtry_files $uri $uri/ /index.html;などのフォールバックが必要であることを意味します。

専門家の助けを求めるタイミング

リロードの失敗が本番環境に影響を与える場合、ステータスチェックがユーザーレポートと一致しない場合、またはエラーにアップストリームのタイムアウト、TLS障害、ロードバランサー、CDNの動作が同時に関係する場合は、DevOpsエンジニアまたはNginxスペシャリストに相談してください。

また、クラッシュが繰り返し発生する場合、説明のつかないワーカーの終了が発生する場合、または最後の設定変更をロールバックした後もエラーが続く場合も、エスカレーションする必要があります。問題はNginxの外部、例えばシステム制限、アプリケーションの障害、ネットワークルーティングにある可能性があります。

すべてのリロード前に構文をテストし、すべての変更後にステータスを監視し、ユーザーが依存する実際のURLの動作を検証してください。このシンプルな習慣により、ほとんどのNginx設定の問題が公のインシデントになる前にキャッチできます。