Test, reload, and roll back

A syntax error in Nginx configuration can take a working site offline. My workflow is test first, reload second, smoke test third, and keep the old file until all three pass.

reload is different from restart. Reload asks the master process to read new configuration and spin up fresh workers while old workers finish in-flight requests. Restart stops everything and starts cold. For production config changes, reload is what you want.

Before you edit anything, copy the current file:

sudo cp /etc/nginx/sites-available/app /etc/nginx/sites-available/app.bak

Make your change, then run the safe sequence:

Never reload an untested configuration:

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

Keep the previous configuration available before editing. After reload, request the exact hostname and path with curl. A successful syntax check cannot detect a wrong server block, upstream port, certificate name, or application response, so the external smoke test is part of the change.

nginx -t only checks syntax and file references. It does not know whether your upstream port is wrong or your certificate name mismatches the hostname. That is why the curl step matters:

curl -I https://app.example.com/health
# HTTP/1.1 200 OK

Request the exact hostname and path your users hit, not just 127.0.0.1. Virtual host selection depends on the Host header, and TLS depends on SNI.

If the smoke test fails, restore the backup and reload again:

sudo cp /etc/nginx/sites-available/app.bak /etc/nginx/sites-available/app
sudo nginx -t && sudo systemctl reload nginx

Because reload keeps old workers alive for open connections, a bad config can leave you with a mix of old and new behavior until those workers exit. The curl test catches that before you walk away.

Try a harmless change on a test server, like adding a response header. Test, reload, verify with curl, then restore the backup and repeat the same sequence.