Test Nginx Configuration Before Reloading
Use Nginx's configuration test, inspect included files, and reload without replacing healthy workers with a broken configuration.
Photo: Unsplash.
After editing Nginx configuration, test the complete configuration tree before sending a reload:
sudo nginx -tThe test checks syntax and tries to open files referenced by the configuration. A missing certificate, unreadable key, duplicate listener, or broken included file can therefore fail even when the line you edited looks correct.
Only reload after a successful test:
sudo nginx -t && sudo systemctl reload nginxA reload is not the same as a restart. Nginx’s master process reads and validates the new configuration, starts new workers when it can apply the change, and lets old workers finish existing requests. If applying the configuration fails, the existing workers remain in place.
When the source of a directive is unclear, dump the expanded configuration:
sudo nginx -T-T includes the contents of loaded configuration files, which is excellent for finding an unexpected server block or include order. Treat its output carefully: configuration can contain internal hostnames, paths, or embedded credentials. Do not paste it into a public issue without review.
After reload, verify behavior from outside the host:
curl --fail --silent --show-error https://example.com/healthFor TLS changes, inspect the certificate actually served, not only the file on disk. The useful pattern is test, reload, and then verify one real request. Stopping after nginx -t proves the file is acceptable; it does not prove the running service received or behaves correctly with it.