Reload nginx instead of restarting it. A reload sends a HUP signal to the master process, which checks the configuration, starts new workers with the new certificate and lets old workers finish their current requests before they exit. If the check fails, nginx keeps serving with the old setup.
What happens during a reload
The nginx control documentation describes it step by step. The master process first checks the syntax of the new configuration, then tries to apply it, which includes opening log files and listening sockets. If that fails, it rolls back and carries on with the old configuration. If it succeeds, it starts new worker processes and asks the old ones to shut down gracefully. Old workers close their listen sockets and keep serving existing clients, and exit after all of them are done.
That graceful hand over is why a reload does not drop connections, and why a bad config does not take your site down.
Steps after a renewal
- Make sure the new files are in place. With Certbot, point nginx at fullchain.pem and privkey.pem. See the chain file.
- Test the configuration:
nginx -t
- Reload:
nginx -s reload
- Verify what clients receive, not what is on disk:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
Compare the date with the new certificate. If it shows the old date, the reload did not pick up the files you think it did, or another server in front still holds the old one.
- Automate it. Put the reload in your renewal deploy hook. See testing Certbot renewal.
Common ways it goes wrong
- Renewed but never reloaded. The file on disk is new while the process still serves the old one in memory. This is a classic cause of an expiry outage that renewal logs say should not have happened.
- Several nodes. A reload on one host leaves others on the old certificate. Roll the reload across the fleet and check each.
- Permissions. The master reads files as it starts new workers, so check the key file is readable by the master process.
- A proxy in front. A load balancer may have its own certificate. See TLS termination at the proxy.
A deploy hook that fails safely
Write the hook so it runs the config test first and reloads once the test passes. If the test fails, send an alert and leave the old certificate serving. A broken hook that restarts a healthy server is worse than a late renewal.
If a reload is not enough
QUIC connections need an extra setting to survive a reload, according to the docs. Plan a rolling replacement of instances for deployments that rely on it, and test it during a quiet period.
Where Safeguard fits
Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
Does nginx -s reload drop active connections?
No. Old workers finish serving their clients before they exit.
What if my new config has an error?
nginx rolls back and keeps running with the old configuration.
Sources
Last reviewed: 19 October 2026.
