Nginx Master进程不处理请求，而是通过信号协调Worker实现热更新：SIGHUP重载配置、SIGUSR2升级二进制、SIGWINCH关闭Worker、SIGUSR1重开日志、SIGTERM/SIGINT强制退出；热更新本质是双轨切换，新旧Worker并存过渡，确保零中断。
Nginx 的 Master 进程本身不处理请求，但它是整个服务生命周期的“总控中心”，信号处理和配置热更新都依赖它对子进程（Worker）的协调与接管。
Master 进程如何响应信号
Master 进程以阻塞方式监听 SIGUSR1、SIGHUP、SIGUSR2、SIGWINCH、SIGTERM、SIGINT 等信号，每种信号对应明确语义：
- SIGHUP：触发配置重载 —— Master 读取新配置，启动新 Worker，优雅关闭旧 Worker
- SIGUSR2：平滑升级可执行文件（如 nginx 二进制更新后），启动新 Master + 新 Worker，保留旧进程服务
- SIGWINCH：通知 Master 关闭所有 Worker（常用于 graceful shutdown 场景，如滚动发布前）
- SIGUSR1：重新打开日志文件（用于日志轮转，避免重启）
- SIGTERM / SIGINT：强制/快速退出，Master 向 Worker 发送 SIGKILL 并自行终止
配置热更新不是“覆盖 reload”，而是“双轨切换”
执行 nginx -s reload 或 kill -HUP `cat /var/run/nginx.pid` 后，Master 并不直接修改正在运行的 Worker 配置。实际流程是：
- Master 解析并校验新配置文件（语法、路径、端口冲突等）；任一失败则中止，旧 Worker 继续运行
- 若校验通过，Master fork 出新 Worker 进程，用新配置初始化它们
- 同时向旧 Worker 发送 SIGQUIT，要求其停止接受新连接、处理完已有请求后退出
- 新 Worker 接管 listen socket（通过继承父进程已绑定的 fd），开始接受连接
- 整个过程无请求丢失，也无需中断服务
关键细节决定热更成败
热更新能否成功，不仅取决于信号是否发出，更依赖配置结构与运行时状态：
- listen 指令中的
reuseport会影响 socket 继承行为，多 worker 共享端口时需确保内核支持且配置一致 - SSL 证书或密钥路径变更后，新 Worker 启动时会立即加载，但旧 Worker 仍使用原证书服务存量连接
- 如果新配置中某 upstream server 不可达，或 resolver 不可用，可能导致新 Worker 启动失败（表现为
nginx: [emerg] ... failed） - log_format、access_log 路径变更后，需配合
kill -USR1才能生效，因为日志文件描述符由 Worker 自己持有
验证热更新是否真正生效
不能只看 ps aux | grep nginx 是否有新进程，要确认三点：
- 检查
nginx -t输出是否显示 “configuration file ... is ok” - 用
lsof -i :80观察监听 socket 是否被新 PID 持有 - 查看 error.log，确认是否有
reconfiguring和exiting日志行，以及新 Worker 的start worker processes
