核心是构建超时闭环机制：worker_shutdown_timeout必须置于main块，按业务类型设15–30s（rest）、45–90s（长轮询）、90–300s（websocket）、≥450s（大上传），并确保proxy_read/send_timeout≥其值、client_header/body_timeout≤其值，websocket还需配套proxy_http_version 1.1等升级头配置。
要让 Nginx 热重载（nginx -s reload）时旧 worker 进程不卡在 shutting down 状态、不挂起长连接，核心不是“调大一个值”，而是构建一套协同生效的超时闭环机制。worker_shutdown_timeout 是其中关键一环，但单独配置它几乎无效。
必须放在 main 块，否则完全不生效
该指令仅在全局上下文（即 nginx.conf 最外层）有效，写在 events、http 或 server 块内会被 Nginx 忽略：
- ✅ 正确：
worker_shutdown_timeout 90s;（直接写在文件开头，与其他user、worker_processes同级） - ❌ 错误：
http { worker_shutdown_timeout 60s; }或events { worker_shutdown_timeout 30s; }
取值不能拍脑袋，得按连接类型定
它不控制新连接，只决定旧 worker 能“陪”已有连接走多远。设太短会断连，设太长会堆积进程：
- 普通 REST API（P99 ≤ 1s）：15–30s，覆盖网络抖动和慢查询
- Keep-Alive / 长轮询：45–90s，建议略大于
keepalive_timeout（通常 75s） - WebSocket / SSE / HTTP/2 流：至少 90s～300s；若心跳 30s，需 ≥ 30s × 2 + RTT，起步设 90s
- 大文件上传（如 200MB @ 512KB/s）：理论耗时约 400s，
worker_shutdown_timeout至少设为 450s，并同步确认client_body_timeout ≥ 450
单设它没用，必须闭环上下游超时
只调大 worker_shutdown_timeout，而下游或上游提前断开，旧 worker 仍会被悬停：
-
proxy_read_timeout和proxy_send_timeout必须 ≥worker_shutdown_timeout，否则 Nginx 会在后端响应前主动关闭连接 -
client_header_timeout和client_body_timeout应 ≤worker_shutdown_timeout，防止客户端迟迟不发完头或体，把旧 worker 卡住 - WebSocket 场景下，
proxy_read_timeout推荐设为 86400（24 小时），避免默认 60s 主动断连空闲连接
WebSocket 不靠它“优雅”，但靠它防堆积
worker_shutdown_timeout 对 WebSocket 本身不生效——Nginx 不解析帧，无法判断消息是否收发完成。它只是给旧 worker 加一道安全阀，防止其无限期等待导致内存堆积甚至 OOM：
- 必须配合三项基础代理头：
proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade"; - 可选但强烈建议：
proxy_buffering off;（避免缓存未转发数据掩盖真实断连时机） - 真正平滑依赖后端健康检查（如返回 503）、Nginx upstream 自动摘流、客户端指数退避重连三者协同
