nginx master进程收到sighup后先校验配置语法与资源权限，通过则fork新worker加载新配置并accept新连接，同时旧worker处理完已有连接后优雅退出，全程不中断服务、不丢请求。
Nginx 的 Master 进程通过接收 SIGHUP（信号编号 1）实现配置重载，整个过程不中断服务、不丢请求，核心是“新旧 Worker 并存 + 优雅切换”。
Master 收到 SIGHUP 后先做两件事
它不会立刻重启或覆盖配置，而是严格按顺序执行：
- 重新读取并解析
nginx.conf及所有include文件，检查语法是否合法 - 验证关键资源是否可用：监听端口是否被占用、SSL 证书路径是否存在且可读、日志目录是否有写权限等
任一检查失败，Master 就停止后续流程，继续用旧配置运行，并在 /var/log/nginx/error.log 中记录错误。服务完全不受影响。
验证通过后启动新 Worker
Master 开始加载新配置到内存，并 fork 出一批新 Worker 进程：
- 新 Worker 拿到的是完整的新配置（比如新的
server块、upstream地址、TLS 参数） - 它们立即继承 Master 已绑定的监听 socket（如
:80、:443），开始 accept 新连接 - 此时系统中同时存在旧 Worker（处理存量连接）和新 Worker（处理新请求）
旧 Worker 不是被杀掉，而是安静退出
Master 向旧 Worker 发送 SIGQUIT（不是用户直接发的 HUP），触发其优雅关闭逻辑：
- 停止 accept 新连接，但保持已有 TCP 连接活跃（包括 keep-alive 空闲连接）
- 继续处理未完成的请求：响应已发出的 HTTP 请求、上传未结束的文件、等待后端返回等
- 全部连接自然关闭或超时后，进程自行退出；默认无强制超时，实际退出时间取决于业务流量模式
怎么发这个信号才有效
必须作用于 Master 进程本身，常见方式有：
-
kill -HUP $(cat /var/run/nginx.pid)（最直接，需确认 PID 文件路径） -
nginx -s reload（封装好的命令，内部也是发 SIGHUP） -
systemctl reload nginx（推荐，自动做nginx -t校验 + 权限检查 + 信号发送）
注意：不要对 Worker 进程 PID 发 HUP —— 它们不响应这个信号，也没法触发重载。
