会中断，但非必然——关键在于是否配置 worker_shutdown_timeout。默认值为0，旧worker不等待连接完成即退出，导致WebSocket、keep-alive等连接被RST；设为30s等合理值可实现真正零中断。
会中断，但不是必然或不可控的——关键在于你有没有补上 worker_shutdown_timeout 这个被默认禁用的“安全阀”。
为什么 reload 看似平滑却实际断连
执行 nginx -s reload 时，主进程会启动新 worker、向旧 worker 发送 QUIT 信号。但默认情况下：
-
worker_shutdown_timeout值为 0（即不启用），旧 worker 不等待连接完成就直接关闭监听套接字 - 已建立的 WebSocket 连接、HTTP/1.1 keep-alive 复用连接、gRPC 流等，会在内核层面收到 RST 包，客户端立刻断开（如 WebSocket 报 1006）
- 监控中可见
nginx.connections.active断崖下跌，nginx.worker.processes.exiting激增
真正决定是否中断的核心参数：worker_shutdown_timeout
这个指令必须显式配置在 http{} 或 main{} 块中，它定义了旧 worker 在收到 QUIT 后最多等待多久才强制退出：
- 设为 30s：旧 worker 会持续处理已有请求，直到全部完成或超时，期间不再 accept 新连接
- 设为 0（默认）：立即停止 accept，并尽快退出——不等任何 pending response、sendfile 或流式响应结束
- 注意：该值不能超过
proxy_read_timeout或后端最长响应时间，否则可能卡住 worker
配套必须检查的三类配置
单靠 worker_shutdown_timeout 不够，还需协同调整：
- keepalive_timeout：确保客户端复用连接不会在 reload 前被 Nginx 主动关闭（建议 ≥60s）
-
proxy_read_timeout / proxy_send_timeout：若后端响应慢于
worker_shutdown_timeout，旧 worker 可能因超时提前退出，导致未发完的响应丢失 - 证书路径与权限无误：reload 成功 ≠ 证书生效；若私钥权限不对（如非 600）、证书链不完整、或配置中 ssl_certificate 写在 server 块外，新 worker 启动会失败或回退使用旧证书
验证 reload 是否真“零中断”的方法
别只看 nginx -t 和日志 “reloading”，要实测连接生命周期：
- 用
ss -tnp | grep :443观察 reload 前后 ESTAB 连接数是否平滑过渡（不应归零） - 对 WebSocket 长连接发起持续 ping，reload 期间确认无 1006 错误
- 抓包看是否有 RST 包突现；或查 error log 中是否出现
shutdown() failed或recv() failed - 执行
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -fingerprint -sha256，确认指纹已是新证书
