nginx本身不会因ssl证书过期崩溃，但客户端会强制拦截连接并显示“您的连接不是私密连接”等错误；必须验证新证书notafter时间晚于2026年7月7日，确认配置路径正确、权限合规（私钥600、证书644）、fullchain.pem完整，执行nginx -t后平滑reload，并同步多节点、闭环验证生效。
Nginx 本身不会因 SSL 证书过期而崩溃或停止服务，但客户端（浏览器、App、API 调用）会主动拒绝连接，表现为“您的连接不是私密连接”“NET::ERR_CERT_DATE_INVALID”等错误——这不是 Nginx 故障，而是 TLS 握手被终端强制终止。真正要做的，不是“修复过期证书”，而是快速、可靠、无感地完成新证书部署与生效。
确保新证书已就绪且路径正确
- 用
openssl x509 -in /path/to/fullchain.pem -noout -dates验证新证书的notAfter时间（当前是 2026年7月7日，需确保该时间晚于此时）。 - 检查 Nginx 配置中
ssl_certificate和ssl_certificate_key是否指向新文件，且写在server { ... }块内（不能放在http或main块中）。 - 私钥权限必须为
600（chmod 600 privkey.pem），证书文件建议644；权限错误会导致 Nginx 静默降级使用旧证书。 -
ssl_certificate必须是fullchain.pem（含域名证书 + 中间 CA），而非仅cert.pem；否则部分 Android/iOS 设备握手失败。
平滑重载，避免连接中断
- 执行前先验证：
nginx -t—— 配置语法错误会导致 reload 失败，Nginx 自动回退到旧配置，看似成功实则证书未更新。 - 重载用
nginx -s reload（非restart），它只替换 worker 进程，不中断已有连接。 - 关键参数必须设置：
-
worker_shutdown_timeout 30s;（写在http{}或main{}块）——让旧 worker 最多再服务 30 秒，处理完正在传输的请求； -
keepalive_timeout 60s;—— 防止 reload 前复用连接被提前关闭； -
proxy_read_timeout和proxy_send_timeout≥worker_shutdown_timeout—— 避免代理超时强制中断响应； -
ssl_session_timeout 4h;—— 提升 TLS 会话复用率，减少握手开销。
-
多节点环境必须同步更新
- 不要逐台手动复制证书。统一使用软链接（如
/etc/nginx/ssl/current.crt → /etc/nginx/ssl/live/example.com/fullchain.pem），更新时只改链接目标。 - 所有节点执行相同操作：先
nginx -t，再nginx -s reload；配合健康检查（如location /health { return 200; }）确认就绪后再切流。 - 若用 Certbot，务必配置
--deploy-hook "/usr/sbin/nginx -s reload"或--post-hook，避免证书更新了但 Nginx 没重载。
验证是否真正生效
- 不依赖浏览器刷新：用
curl -vI https://yoursite.com 2>&1 | grep "subject:"或openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -dates直接读取服务端返回的证书有效期。 - 对 WebSocket 长连接持续 ping，确认 reload 期间无
1006错误；观察ss -tn state established | grep :443 | wc -l，reload 前后 ESTAB 连接数应平滑过渡，不归零。
证书过期不是配置问题，而是运维事件。核心在于建立自动化续期（如 Certbot + cron + deploy-hook）、集中分发、参数协同与闭环验证——把“救火”变成“值守”。
