Nginx Worker Process 优雅关闭的核心是不中断已有请求、停止接受新连接、逐步释放空闲连接，并在所有活跃连接处理完毕后退出；其依赖SIGQUIT信号触发、事件循环持续运行、连接状态管理及worker_shutdown_timeout超时兜底。
Nginx 的 Worker Process 实现连接优雅关闭，核心在于不中断已有请求、不拒绝新连接、逐步释放空闲连接，并在所有活跃连接处理完毕后安全退出。这不是靠单个机制完成的，而是信号、事件循环、连接状态管理和定时检查共同作用的结果。
接收 SIGQUIT 信号触发优雅退出流程
当向 worker 进程发送 SIGQUIT（例如执行 nginx -s quit 或 kill -QUIT $pid）时，worker 进程不会立即终止，而是将自身状态标记为“正在退出”，并停止接受新连接。注意：此时 master 进程仍正常运行，可能已拉起新 worker；旧 worker 只负责善后。
停止监听新连接但保持已有连接活跃
收到 SIGQUIT 后，worker 会：
- 调用
ngx_close_listening_sockets()关闭所有 listening socket，不再accept()新连接 - 继续处理已建立的 TCP 连接（包括正在传输请求体、等待响应写回、Keep-Alive 等待中的连接）
- 对 HTTP/1.1 Keep-Alive 连接，仍按配置的
keepalive_timeout计时，超时后主动关闭
事件循环持续运行直到无活跃连接
worker 不会立刻退出，而是继续运行 epoll/kqueue/iocp 事件循环：
- 响应已连接上的读写事件（如客户端发来剩余请求体、服务端回写响应）
- 定时检查连接空闲时间，关闭超时的 Keep-Alive 连接
- 等待所有连接进入
CLOSED或CLOSING状态 - 一旦所有连接被关闭或超时释放，且没有待处理事件，进程才调用
exit(0)
配合 upstream 和子请求时的额外保障
若请求涉及 proxy_pass、fastcgi_pass 或子请求（subrequest），Nginx 会确保：
- 已发出的 upstream 请求必须等待响应返回或超时失败
- 子请求全部完成，主请求才能结束
- 所有缓冲区数据写入 socket 并确认（部分场景会调用
shutdown(SHUT_WR)等待 FIN-ACK）
整个过程无需人工干预，只要不强制 kill -9，Nginx 就能保证每个 HTTP 请求得到完整响应，TCP 连接按标准四次挥手关闭。关键在于它把“退出”变成了一个受控的状态迁移，而不是瞬间终止。
