nginx -s reload 由 master 进程主导五步优雅重载：校验配置、开新端口、fork 新 worker、发 quit 信号、旧 worker 处理完请求后退出，全程不中断服务。
Master 进程本身不重启，而是通过信号协同、配置校验和进程调度完成优雅重载——整个过程不中断服务，旧请求照常处理，新请求由新 Worker 接管。
Master 接收并响应重载信号
执行 nginx -s reload 或 kill -HUP
- 重新读取
nginx.conf及所有include的配置文件 - 进行完整语法检查与语义验证（如端口是否被占用、路径是否存在且可写、SSL 证书是否有效等）
- 若任一环节失败，Master 继续运行旧配置，并在 error.log 中记录错误，服务完全不受影响
新旧 Worker 的协同切换
配置校验通过后，Master 开始调度新旧 Worker 的交接：
- fork 出一批新 Worker 进程，用新配置初始化；它们复用已有监听 socket（通过
SO_REUSEPORT或内核句柄继承），能立刻 accept 新连接 - 向所有旧 Worker 发送
QUIT信号，通知其进入退出流程 - 旧 Worker 停止 accept 新连接，但持续处理已建立的连接：包括长连接、上传中请求、后端未返回响应等
- 若配置了
worker_shutdown_timeout 30s;（需 Nginx ≥1.19.10），旧 Worker 最多再服务 30 秒，之后强制关闭剩余连接
关键依赖与常见风险点
真正实现“不丢请求”，需要满足几个底层前提：
- 配置文件必须挂载到容器或系统中正确路径，且 nginx 主进程有读取权限（Docker 中尤其注意 SELinux 和 volume 权限）
- 监听端口不能被其他进程占用，否则校验阶段即失败
- PID 文件路径需与实际一致（
pid /var/run/nginx.pid;），否则nginx -s reload找不到主进程 - 避免在高并发峰值期执行重载——虽然不中断，但 Worker 数量会短暂翻倍，可能增加内存与 CPU 压力
如何确认重载正在平滑进行
执行命令后，可通过以下方式快速验证状态：
-
ps aux | grep nginx：应同时看到nginx: master process、若干nginx: worker process（新）、以及若干nginx: worker process is shutting down（旧） -
tail -f /var/log/nginx/error.log：出现reloading configuration和后续exiting日志 - 发起一个长耗时请求（如
/slow返回 25 秒后内容），reload 同时观察是否成功完成——这是检验worker_shutdown_timeout是否生效的最直接方式
