Nginx lit sa configuration au démarrage. Modifier un fichier ne fait rien tant que vous ne lui demandez pas de relire, et la façon dont vous le lui demandez décide si quelqu'un s'en rend compte.

Toujours tester d'abord

nginx -t

Il analyse tout et nomme le fichier et la ligne de ce qui lui déplaît. Il ne change rien. Il n'y a jamais de raison de s'en passer.

Recharger, pas redémarrer

  • reload - lance de nouveaux workers avec la nouvelle configuration, laisse les anciens finir ce qu'ils font, puis les retire. Aucune connexion n'est perdue.
  • restart - arrête tout et repart. Toute requête en vol échoue.
systemctl reload nginx
Un reload avec une configuration cassée ne casse PAS le site : Nginx refuse la nouvelle et continue avec l'ancienne. Un restart avec une configuration cassée laisse le site à terre. Cela seul justifie de recharger.

Quand un redémarrage est vraiment nécessaire

  • Quand change l'utilisateur sous lequel Nginx tourne.
  • Quand on ajoute un module.
  • Quand on change dans le contexte principal quelque chose que des workers en cours ne peuvent pas reprendre.

Garder le changement réversible

cp /etc/nginx/sites-available/mysite{,.bak-$(date +%F)}
# edit, test, reload
# and if it is wrong:
cp /etc/nginx/sites-available/mysite.bak-2026-09-04 /etc/nginx/sites-available/mysite
nginx -t && systemctl reload nginx

Vérifier ce qui est réellement chargé

nginx -T | grep -A5 "server_name yourdomain.com"

Le T majuscule imprime toute la configuration en service, chaque include résolu : c'est le seul moyen d'être sûr que le fichier que vous avez modifié est bien celui qui sert.

Si un changement semble sans effet, cherchez un second bloc serveur portant le même nom. Le premier trouvé l'emporte, et un vieux fichier dans sites-enabled en est la raison habituelle.