worker_shutdown_timeout对WebSocket完全无效，因Nginx不解析WebSocket帧，无法感知消息边界，仅能等待TCP keepalive超时或客户端断开；到期强制kill导致帧截断、连接异常中断及aborting告警。
worker_shutdown_timeout 对 WebSocket 连接完全无效，强行依赖它做 reload，只会导致消息截断、连接异常中断、客户端重连风暴。
为什么 worker_shutdown_timeout 在 WebSocket 场景下不生效
Nginx 的优雅关闭逻辑只对 HTTP 请求边界敏感：它能识别 Content-Length、Transfer-Encoding: chunked 或请求头结束位置，从而判断一个请求是否“处理完毕”。但 WebSocket 是基于 TCP 的全双工长连接，Nginx 在反向代理模式下仅做帧透传（L7 proxy），不解析任何 WebSocket 帧（如 0x81、0x88、二进制 opcode），也无法感知应用层消息是否已发完、是否正在收包。
这意味着：
- 旧 worker 进程收到
QUIT信号后，会立即关闭监听套接字，但对已建立的 WebSocket 连接，只能等待内核 TCP keepalive 超时（默认 2 小时）或客户端主动断开； -
worker_shutdown_timeout到期后触发的是强制 kill，此时未完成的帧传输被内核丢弃，TCP 连接 abrupt close，客户端收到WebSocket is closed before the connection is established或error event； - 日志中频繁出现
open socket left in connection和aborting，正是 socket 未 clean up 的直接证据。
proxy_read_timeout 和 proxy_send_timeout 才是 WebSocket 的关键配置
这两个参数决定 Nginx 保持空闲 WebSocket 连接的时间上限，它们直接影响连接是否被误杀——而不是 worker_shutdown_timeout。
常见错误配置：
- 保留默认值（60s），导致活跃但无心跳的连接被静默关闭；
- 设得过短（如 10s），在弱网或服务端处理延迟时频繁触发重连；
- 设得过长（如 7200s），虽保连接但放大故障影响面（旧 worker 拖更久）。
推荐实践：
- 设为业务最大空闲容忍时间，例如
proxy_read_timeout 3600（1 小时），配合客户端每 30 秒发一次 ping； -
proxy_send_timeout应 ≥proxy_read_timeout，避免响应未发完就被断； - 禁用
proxy_buffering on，改用proxy_buffering off，防止 Nginx 缓存未发送帧造成延迟断连感知。
真正可行的平滑重启路径：三方协同 draining
单靠 Nginx 参数无法实现 WebSocket 优雅重启，必须后端、Nginx、客户端共同配合：
- 后端提供健康检查端点（如
/healthz），下线前返回503 Service Unavailable，Nginx 配合proxy_next_upstream error timeout http_503快速摘除节点； - Nginx 层启用连接 draining：Ingress Nginx Controller 可通过
nginx.ingress.kubernetes.io/service-upstream: "true"+ K8s readiness probe 实现； - 客户端必须实现幂等重连：断开后延迟 1–3 秒再连，关键消息带
message_id，服务端去重； - 运维侧使用滚动更新：K8s 中设置
maxSurge=0, maxUnavailable=1，确保旧 Pod 等待连接自然关闭后再终止。
reload 前必须验证的几件事
即使配置正确，一次失败的 nginx -s reload 也可能引发雪崩：
- 先执行
nginx -t，避免语法错误导致 master 进程退出、所有 worker 被连带终止； - 确认容器内 pid 1 是 nginx master 进程（加
--init或tini），否则SIGHUP无法透传给 worker； - 检查
keepalive_timeout是否过短（默认 75s），建议设为keepalive_timeout 600s，减少连接重建压力； - 切勿手动
kill处于shutdown状态的 worker 进程——这会直接触发aborting和 socket 泄漏。
最常被忽略的一点：WebSocket 的“优雅”不在 Nginx，而在客户端能否容忍短暂断连并自动恢复。参数调得再细，没有客户端重连退避和消息幂等，就谈不上平滑。
