Nginx优雅重启由Master进程触发：先校验配置，再fork新Worker并发送QUIT信号给旧Worker，旧Worker处理完现有连接后退出。耗时取决于配置复杂度与模块初始化开销。
在 Nginx 架构中，Master 进程本身不处理请求，它的核心职责之一是协调 Worker 进程的生命周期，包括启动、平滑重启（reload）和优雅关闭。所谓“优雅重启”，本质是 Master 接收信号后，以最小化服务中断的方式完成配置更新与进程更替——关键在于旧 Worker 不立即退出，而是继续处理完已有连接，新 Worker 并行启动并接管新连接。
Master 如何触发优雅重启
当执行 nginx -s reload 或向 Master 进程发送 SIGHUP 信号时，Master 开始执行以下动作：
- 校验新配置文件语法是否正确（
nginx -t等效检查），失败则终止流程并记录错误日志； - 若校验通过，Master fork 出新的 Worker 进程（使用新配置加载模块、监听端口等）；
- 同时向所有现存 Worker 进程发送
QUIT信号（非强制 kill），通知其进入“优雅退出”状态； - 旧 Worker 收到 QUIT 后停止接受新连接，但持续处理已建立的请求（包括长连接、正在传输的响应等）；
- 一旦某旧 Worker 完成所有当前任务且无活跃连接，它自行退出；
- Master 持续监控 Worker 状态，待全部旧 Worker 退出后，本轮 reload 完全完成。
时间线中的关键节点与耗时影响因素
整个过程没有固定时长，但各阶段有明确依赖关系：
- 配置校验阶段：通常毫秒级，但若 include 大量文件或启用复杂 Lua 脚本，可能延迟数百毫秒；
- 新 Worker 启动阶段：取决于模块初始化开销（如 ssl_certificate 加载、shared memory zone 分配），一般
-
旧 Worker 退出阶段：这是最大变量——取决于
worker_shutdown_timeout设置（默认未启用）、活跃连接数、客户端读写速度、以及是否启用keepalive_timeout； - Master 等待阶段：Master 不主动 kill 旧 Worker，仅等待其自然结束；若旧 Worker 卡死（如陷入阻塞 I/O），可能长期滞留，需人工介入。
如何观察与验证当前状态
可通过以下方式确认优雅重启是否按预期进行：
- 查看
nginx.pid文件内容变化：reload 后 PID 不变（仍是 Master 进程 ID），说明 Master 未重启； - 执行
ps aux | grep nginx：应短暂出现新旧 Worker 共存现象（例如旧 Worker 状态为S，新 Worker 为S或R）； - 检查 error.log：成功 reload 会记录
"reloading configuration"，失败则有具体报错； - 用
lsof -i :80观察监听 socket 是否被新旧 Worker 同时持有（Linux 下通常由新旧 Worker 共享 listen socket，靠内核 EPOLL 边缘触发分发）。
常见误区与可控优化点
实际运维中容易混淆或忽略的关键细节：
- “reload” ≠ “restart”：systemd 的
systemctl restart nginx默认执行 stop + start，会导致 Master 重启，所有 Worker 强制终止，不满足优雅性； - 未设置
worker_shutdown_timeout时，旧 Worker 可能无限期等待长连接关闭，建议设为合理值（如 30s）防止僵死； - HTTP/2 或 gRPC 场景下，单连接承载多请求，
keepalive_timeout和lingering_time配置直接影响旧 Worker 退出延迟； - 第三方模块（如 ngx_lua）若在 init_by_lua_block 中执行阻塞操作，会拖慢新 Worker 启动，间接延长 reload 总耗时。
