再起動ではなく再読み込みを使う
再読み込みは、NGINXに設定を読み直すよう指示します。新しいワーカープロセスが起動し、古いプロセスは処理中のリクエストを完了してから終了するため、通常、訪問者は何も気づきません。新しい設定を適用できない場合、NGINXは古い設定で動作を続けます。再起動は先にサービスを停止するため接続が切断され、設定に誤りがあると再び起動できないこともあります。
変更するファイルをバックアップする
編集前に、日付を名前に含めたコピーを元のファイルの隣に作成します。conf.d/*.confやsites-enabled/*のようなワイルドカードでNGINXが読み込むディレクトリには、コピーを残さないでください。コピーも読み込まれてしまいます。DebianやUbuntuではsites-available内のファイルを編集します。sites-enabled内の項目は、通常そのファイルへのリンクです。
sudo cp -a /etc/nginx/sites-available/example.conf /root/example.conf.$(date +%Y%m%d-%H%M%S)検証してから再読み込みする
nginx -tは構文と、証明書など設定が参照するファイルを検証します。nginx -Tを使うと、インクルードを展開した完全な設定を確認できます。検証に成功した場合だけ再読み込みしてください。コマンドを&&でつなぐと、この条件を満たせます。検証では設定が意図した動作をするかまでは判断できないため、その後にサイトを開いて確認してください。
sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | less
curl -I https://example.com/問題が起きた場合
バックアップを復元し、再度検証してから再読み込みします。サービスが停止した場合は、エラーログとjournalで原因を確認できます。ポートがすでに使用中、証明書が存在しない、サーバー名が重複している、といったメッセージを探してください。
sudo cp -a /root/example.conf.20261031-120000 /etc/nginx/sites-available/example.conf
sudo nginx -t && sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log再読み込みで対応できないこと
WebSocketsなどの長時間接続は終了するまで古いワーカーに残るため、古いワーカーがしばらく動き続け、追加のメモリを使う場合があります。パッケージのアップグレード時には、サービスが自動で再起動されることもあります。大きな変更は、証明書やリダイレクトも含めて、まずテストサーバーで検証してください。
CH-J Server ManagerのNGINX Manager
NGINX ManagerはLinuxサーバー上の管理対象NGINXディレクトリにある設定ファイルを、1ファイル512 KiBまで編集できます。保存時には、アプリが.chj-backup-という接尾辞を付けたバックアップを作成してnginx -tを実行し、検証が成功した場合だけ変更を保持します。再読み込みにはユーザーの明示的な確認が必要で、開始前に検証をもう一度実行します。sites-enabledにある有効化用のシンボリックリンクは置き換えません。対応するsites-available内のファイルを編集してください。