worker_shutdown_timeout对WebSocket无效，因Nginx不解析WebSocket帧，无法判断消息状态，仅能强制终止TCP连接，导致消息截断、aborting告警及socket残留。
worker_shutdown_timeout 不是 WebSocket 优雅关闭的解药，设了也白设——它只对 HTTP 流量起作用，对已建立的 WebSocket 连接无实际延迟终止能力。
为什么 worker_shutdown_timeout 在 WebSocket 场景下基本失效
Nginx 的 worker_shutdown_timeout 是为 HTTP 请求设计的：它依赖请求头/体边界识别来判断“一个请求是否完成”，再决定是否关闭连接。但 WebSocket 是 TCP 层的全双工长连接，Nginx 反向代理时不做帧解析（不识别 0x00/0xFF 或现代二进制帧），仅透传数据流。因此：
- 旧 worker 进入 shutdown 状态后，
worker_shutdown_timeout到期只会强制 kill 进程，而非等待帧传输完成； - 日志中频繁出现
aborting和open socket left in connection，正是强制终止导致 socket 未 clean up 的直接证据； - 即使设为
300s，只要客户端没主动断开或服务端没发 close 帧，连接仍会被截断，消息丢失风险不变。
worker_shutdown_timeout 真正该用在哪
它只在以下明确可预期、有明确结束信号的场景下有效：
- HTTP 文件上传/下载：客户端发送完整
Content-Length或使用分块传输，Nginx 能感知 body 结束； - 短生命周期 API 请求（如 JSON-RPC、RESTful 接口），响应发出即视为完成；
- 配合
proxy_read_timeout和proxy_send_timeout使用，避免因后端慢响应导致 worker 卡死。
典型配置示例（放在 http 或 stream 块中）：
worker_shutdown_timeout 30s; proxy_read_timeout 3600; proxy_send_timeout 3600;
注意：worker_shutdown_timeout 默认值为无限（0），不显式设置就等于放任旧 worker 一直挂着——这在高并发下可能引发进程堆积和 context switch 激增。
真正影响 WebSocket 平滑退出的三个关键配置
别把希望全押在 worker_shutdown_timeout 上。这三个配置才决定 WebSocket 是否“自然断连”：
-
keepalive_timeout 600s：避免默认 75s 导致连接被过早回收，尤其对心跳间隔 >30s 的客户端； -
proxy_buffering off：防止 Nginx 缓存未发送完的 WebSocket 数据，掩盖真实断连时机； -
proxy_http_version 1.1+proxy_set_header Upgrade $http_upgrade+proxy_set_header Connection "upgrade"：确保 WebSocket 握手成功，否则压根进不了长连接流程。
reload 时最常踩的坑：手动 kill shutdown 状态的 worker
执行 nginx -s reload 后，ps 查到一堆 worker process is shutting down 是完全正常的中间态。此时：
- 不要
kill -9或kill任何 PID，否则立刻触发aborting和 socket 遗留； - 不要依赖
worker_shutdown_timeout来“加速退出”，它无法干预 WebSocket 连接生命周期； - 真正要做的，是让后端服务配合健康检查返回
503，让 Nginx 主动摘除节点，再由客户端重连退避兜底。
复杂点在于：WebSocket 的平滑性从来不是单靠 Nginx 配置能解决的，它卡在 TCP 层、依赖客户端行为、受后端通知机制制约——worker_shutdown_timeout 只是 HTTP 世界的缓冲带，在长连接世界里，它连门都摸不到。
