nginx worker 进程不主动重启，而是由 master 调度实现优雅替换：旧 worker 停止 accept 新连接但继续处理已有请求，新 worker 复用监听 socket 并行接管新连接，全程连接不中断、服务无感知。
Nginx 的 Worker 进程本身不主动“重启”，而是由 Master 进程统一调度，在 reload 操作中被优雅替换。整个过程是协作式的：旧 Worker 继续服务，新 Worker 并行启动，连接无感知切换。
Worker 进程不独立重启，而是被 Master 控制实现“优雅退出 + 新建接管”
Worker 如何做到“不中断请求”的退出
旧 Worker 收到 Master 发出的退出指令（通常是 QUIT 信号）后，并非立即终止，而是进入受控的收尾状态：
- 停止 accept 新连接，监听 socket 不再入队
- 继续处理已建立但尚未完成的请求（包括长连接、文件上传中、响应未发完等）
- 不主动断开 keepalive 连接，等待客户端主动关闭或超时
- 若配置了
worker_shutdown_timeout 10s;，则最多等待 10 秒，超时后强制关闭剩余连接 - 所有活跃请求结束后，进程自动退出，Master 将其从进程列表中移除
新 Worker 是如何无缝接手的
新 Worker 启动时，关键在于复用已有监听资源：
- Master 在 fork 新 Worker 前，已通过
SO_REUSEPORT（现代内核）或内部 socket 句柄继承机制，让新旧 Worker 共享同一组监听 socket - 新 Worker 启动后立即能 accept 新连接，无需重新 bind 或 listen
- 客户端新建连接自然落到新 Worker，而旧连接仍由原 Worker 处理，两者并存不冲突
如何确认 Worker 正在平滑切换
执行 nginx -s reload 后，可观察以下现象：
-
ps aux | grep nginx显示两批 worker：老进程状态为exiting，新进程为running -
tail -f /var/log/nginx/error.log中出现reloading configuration和后续exit日志 -
curl -I http://your-site响应正常，且新配置（如新增 header、改写规则）对新请求生效 - 旧连接（如长时间 WebSocket 或大文件下载）持续可用，直到自然结束
本质上，Worker 的“平滑”不靠自身重启逻辑，而依赖 Master 的信号协同、socket 继承与生命周期管理。只要配置校验通过、系统支持 socket 复用，整个过程就天然可靠。
