Nginxサービス制御：一般的な管理コマンドの実践ガイド
開始、停止、リロード、再起動、ステータス確認、設定テスト、ログ、直接シグナルなど、Nginxサービス制御の実践的なコマンド。
Nginxサービス制御：一般的な管理コマンドの実践ガイド
Nginxのサービス制御は複雑ではありませんが、実際のユーザーが接続している状況では、reload、restart、stop、nginx -s quitの違いが重要です。最も安全な習慣はシンプルです。まず設定をテストし、グレースフルリロードで十分な場合はリロードし、完全なサービスサイクルが必要な場合にのみ再起動します。
最近のLinuxサーバーのほとんどはsystemdを使用しているため、systemctlが最もよく使われるコマンドになります。古いディストリビューションでは、まだserviceコマンドを使用している場合があります。Nginxバイナリは直接シグナルも受け付けており、サービス管理ツールを経由せずに設定のリロードやログの再オープンを行う場合に便利です。
Nginxサービス管理の理解
Nginxのサービス管理コマンドは、通常、systemctl（systemdを使用するシステム向け。最近のLinuxディストリビューションで一般的）やservice（古いinitシステム向け）などのシステムユーティリティを使用して実行されます。具体的なコマンドは、オペレーティングシステムとそのサービス管理フレームワークによって多少異なる場合があります。
Nginxの起動
Nginx Webサーバーを起動するには、startコマンドを使用します。このコマンドはNginxプロセスを開始し、着信接続を受け入れられる状態にします。
systemctlを使用する場合（最近のシステムに推奨）：sudo systemctl start nginxserviceを使用する場合（古いシステム向け）：sudo service nginx start
Nginxが起動すると、設定ファイルを読み込み、設定で指定されたポート（通常はHTTP用の80番ポートとHTTPS用の443番ポート）でリッスンを開始します。
Nginxの停止
Nginx Webサーバーをグレースフルにシャットダウンするには、stopコマンドを使用します。このコマンドはNginxに新しい接続の受け入れを停止し、既存の接続が完了してから終了するように指示します。
systemctlを使用する場合：sudo systemctl stop nginxserviceを使用する場合：sudo service nginx stop
systemdシステムでは、stopはサービス管理ツールにNginxの停止を要求します。アクティブなリクエストが完了する時間があるかどうかは、サービスの設定とシグナルの動作に依存します。特にNginxレベルのグレースフルシャットダウンが必要な場合は、sudo nginx -s quitが直接的なコマンドです。
Nginxの再起動
restartコマンドは、stopとstartを組み合わせたものです。大幅な設定変更を行い、その変更を有効にするために完全なサービスサイクルが必要な場合によく使用されます。このコマンドはサービスを一時的に中断するため、注意して使用してください。
systemctlを使用する場合：sudo systemctl restart nginxserviceを使用する場合：sudo service nginx restart
これは、特定の種類の設定更新を適用するための一般的なコマンドです。
Nginxのリロード
reloadコマンドは、アクティブな接続を切断せずに設定変更を適用するための、最も便利なNginxコマンドの1つです。Nginxはワーカープロセスをグレースフルに再起動し、新しい設定を適用します。これは、ほとんどの設定更新で推奨される方法です。
systemctlを使用する場合：sudo systemctl reload nginxserviceを使用する場合：sudo service nginx reload
ヒント： ダウンタイムを最小限に抑えるために、可能な限りrestartではなくreloadを使用するようにしてください。
新しい設定が無効なためにリロードが失敗した場合、通常、古いワーカープロセスは古い設定で動作を続けます。これが、ルーチン編集時にリロードが再起動よりも安全である理由の1つです。それでも、常に最初にnginx -tを実行して、インシデント発生時の失敗動作に依存しないようにしてください。
Nginxのステータス確認
Nginxが実行中かどうか、障害が発生していないか、現在の状態を確認するには、statusコマンドを使用します。
systemctlを使用する場合：sudo systemctl status nginxserviceを使用する場合：sudo service nginx status
このコマンドは、サービスがアクティブかどうか、プロセスID（PID）、最近のログエントリなど、迅速な診断に役立つ貴重な情報を提供します。
Nginx設定のテスト
設定変更を適用する前、特にrestartやreloadの後は、設定ファイルに構文エラーがないかテストすることが重要です。Nginxにはこのための組み込みコマンドがあります。
設定構文のテスト
このコマンドは、変更を実際に適用せずに、Nginx設定全体の構文エラーをチェックします。問題が見つかった場合は報告します。
nginx -t
出力例（成功）：
test is successful
nginx: configuration file /etc/nginx/nginx.conf test is successful
出力例（エラー）：
nginx: [emerg] unknown directive "server_name " in /etc/nginx/sites-available/default:10
nginx: configuration file /etc/nginx/nginx.conf test failed
警告： 設定ファイルを変更した後、Nginxをリロードまたは再起動する前に、必ずnginx -tを実行してください。この簡単な手順で、構文エラーによる予期しないダウンタイムを防ぐことができます。
カスタムのメイン設定ファイルを使用している場合は、明示的に指定します。
sudo nginx -t -c /path/to/nginx.conf
インクルードされたファイルを含む、ロードされた完全な設定を表示するには、次を使用します。
sudo nginx -T
共有端末やチケットでnginx -Tを使用する場合は注意してください。設定ファイルからの機密性の高いパス、アップストリーム名、コメントが出力される可能性があります。
起動時にNginxを有効にする
Nginxを一度起動することと、再起動後に有効にすることは異なります。systemdシステムでは、次を使用します。
sudo systemctl enable nginx
すぐに有効にして起動するには：
sudo systemctl enable --now nginx
起動時に自動的に起動しないようにするには：
sudo systemctl disable nginx
これはパッケージインストール後に便利です。セットアップ中に手動でNginxを起動し、数週間は問題なく動作していたものの、メンテナンス再起動後にサービスが有効になっていなかったためにダウンしたままになったサーバーを何度か見たことがあります。
サービスアクション後のログ確認
起動またはリロードに失敗した後は、コマンドプロンプトを見つめないでください。systemdとNginxに何が起こったのかを尋ねてください。
sudo journalctl -u nginx -n 100 --no-pager
そして、Nginxエラーログを確認します。
sudo tail -n 100 /var/log/nginx/error.log
何を探せばよいかがわかれば、一般的なメッセージは十分に直接的です。
bind() to 0.0.0.0:80 failed：別のプロセスがすでにそのポートを使用しているか、権限が正しくありません。unknown directive：タイポ、モジュールの欠落、または間違ったNginxビルドで使用されたディレクティブ。host not found in upstream：DNSが失敗したか、アップストリーム名が間違っています。permission denied：Nginxがファイルを読み取れない、ログを書き込めない、または証明書キーにアクセスできません。
ポート競合の場合、通常はこれで答えが得られます。
sudo ss -ltnp | grep -E ':80|:443'
別のWebサーバーが同じポートでリッスンしている場合は、どのサービスがそれを所有するかを決定します。理由がわからない限り、プロセスを強制終了しないでください。
実際の状況におけるリロードと再起動
ほとんどの設定編集後はreloadを使用します。新しいサーバーブロック、プロキシヘッダーの変更、タイムアウト値の更新、新しいリダイレクト、ログ形式の変更、静的ファイルの場所の調整などです。Nginxは新しい設定で新しいワーカーを起動し、古いワーカーは既存の作業を完了させます。
サービス自体をクリーンに起動する必要がある場合はrestartを使用します。例としては、systemdの制限の変更、サービスが継承する環境の変更、バイナリが変更されたパッケージアップグレード、マスタープロセスが異常な状態の場合などがあります。再起動はトラフィックを一時的に中断する可能性があるため、意図的に行ってください。
サービスを停止したい場合はstopを使用します。これは明白に聞こえますが、メンテナンス中は重要です。Nginxを停止した後もロードバランサーがサーバーにトラフィックを送信し続けると、ユーザーはエラーを目にすることになります。可能な場合は、先にサーバーをロードバランサーからドレインしてください。
ログローテーション後にnginx -s reopenを使用します。ローテーションプロセスがNginxにシグナルを送信しない場合、Nginxは表示上のログファイルが移動した後も、古いファイルハンドルに書き込み続ける可能性があります。
パッケージ名とサービス名
ほとんどのディストリビューションではサービスをnginxと呼びますが、すべての環境が同一とは限りません。systemctl status nginxでユニットが存在しないと言われた場合は、一致するユニットをリストします。
systemctl list-unit-files | grep -i nginx
一部のホストでは、Nginxがカスタムパッケージ、コンテナ、コントロールパネル、またはバンドルされたスタックからインストールされている場合があります。そのような場合、systemdコマンドは実際に使用しているインスタンスを制御できない可能性があります。バイナリと設定パスを確認します。
which nginx
nginx -V
nginx -Vはビルドオプションとモジュールパスを出力します。これは、あるサーバーでは設定ディレクティブが機能するが、別のサーバーではモジュールが欠落しているために機能しない場合にも役立ちます。
NginxがDockerで実行されている場合、ホスト上のサービスコマンドは無関係かもしれません。代わりに、コンテナワークフローを通じて検査およびリロードします。
docker ps
docker exec <container> nginx -t
docker exec <container> nginx -s reload
プロセスを所有するオーケストレーションツールを使用します。Kubernetesの場合、通常はConfigMapまたはIngressリソースを変更し、コントローラーにリロードさせることであり、永続的な修正のためにポッドにシェルアクセスすることではありません。
インシデント発生時のコマンドシーケンス
設定変更によってリロードが壊れた場合：
sudo nginx -t
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log
nginx -tで表示された最初の構文エラーまたはファイルエラーを修正し、再度テストします。構文テストですでに機能しないと示されているのに、サービスを再起動して「動作するかどうか」を確認しないでください。
サイトがダウンしていて、Nginxが実行されているかどうかわからない場合：
sudo systemctl status nginx
sudo ss -ltnp | grep -E ':80|:443'
curl -I http://127.0.0.1/
これにより、3つの質問が分離されます。サービスはアクティブか、期待されるポートで何かがリッスンしているか、ローカルHTTPリクエストは機能するか。ローカルのcurlは機能するがパブリックサイトが機能しない場合は、DNS、ファイアウォールルール、クラウドセキュリティグループ、ロードバランサー、TLSを確認します。
証明書更新後にHTTPSが失敗した場合：
sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager
証明書パスの間違いは通常、構文テストまたはエラーログに表示されます。証明書キーがrootで読み取り可能だが、Nginxワーカーユーザーが必要なディレクトリにアクセスできない場合、権限の問題も一般的です。秘密鍵の権限には注意してください。エラーを黙らせるためだけに、誰でも読み取り可能にしないでください。
ローテーション後にログの更新が停止した場合：
sudo nginx -s reopen
sudo ls -l /var/log/nginx/
sudo tail -f /var/log/nginx/access.log
多くのlogrotateパッケージはすでにこれを処理しています。このコマンドは、手動でログをローテーションする場合や、カスタムログ設定を実行する場合に依然として役立ちます。
やってはいけないこと
通常の管理方法として、Nginxワーカープロセスに対してkill -9を実行しないでください。プロセスに作業を完了したりクリーンアップしたりする機会を与えません。本当にスタックしたプロセスに対処していて、副作用を理解している場合を除き、systemctl stop、systemctl restart、またはNginxシグナルコマンドを使用してください。
sites-availableのファイルを編集し、それらがアクティブであると想定しないでください。Debianスタイルのレイアウトでは、通常、サイトを有効にするためにsites-enabledにシンボリックリンクが必要です。他のディストリビューションでは、レイアウトがconf.dを使用する場合があります。nginx -Tは、Nginxが実際に何をロードしているかを確認する最も速い方法です。
sudoを忘れないでください。権限のないユーザーとしてnginx -tを実行すると、サービス自体は読み取れる場合でも、証明書キーやインクルードされたファイルを読み取れないために失敗する可能性があります。サービスが本番環境で実行されるのと同じ方法でテストします。
sudo nginx -t
反射的に再起動を使用しないでください。再起動には役割がありますが、リロードよりも負荷がかかります。静かなメンテナンスウィンドウ中は問題にならないかもしれません。忙しいセールスイベント中は問題になります。
Nginxプロセスの管理（上級者向け）
systemctlとserviceはNginxサービス全体を管理するための主要なツールですが、特定のシグナルを使用してnginxコマンドでNginxマスタープロセスと直接対話することもできます。
Nginxへのシグナル送信
Nginxはワーカープロセスを管理するマスタープロセスを使用します。マスタープロセスにシグナルを送信して、その動作に影響を与えることができます。これを行う最も一般的な方法は、マスタープロセスのPIDを見つけてkillコマンドを使用するか、より便利な方法としてnginx -s <signal>を使用することです。
設定のリロード： 上記の
reloadコマンドと同様です。sudo nginx -s reloadグレースフルシャットダウン：
stopコマンドと同様です。sudo nginx -s quit高速シャットダウン： 現在のリクエストが処理されるのを待たずに、すべてのワーカープロセスを即座に強制終了します。
sudo nginx -s stopログファイルの再オープン： ログファイルを手動でローテーションする場合や、ログが別の場所に書き込まれている場合に便利です。
sudo nginx -s reopen
nginx -s <signal>を使用するには、NginxがマスタープロセスのPIDファイルの場所を知っている必要があります。デフォルトでは、これは多くの場合/var/run/nginx.pidまたは/run/nginx.pidです。必要に応じて-cオプションを使用して別のPIDファイルの場所を指定できますが、標準的なインストールではこれはほとんど必要ありません。
安全な日常ワークフロー
通常の設定編集には、次のワークフローを使用します。
sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx
次に、クライアントからサイトを確認します。
curl -I https://example.com/
サービスの起動に失敗した場合は、再起動を繰り返さないでください。ステータス出力とログを読み、最初の実際のエラーを修正し、再度テストしてから、起動またはリロードを行ってください。Nginxサービス制御コマンドは小さいですが、正しい順序で使用することで、設定ミスが回避可能なダウンタイムになるのを防ぎます。