Recharger plutôt que redémarrer
Un rechargement demande à NGINX de relire la configuration. Il lance de nouveaux processus de travail et laisse les anciens terminer leurs requêtes en cours, de sorte que les visiteurs ne remarquent généralement rien. Si la nouvelle configuration ne peut pas être appliquée, NGINX continue de fonctionner avec l’ancienne. Un redémarrage arrête d’abord le service, ce qui interrompt les connexions, et le service risque de ne pas redémarrer si la configuration est incorrecte.
Sauvegarder le fichier à modifier
Avant toute modification, créez une copie à côté du fichier, avec la date dans son nom. Ne laissez pas de copies dans un répertoire que NGINX charge avec un motif contenant des caractères génériques, comme conf.d/*.conf ou sites-enabled/*, car elles seraient chargées elles aussi. Sous Debian et Ubuntu, modifiez le fichier dans sites-available ; l’entrée dans sites-enabled n’est généralement qu’un lien vers celui-ci.
sudo cp -a /etc/nginx/sites-available/example.conf /root/example.conf.$(date +%Y%m%d-%H%M%S)Tester, puis recharger
nginx -t vérifie la syntaxe et les fichiers auxquels la configuration fait référence, notamment les certificats. Utilisez nginx -T pour afficher la configuration complète après intégration des fichiers inclus. Ne rechargez que si le test réussit ; relier les commandes avec && vous le garantit. Le test ne peut pas déterminer si la configuration produit le comportement voulu : ouvrez donc ensuite le site web.
sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | less
curl -I https://example.com/En cas de problème
Restaurez la copie de sauvegarde, testez à nouveau et rechargez. Si le service s’est arrêté, le journal d’erreurs et le journal système en indiquent la cause. Recherchez des messages concernant un port déjà utilisé, un certificat manquant ou un nom de serveur en double.
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.logCe qu’un rechargement ne couvre pas
Les connexions de longue durée, comme WebSockets, restent attachées aux anciens processus de travail jusqu’à leur fermeture. Ces processus peuvent donc continuer à fonctionner un certain temps et consommer de la mémoire supplémentaire. Une mise à niveau de paquet peut redémarrer le service d’elle-même. Testez d’abord les changements importants sur un serveur de test, y compris les certificats et les redirections.
NGINX Manager dans CH-J Server Manager
NGINX Manager modifie les fichiers de configuration dans les répertoires NGINX gérés sur les serveurs Linux, jusqu’à 512 KiB par fichier. Lors de l’enregistrement, l’application crée une sauvegarde avec le suffixe .chj-backup-, exécute nginx -t et ne conserve la modification qu’après un test réussi. Un rechargement nécessite votre confirmation explicite et relance le test avant de commencer. Un lien symbolique activé n’est pas remplacé ; modifiez le fichier correspondant dans sites-available.