向 nginx 主进程发送 hup 信号可实现无中断热加载配置：主进程校验语法后启动新 worker 加载新配置处理新连接，旧 worker 继续服务已有连接直至自然退出；需先执行 nginx -t 校验、准确获取 master pid（如 cat /var/run/nginx.pid）、用 kill -hup 或 nginx -s reload 发送，并通过进程状态、错误日志和连通性三方面验证。
向 Nginx 主进程发送 HUP 信号是实现配置热加载的标准方式，它会触发平滑重启：新工作进程用新配置启动，旧工作进程处理完已有连接后退出，整个过程不中断服务。
确认配置语法正确再发 HUP
直接发 HUP 不校验配置，若配置有误，新工作进程启动失败，Nginx 会回退到旧配置继续运行，但日志中会出现错误，且可能造成部分功能异常。务必先执行：
-
nginx -t—— 检查配置文件语法和路径有效性 -
nginx -T—— 查看实际生效的完整配置（含 include 合并后结果），便于排查隐含问题
准确找到并发送 HUP 信号
Nginx 主进程是唯一拥有监听端口权限、负责派生工作进程的进程，PID 默认写在 /var/run/nginx.pid（路径以你配置中 pid 指令为准）。安全发送方式：
kill -HUP $(cat /var/run/nginx.pid)- 或更稳妥：
nginx -s reload—— 这条命令内部就是读 PID 文件并发送 HUP，推荐优先使用 - 避免用
killall nginx或模糊匹配 PID，可能误杀工作进程
验证热加载是否成功
不能只看命令没报错，要确认行为已更新：
- 检查进程列表：
ps aux | grep nginx，应看到新旧两批工作进程共存（几秒内旧进程逐步退出） - 查看错误日志：
tail -f /var/log/nginx/error.log，确认无invalid number of arguments、unknown directive等错误 - 用
curl -I或浏览器访问，验证新配置效果（如新增的return 404规则、修改的proxy_pass地址等）
注意几个常见陷阱
看似简单，但以下情况会导致“以为重载成功，实则未生效”：
- 编辑了配置但忘了
save（特别是 vim 编辑后未 :wq） - 修改的是被
include的子配置，但主配置里路径写错或未生效 - SELinux 或文件权限限制导致 Nginx 无法读取新配置中的证书、日志路径等
- 使用了
daemon off或容器环境，PID 文件位置不同或不存在，需改用kill -HUP 1（容器中主进程 PID 为 1）
不复杂但容易忽略细节，关键在于“先测再发、发完验证”。
