Nginx 中 worker_shutdown_timeout 实战：确保热重载过程中长连接平滑退出-Nginx-PHP中文网

worker_shutdown_timeout对websocket无效，因nginx不解析websocket帧，无法判断消息状态，仅能强制终止tcp连接，导致消息截断、aborting告警及socket残留。

nginx 中 worker_shutdown_timeout 实战：确保热重载过程中长连接平滑退出

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 块中）：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

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 握手成功，否则压根进不了长连接流程。