直接用 kill -hup 向 nginx 主进程发信号可安全热加载配置，需先准确获取 master pid（如 cat /var/run/nginx.pid）、以匹配用户权限执行，并确保 nginx -t 通过、旧配置已备份；执行后新 worker 加载新配置处理新连接，旧 worker 继续服务已有连接，全程不中断。
直接用 kill -HUP 向 Nginx 主进程发信号就能安全重载配置，前提是准确找到 master 进程、提前验证配置、并确认环境就绪。
必须先确认是 Master 进程的 PID
只有 master 进程响应 HUP 信号，worker 进程收到会直接忽略。不能靠 ps aux | grep nginx 随便挑一个 PID。
- 优先读取 PID 文件：
cat /var/run/nginx.pid或cat /usr/local/nginx/logs/nginx.pid（路径以nginx -V 2>&1 | grep prefix和配置中pid指令为准） - 辅助核对：
ps aux | grep "nginx: master process"，确认输出里有 master process 字样，且用户为 root（或启动 Nginx 的实际用户） - 权限要匹配：如果 Nginx 是普通用户启动的，
kill -HUP也得用同一用户执行，否则被拒绝
发送前务必做两项关键检查
跳过这步容易导致 reload 失败却不报错，旧配置继续跑，新配置根本没生效。
-
语法校验：运行
nginx -t（默认检测主配置）或nginx -t -c /etc/nginx/nginx.conf，确保返回 “syntax is ok” 和 “test is successful” -
备份当前生效配置：执行
nginx -T > /etc/nginx/conf-backup/$(date +\%F-\%H\%M).conf.full，保留完整合并后配置，出问题可秒级回滚
执行 kill -HUP 并观察是否真正生效
信号发出后不是“重启服务”，而是 master 启动新 worker、旧 worker 继续处理已有连接，整个过程无连接中断。
- 标准命令：
kill -HUP $(cat /var/run/nginx.pid) - 验证新 worker 是否启动：
ps -eo pid,comm,lstart | grep nginx | grep worker，看是否有比 reload 时间更晚的新进程 - 验证配置是否更新：比如改了
add_header X-Config-Version "v2"，用curl -I http://your-site/检查响应头；或调大client_max_body_size后上传略超原限制的文件，确认不再返回 413 - 观察连接过渡：
ss -tn state established '( dport = :80 or dport = :443 )' | wc -l，活跃连接数应平缓下降（旧 worker 退出中），再趋于稳定（新 worker 接管）
常见失败原因和应对
如果 reload 后没变化或日志报错，大概率卡在这几个环节：
- PID 文件路径不对或内容为空 → 检查
nginx.conf中pid指令，确认文件存在且可读 - 配置语法通过但 include 路径错误或证书缺失 →
nginx -T输出里找具体位置，比-t更彻底 - 新 worker 启动失败但旧 worker 仍在跑 → 查
error.log，重点看 reload 时间点附近的报错，如端口被占、目录无权限、SSL 文件不可读等 - 用 systemd 管理时混用命令 → 避免同时用
systemctl reload nginx和手动kill -HUP，二者本质相同，但混用可能造成状态不一致
