Nginx安全重载后旧worker进程仍处理已建立连接，导致新配置延迟生效；需通过worker_shutdown_timeout协同proxy_read_timeout等参数调优，并配合灰度reload与负载均衡摘除实现零残留。
安全重载（nginx -s reload）本身不会导致“旧配置残留”，真正的问题是：旧 worker 进程仍在处理连接，而这些连接可能依赖已变更的 upstream、rewrite 规则或 header 行为——但它们仍按旧配置逻辑执行，直到自然结束或超时退出。所谓“残留风险”，实质是业务语义层面的延迟生效，而非配置未加载。
明确旧 worker 的行为边界
reload 后，新 master 会 fork 新 worker 加载新配置；旧 worker 不再接受新连接，但会继续服务所有已建立的 TCP 连接（无论是否空闲、是否在传数据）。这意味着：
- HTTP/1.1 Keep-Alive 空闲连接，只要没超 keepalive_timeout，仍由旧 worker 维持，后续请求也走旧逻辑
- WebSocket、SSE、长轮询等活跃连接，只要没关闭，整个生命周期都受旧配置约束
- 大文件上传中段、慢速 POST body 未收完等情况，也会卡在旧 worker 中，按旧 client_body_timeout 和路由规则处理
用 worker_shutdown_timeout 控制最大滞留窗口
这是应对该风险最直接有效的手段。它设定了旧 worker 从收到 QUIT 信号起，最多还能存活多久：
- 必须放在 events 块中，例如：
events { worker_shutdown_timeout 45s; } - 值应略大于你最长的单次业务耗时（含网络抖动余量），比如上传接口 P99 为 38 秒，建议设 45–60 秒
- 设太短（如 5 秒）会导致活跃连接被强制中断；设太长（如 300 秒）会让旧逻辑持续生效太久，增加灰度验证难度
协同调优配套超时参数
单独调大 worker_shutdown_timeout 不够，还需确保其他超时不早于它“截断”连接：
- proxy_read_timeout 和 proxy_send_timeout ≥ worker_shutdown_timeout：避免反向代理层先关连接，后端还在处理
- client_header_timeout 和 client_body_timeout ≤ worker_shutdown_timeout：防止客户端发一半 header 就卡住旧 worker 直到超时
- keepalive_timeout 可保持默认（如 60s），它只管空闲连接释放，不影响活跃连接的善终逻辑
发布阶段主动降低风险
对敏感变更（如鉴权逻辑、上游地址、TLS 版本），可配合运维节奏控制影响面：
- 灰度 reload：先在小流量节点 reload，观察日志中
X-Worker-Pid或自定义 header，确认旧连接是否如期退出 - 配合健康检查：在 reload 前临时将节点从负载均衡摘除（如返回 503），等旧连接自然清空后再加回，实现“零旧连接残留”
- 记录 reload 时间戳，在 error.log 或 access_log 中添加
$time_iso8601，便于事后比对请求时间与配置生效时间
