零停机热重启能实现，但前提是你没跳过 nginx -t、没忽略 PID 文件权限、也没在旧进程还在处理长连接时就强行 kill -QUIT；nginx -s reload 触发 HUP 信号，使 Master 重解析配置并启动新 Worker，旧 Worker 继续处理已有连接，监听套接字由 Master 持有并分发，客户端无感知断连。
零停机热重启能实现，但前提是你没跳过 nginx -t、没忽略 PID 文件权限、也没在旧进程还在处理长连接时就强行 kill -QUIT。
为什么 nginx -s reload 不等于“重启服务”
HUP 信号触发的是 Master 进程内部的一次配置重解析和 Worker 迭代，不是整个进程树 kill 再拉起。旧 Worker 继续持有已建立的 TCP 连接（包括 keep-alive 空闲连接），新 Worker 启动后通过继承的监听 socket 接收新连接——两者共存期间，连接分发由内核完成（SO_REUSEPORT 或 Master 统一分发），客户端完全无感知。
常见错误现象：
- 执行
nginx -s reload后，ps aux | grep nginx看不到新 Worker：大概率是nginx -t没过，Master 拒绝加载新配置，日志里会有invalid number of arguments in "listen" directive类报错 - 旧连接突然断开或返回 502：说明新 Worker 因权限问题（如无法读取 SSL 证书、写入日志目录）启动失败，Master 只能继续用旧 Worker，但后续请求可能因配置不一致被拒绝
关键参数差异：
-
worker_processes auto：reload 后新 Worker 数量按当前 CPU 核心数重算，若旧配置是固定数字（如worker_processes 4），可能造成资源争抢 -
keepalive_timeout和client_header_timeout：这些值变更会立即生效于新连接，但不影响旧连接中已设置的超时计时器
二进制替换时 USR2 到底启动了什么
发送 kill -USR2 $(cat /var/run/nginx.pid) 后，旧 Master 进程 fork 出一个新 Master，这个新 Master 的可执行文件路径来自你调用的 kill 命令上下文无关——它只认你显式指定的新二进制路径（比如 /opt/nginx-1.25.3/sbin/nginx），而不是 PATH 或软链。所以必须确保该路径下二进制存在、可执行、且与旧版本 ABI 兼容（尤其模块结构、共享内存布局）。
容易踩的坑：
- 新二进制编译时用了
--with-http_v2_module，但旧配置里有http2 on；而旧版本没这个模块，reload 就会失败——但 USR2 是另一条路径，它只校验新二进制自身能否启动，不校验配置是否兼容旧版 - 新二进制运行用户是
www-data，但旧 PID 文件 /var/run/nginx.pid 所属用户是nginx，导致新 Master 启动时无法写入自己的 pid 文件，卡在初始化阶段 -
pid /var/run/nginx.pid指令在新旧配置中路径不一致，新 Master 启动后写入新位置，后续WINCH发送给旧 PID 就失效
旧 Worker 退出前到底在做什么
收到 WINCH 后，旧 Master 不再 fork 新 Worker，并向自己管理的每个旧 Worker 发送 QUIT 信号。此时旧 Worker 进入“优雅关闭”状态：不再 accept 新连接，但仍在处理已接收的请求、响应未完成的流式传输、等待 keep-alive 超时、刷写缓冲区日志。这个过程没有固定时长，取决于业务实际负载。
判断是否安全发 QUIT 给旧 Master 的依据：
- 用
ss -tn state established '( dport = :80 or dport = :443 )' | wc -l观察活跃连接数是否持续下降 - 检查
ps aux | grep 'nginx: worker process' | grep -v 'master'输出中旧 Worker 的启动时间是否早于 reload 时间戳 - 监控 Nginx 自身指标：旧 Worker 的
ngx_http_upstream_fallback_requests或ngx_http_request_time是否归零（需开启 stub_status）
性能影响：旧 Worker 在退出前仍占用内存和 CPU，若存在大量长轮询或大文件下载，它们可能持续数分钟，此时系统总 Worker 数临时翻倍，需预留足够资源。
升级后验证不能只看 nginx -v
nginx -v 返回的是当前 shell 中 PATH 下的二进制版本，不是正在运行的进程所用版本。真正运行的是哪个？得查 /proc：
ls -l /proc/$(pgrep -f "nginx: master process" | head -n1)/exe
输出类似 /opt/nginx-1.25.3/sbin/nginx 才算成功。如果还是指向旧路径，说明 USR2 失败或新 Master 启动后立刻崩溃（查 error.log 开头几行，常因模块缺失或配置语法错误）。
更隐蔽的问题是配置合并逻辑变化：比如新版本对 include 路径解析顺序调整，或 map 指令默认行为变更，导致某些请求路由结果不同——这种问题不会报错，但线上行为已偏移。所以升级后务必验证关键路径的响应头、状态码、body 内容，而不是只确认进程存活。
