Nginx SSL证书热替换本质是配置重载触发worker进程平滑重启，需确保证书文件原子覆盖、路径不变、权限正确，并通过nginx -t校验后执行nginx -s reload，避免强制重启。

Nginx 的 Master 进程信号机制本身**不直接参与 SSL 证书加载**，证书替换本质上是配置重载（reload）触发的 worker 进程平滑重启过程。所谓“热替换”，实际是通过 `nginx -s reload` 或发送 `SIGHUP` 给 master 进程，让新 worker 加载更新后的证书文件，而旧 worker 继续处理已有连接，实现无中断切换。 关键在于：证书文件必须提前就位、路径不变、权限正确，且 reload 操作本身不能出错。 以下为可落地的操作要点：

确保证书文件已就绪且路径未变更

新证书（如 fullchain.pem）和私钥（如 privkey.pem）需覆盖写入到 Nginx 配置中指定的绝对路径，例如：
ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;
覆盖时建议用 原子写入（如先写临时文件再 mv 替换），避免 reload 期间读到截断或空文件。

验证配置并执行安全重载

每次证书更新后必须校验语法和证书有效性：

• 运行 nginx -t —— 确认配置无误且能成功读取新证书（会检查 PEM 格式、密钥匹配、过期时间等）
• 若通过，执行 nginx -s reload 或 kill -HUP $(cat /var/run/nginx.pid)
• 不要用 service nginx restart，它可能强制 kill 所有进程，破坏连接连续性

观察新旧 worker 并存状态

reload 后，master 会启动新 worker，同时保留旧 worker 直至其处理完所有活跃连接（包括 TLS 握手中的长连接）。可通过以下方式确认过渡正常：

SSL Certificate Monitor

检查一个或多个域名的 SSL/TLS 证书到期时间、颁发者、协议及 SAN 信息，用于应要求检查证书、监控到期或验证 HTTPS 等场景。

下载

• ps aux | grep nginx —— 应短暂看到新旧 worker 进程共存
• ss -tnp | grep :443 —— 查看 ESTABLISHED 连接是否持续存在，且新连接逐步由新 worker 接入
• 用 openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates 验证返回的证书有效期是否已更新

自动化场景下的注意事项

若集成到 Let’s Encrypt 自动续期（如 certbot），务必禁用 --deploy-hook "systemctl restart nginx" 类强制重启，改用：

• --deploy-hook "nginx -s reload"
• 或更稳妥地，在 hook 中先 nginx -t && nginx -s reload，失败时不中断流程
• 确保 certbot 运行用户对 Nginx 配置目录和证书路径有读取权限（尤其私钥）

整个过程不依赖 Master 进程“主动加载”证书，而是靠配置重载驱动 worker 进程自我更新。只要 reload 成功且证书文件有效，TLS 层就能无缝切换，客户端无感知。