Nginx reads its configuration at start-up. A change to a file does nothing until you tell it to re-read, and how you tell it decides whether anyone notices.

Always test first

nginx -t

It parses everything and names the file and line of anything it does not like. It changes nothing. There is no reason ever to skip it.

Reload, do not restart

  • reload - starts new workers with the new config, lets the old ones finish what they are doing, then retires them. No connection is dropped.
  • restart - stops everything and starts again. Every request in flight fails.
systemctl reload nginx
A reload with a broken config does NOT break the site: Nginx refuses the new config and keeps running the old one. A restart with a broken config leaves the site down. That alone is the reason to reload.

When a restart is genuinely needed

  • Changing the user Nginx runs as.
  • Adding a module.
  • Changing anything in the main context that cannot be applied to running workers.

Keep the change reversible

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

Check what is actually loaded

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

Capital T prints the whole running configuration with every include resolved, which is the only way to be sure a file you edited is the one being used.

If a change appears to do nothing, check for a second server block matching the same name. The first match wins, and a stale file in sites-enabled is the usual reason.