Nginxサービス制御のための必須コマンドマスター

Nginxのサービス制御に必要なコマンドをマスターすることで、トラフィックを落とさずに安全に再起動や設定のリロードを行い、サーバーが応答しない原因を診断できるようになります。日常的なNginxの作業のほとんどは、注意深く使用する少数のコマンドに集約されます。

このガイドでは、systemdで管理されるNginxが動作するLinuxシステム（Ubuntu、Debian、CentOS、Rocky Linux、多くのクラウドイメージで一般的）での実用的なコマンド使用法に焦点を当てます。

例ではサービス名がnginxであることを前提としています。カスタムビルドやコントロールパネルでは異なるユニット名を使用する場合がありますが、パッケージ化されたNginxインストールでは通常この規則に従います。不明な場合は、一致するユニットをリストアップしてください：

systemctl list-units '*nginx*'
systemctl list-unit-files '*nginx*'

この小さな確認で、よくある間違い（実際には別のWebサーバーやコンテナがトラフィックを処理しているのに、間違ったサービスをトラブルシューティングしてしまう）を防げます。

Nginxが実行中か確認する

サービスのステータスから始めましょう：

sudo systemctl status nginx

これにより、Nginxがアクティブ、失敗、無効、またはまだ起動中かどうかが表示されます。また、systemdからの最近のログ行も表示され、起動やリロードが失敗した理由が含まれていることがよくあります。

最初の数行のステータスを注意深く読んでください。active (running)はsystemdがマスタープロセスが生きていると認識していることを意味します。failedは最後の起動またはリロード試行が失敗したことを示します。enabledまたはdisabledはブート時の動作を示し、現在サービスが実行中かどうかは示しません。

スクリプトで役立つ短い出力を得るには：

systemctl is-active nginx

出力にはactive、inactive、failed、activatingが含まれます。Nginxがブート時に有効かどうかだけを知りたい場合は：

systemctl is-enabled nginx

また、NginxがWebポートでリッスンしていることを確認できます：

sudo ss -ltnp | grep nginx

ポート80や443などのリスナーが表示されるはずです。サービスがアクティブでも期待されるポートがリッスンしていない場合は、listenディレクティブとインクルードされた設定ファイルを確認してください。

ssで何も表示されない場合は、別のプロセスが既にポートを占有していないか確認します：

sudo ss -ltnp 'sport = :80'
sudo ss -ltnp 'sport = :443'

ポートの競合は、Apache、Caddy、ローカル開発サーバー、同じポートを公開するコンテナランタイムをインストールした後によく発生します。その場合、Nginxを何度再起動しても解決しません。競合するサービスを停止するか、リスナーを変更する必要があります。

Nginxの起動、停止、再起動、リロード

Nginxが実行されていない場合はstartを使用します：

sudo systemctl start nginx

意図的にオフラインにする場合はstopを使用します：

sudo systemctl stop nginx

本番サーバーでのstopは注意してください。別のサーバーやロードバランサーがトラフィックを処理していない限り、すぐにサービスが利用できなくなります。

完全な停止と起動が必要な場合はrestartを使用します：

sudo systemctl restart nginx

再起動はシンプルですが、常に最良の選択とは限りません。特にビジーなサーバーや設定に起動の問題がある場合、アクティブな接続を中断する可能性があります。

再起動は、Nginxプロセス自体が異常な場合、モジュールやパッケージのアップデートで新しいプロセスが必要な場合、または意図的にワーカーの状態をクリアしたい場合に使用します。通常のサーバーブロックの編集、証明書パスの更新、アップストリームの変更、リダイレクト、ヘッダー変更には、通常リロードがより良い最初の選択肢です。

ほとんどの設定変更には、リロードを優先します：

sudo systemctl reload nginx

リロードは、Nginxマスタープロセスに新しい設定を読み込ませ、新しいワーカーを起動するよう指示します。古いワーカーは既存のリクエストを完了してから終了します。これが通常の変更適用方法で、中断が少なくなります。

実用的な例：api.example.com用の新しいサーバーブロックを追加した場合。まずsudo nginx -tを実行します。テストが成功したら、sudo systemctl reload nginxを実行します。既存の接続を使用しているユーザーは影響を受けないはずです。

Nginxに直接リロードを依頼することもできます：

sudo nginx -s reload

systemdシステムでは、ルーチン操作にはsystemctl reload nginxを推奨します。systemdがサービス状態とログの信頼できる情報源であり続けるためです。直接のnginx -s形式は、systemdが存在しない最小限のシステムやコンテナ内で依然として有用です。

リロードと再起動の違いを理解する

この区別は、多くの回避可能なダウンタイムを防ぎます。

リロードは、Nginxマスタープロセスに新しい設定を読み込ませ、新しいワーカーを起動するよう指示します。設定が有効な場合、新しいワーカーは新しい接続を受け入れ、古いワーカーは既存の作業を完了して終了します。これがリロードが通常の本番パスである理由です。

