旧 worker 进程在 reload 后不会立即退出，而是等待已有连接自然关闭或超时强制终止；其完全退出取决于 worker_shutdown_timeout（必须置于 main 块）、连接状态（如 keepalive_timeout、proxy_read_timeout 等）及客户端行为三者交集，超时后强制关闭 socket 并退出。

旧 worker 进程在平滑重载（nginx -s reload）后，**不会立即退出，而是持续运行直到满足全部退出条件**。它何时完全退出，取决于三个硬性约束的交集：配置设定、连接状态、超时机制。

退出由 worker_shutdown_timeout 强制兜底

这是最明确的时间边界。该指令设定了旧 worker 最多还能“陪多久”：

• 必须写在 main 块（即 nginx.conf 最外层，与 user、worker_processes 同级），否则无效
• 值不是随意填的，要覆盖你业务中最长的连接生命周期：REST 接口通常 15–30s，长轮询建议 45–90s，WebSocket 或大文件上传需 ≥90s 甚至 300s+
• 超时一到，Nginx 强制关闭其所有 socket 并终止进程，不管连接是否真正完成

实际退出往往早于 timeout，取决于连接自然结束

旧 worker 不会等到 timeout 才动，只要它手头的连接全部处理完毕，就会主动退出：

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• 已建立的 HTTP/1.1 Keep-Alive 连接：等客户端空闲超时（keepalive_timeout）或主动断开
• HTTP/2 流或 WebSocket：等对端发 FIN 或心跳超时（需确保 proxy_read_timeout ≥ worker_shutdown_timeout，否则代理层先断）
• 大文件上传：等客户端发完全部 body（要求 client_body_timeout ≤ worker_shutdown_timeout）

进程退出前会逐步释放资源，可观察验证

你可以通过以下方式确认它是否正在退出、何时退出干净：

• 用 ps -eo pid,comm,lstart | grep nginx 查看各 worker 的启动时间——旧进程的 lstart 时间明显早于 reload 时间，且数量随时间减少
• 用 lsof -p [old_worker_pid] | wc -l 观察打开文件数：从高位缓慢下降至接近 0，说明连接正自然关闭
• 检查 error.log 末尾：无 upstream prematurely closed connection 或大量 client closed connection，说明未被强制中断

异常情况：旧进程卡住不退的常见原因

如果旧 worker 长时间残留（比如超过 timeout 还存在），大概率是超时配置没对齐：

• proxy_read_timeout 或 proxy_send_timeout 小于 worker_shutdown_timeout → Nginx 在后端响应前就关了连接，但旧 worker 还在等响应，陷入僵持
• client_header_timeout 或 client_body_timeout 过大 → 客户端迟迟不发完请求头或体，旧 worker 一直阻塞等待
• WebSocket 场景缺关键头：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" 少一个，连接会被降级，无法维持长生命周期