Every config change follows the same safe loop: test, then reload. Never edit and restart blindly — a syntax error on restart can leave the server down.

1. Test the configuration:

sudo nginx -t
# nginx: configuration file /etc/nginx/nginx.conf test is successful

nginx -t parses the whole config (all included files) and reports the exact file and line of any error. It does not apply anything.

2. Reload — zero downtime:

sudo nginx -s reload
# or, on systemd distros:
sudo systemctl reload nginx

A reload makes the master process start new worker processes with the new config and gracefully shut down the old ones after they finish in-flight requests. Existing connections aren’t dropped.

reload vs restart: reload re-reads config with no downtime. restart (systemctl restart nginx) fully stops and starts — it drops connections and will fail to come back up if the config is broken. Use restart only when changing something a reload can’t pick up (e.g. listen ports in some cases).

3. When it breaks — where to look:

# Service state and the most recent error (systemd):
sudo systemctl status nginx

# Live error log (start here for 502/504/permission issues):
sudo tail -f /var/log/nginx/error.log

# Access log (status codes, who hit what):
sudo tail -f /var/log/nginx/access.log

# What's actually listening:
sudo ss -ltnp | grep nginx

Handy extras:

nginx -T (capital T) prints the entire merged configuration — invaluable for finding which file set a directive.
nginx -V shows the build’s version and compiled-in modules (check here for http_v2, brotli, etc.).
A 502 Bad Gateway almost always means the upstream app isn’t running or the proxy_pass address is wrong; 504 means it’s too slow (raise proxy_read_timeout). The error log names the cause.

Test the config and reload without downtime