再起動はサービスを停止して起動します。タイミング、トラフィック、スーパーバイザーの動作によっては、クライアントが接続エラーを経験する可能性があります。また、Nginxが以前に有効な古い設定で実行されていて新しい設定で起動できない場合、小さな設定ミスが障害に変わる可能性があります。

安全なリズムは次のようになります：

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

リロードが失敗した場合、試行を続けないでください。正確なエラーを読み、ファイルを修正し、再度テストしてからリロードしてください。

変更を適用する前に設定をテストする

最も重要なコマンドは：

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は解析に失敗したファイルと行を教えてくれます。実際のミスはその行のすぐ上にあることが多く、特にブレースやセミコロンが欠落している場合です。

インクルードされたファイルを含む、完全にロードされた設定を表示するには：

sudo nginx -T

これは、どのファイルにディレクティブが含まれているかわからない場合に便利です。/etc/nginx/conf.d/、sites-enabled、またはパッケージ提供のスニペットからの驚きを明らかにすることができます。

nginx -Tは機密パス、アップストリーム名、時には埋め込まれた設定値を出力する可能性があります。完全な出力をチケット、チャット、公開フォーラムに貼り付ける際は注意してください。必要に応じてシークレットや内部ホスト名を編集してください。

複数のNginxインスタンスやカスタムプレフィックスを管理している場合は、設定ファイルを明示的に指定します：

sudo nginx -t -c /etc/nginx/nginx.conf

ほとんどのパッケージ化されたシステムでは-cは必要ありませんが、ステージングパスにある候補設定を比較する場合に便利です。

より詳細なコマンドチェックリストについては、Nginx設定のテストとステータス監視を参照してください。

サービス制御中にログを表示する

コマンドが失敗した場合、ログが理由を説明していることがよくあります。ジャーナルから始めます：

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

起動や再起動が失敗した場合は、時間枠を削除して最近のエントリを表示します：

sudo journalctl -u nginx -n 100 --no-pager

ライブログをフォローするには：

sudo journalctl -u nginx -f

Nginxは独自のログも書き込みます。通常はここにあります：

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

systemdジャーナルは、サービスの起動、停止、リロード、パーミッションエラーに最適です。Nginxエラーログは、アップストリームの失敗、ファイルの欠落、クライアントボディサイズ制限、TLS問題などのランタイム問題に最適です。

サーバーが複数のサイトをホストしている場合は、各サーバーブロックに独自のログファイルがあるか確認してください。ログを分離すると、サービス制御の変更を特定の壊れたドメインに関連付けるのがはるかに簡単になります。

リロード後、ジャーナルとエラーログの両方を1分間監視します：

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

リロードコマンドはすぐに戻るかもしれませんが、壊れたアップストリーム、欠落したルートディレクトリ、パーミッション問題は、最初の実際のリクエストがそのサーバーブロックにヒットしたときにのみ現れる可能性があります。

ブート時にNginxを有効または無効にする

再起動後にNginxを自動的に起動するには：

sudo systemctl enable nginx

有効にして一度に起動するには：

sudo systemctl enable --now nginx

自動起動を防ぐには：

sudo systemctl disable nginx

無効にしても現在実行中のサービスは停止しません。ブート時の動作のみを変更します。無効にして停止したい場合は、disableとstopの両方を実行します。

本番システムでは、メンテナンス後にブート動作を確認してください。手動起動後にサーバーが正常に見えても、Nginxが有効になっていないため、次の再起動後に復旧できない場合があります。

依存関係の順序を確認したい場合は、ユニットを検査します：

systemctl cat nginx
systemctl show nginx -p WantedBy -p After -p Requires

パッケージ化されたユニットファイルを直接編集しないでください。代わりにオーバーライドを使用します：

sudo systemctl edit nginx

これにより、systemdのオーバーライドディレクトリの下にドロップインが作成され、パッケージアップグレードがよりクリーンになります。ユニットオーバーライドを変更した後、以下を実行します：

sudo systemctl daemon-reload
sudo systemctl restart nginx

起動関係を理解している場合のみ、ユニット依存関係を変更してください。多くのNginxの問題は、systemd設定ではなくNginx設定に属します。

意図した場合のみシグナルを送信する

Nginxにはマスタープロセスとワーカープロセスがあります。マスターは設定を読み込み、ワーカーを管理し、シグナルに応答します。systemdはそのほとんどをユーザーから隠しており、通常の操作にはこれで十分です。

プロセスツリーを検査する必要がある場合：

ps -o pid,ppid,user,cmd -C nginx

通常、rootとして実行されている1つのマスタープロセスと、設定されたNginxユーザー（多くの場合www-data、nginx、またはディストリビューションによってはnobody）として実行されているワーカープロセスが表示されます。

直接シグナルも存在します：

sudo nginx -s reload
sudo nginx -s quit
sudo nginx -s stop

