旧 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"少一个，连接会被降级，无法维持长生命周期