quitはグレースフルシャットダウンを要求します。stopはすぐに終了します。日常のシステム管理では、特別な理由がない限りsystemctlを使用してください。これにより、サービス状態、ログ、再起動動作が一元管理されます。

避けるべき一般的なコマンドの間違い

設定テストが失敗した後にリロードしないでください。リロードは失敗するはずですが、それに頼るのはずさんで、トラブルシューティングがよりノイズ多くなります。

通常のNginx制御にkill -9を使用しないでください。systemdとNginxマスタープロセスにワーカーを管理させてください。プロセスを強制終了すると、混乱した状態や切断された接続が残る可能性があります。

sites-availableのファイルを編集してアクティブだと想定しないでください。Debianスタイルのレイアウトでは、有効なファイルは通常sites-enabledのシンボリックリンクです。以下で確認します：

ls -l /etc/nginx/sites-enabled/

証明書ファイルのパーミッションを忘れないでください。リロード中にNginxが証明書やキーを読み取れない場合、HTTPSサーバーブロックのロードに失敗する可能性があります。

sudo systemctl status nginxですべてのサイトが動作することを証明できると想定しないでください。Nginxが実行中でも、1つのサーバーブロックが死んだアップストリームや間違ったドキュメントルートを指している可能性があります。

変更がHTTPS関連の場合、HTTPのみをテストしないでください。証明書チェーン、キーパーミッション、SNIマッチング、リダイレクト動作はすべてHTTPSチェックが必要です：

curl -I https://example.com/
openssl s_client -connect example.com:443 -servername example.com </dev/null

curl -Iは多くのチェックに十分です。openssl s_clientはより詳細で、特定の名前で提供される証明書を検査する必要がある場合に便利です。

安全な本番変更チェックリスト

小さなNginx設定変更には、繰り返し可能なチェックリストを使用します：

対象ファイルを編集します。
sudo nginx -tを実行します。
テストが失敗した場合、実行中のサービスに触れる前に設定を修正します。
sudo systemctl reload nginxを実行します。
sudo systemctl status nginx --no-pagerを確認します。
curlで影響を受けるURLをテストします。
エラーログに新しいメッセージがないか監視します。

例えば、リダイレクトを追加した後：

sudo nginx -t
sudo systemctl reload nginx
curl -I http://example.com/old-path
sudo tail -n 50 /var/log/nginx/error.log

リバースプロキシの変更の場合、実際のアップストリームパスをテストします：

curl -I https://api.example.com/health
sudo journalctl -u nginx --since "5 minutes ago" --no-pager

これは意図的に退屈です。設定編集によるNginxの障害のほとんどは、誰かがテストをスキップしたり、間違ったホストをリロードしたり、影響を受けるルートを確認しなかったりしたために発生します。

起動とリロードの失敗のトラブルシューティング

Nginxが起動しない場合、まず設定テストを実行します：

sudo nginx -t

構文が有効でも起動が失敗する場合は、ジャーナルを確認します：

sudo journalctl -u nginx -n 100 --no-pager

一般的な原因は次のとおりです：

別のプロセスが既にポート80または443を使用している。
証明書またはキーファイルのパスが間違っている。
NginxがパーミッションやSELinux/AppArmorポリシーのためにファイルを読み取れない。
参照されたディレクトリが存在しない。
nginx.confで設定された動的モジュールがパッケージ変更後に欠落している。

ポート競合の場合：

sudo ss -ltnp 'sport = :80'
sudo ss -ltnp 'sport = :443'

ファイル欠落の場合、Nginxのエラーメッセージを信頼してください。通常はパスを指定します。期待したパスではなく、書かれた通りのパスを確認します：

sudo ls -l /path/from/error/message

リロードが失敗してもNginxがまだ実行中の場合、古い設定がまだアクティブである可能性があります。それは良いニュースです：ユーザーはまだ影響を受けていないかもしれません。設定を修正し、再度テストし、再度リロードします。アクティブな設定がクリーンに起動できると確信できない限り、再起動しないでください。

サービス制御問題をエスカレーションするタイミング

パッケージアップグレード後にNginxが起動しない場合、本番サーバーでリロードが失敗する場合、またはsystemdが理解できないパーミッションやサンドボックスエラーを表示する場合、DevOpsエンジニアまたはLinux管理者に連絡してください。また、共有インフラストラクチャでユニットファイルを変更する前に助けを求めてください。

Nginxがロードバランサーの背後にある場合、ヘルスチェックやドレイン動作と調整して再起動を行ってください。ローカルコマンドが予想以上に広範囲に影響を与える可能性があります。

最も安全なリズムはシンプルです：ステータスを確認し、設定をテストし、可能な場合はリロードし、必要な場合のみ再起動し、変更後すぐにログを読みます。これらの習慣により、Nginxサービス制御はストレスの多いものではなく予測可能なものになります。