直接向Nginx主进程发送SIGHUP（信号1）可触发平滑重载，不中断服务、不丢请求；但需确保信号送达Master、配置语法与资源权限校验均通过，否则重载失败且服务仍用旧配置运行。
直接向 Nginx 主进程发送 SIGHUP（信号编号 1）即可触发平滑重载，整个过程不中断服务、不丢请求。关键不是“发了信号”，而是信号被正确送达主进程，并且配置校验通过后才真正切换。
必须先验证配置语法和资源权限
Master 进程收到 SIGHUP 后不会立即加载新配置，而是严格按顺序执行两步检查：
- 重新解析
nginx.conf及所有include文件，确认语法无误（如括号匹配、分号缺失、指令拼写） - 验证运行时依赖是否就绪：监听端口未被占用、SSL 证书路径存在且可读、日志目录有写权限、upstream 后端域名能正常解析等
任一检查失败，Master 就放弃重载，继续用旧配置运行，并在 /var/log/nginx/error.log 中记录具体错误。此时服务完全不受影响，但你的修改并未生效。
只对 Master 进程发信号，不能发给 Worker
Worker 进程不响应 SIGHUP，强行发送无效。准确获取 Master PID 的方式有两种：
- 从 pid 文件读取：默认是
$(cat /var/run/nginx.pid)，前提是 nginx 配置中设置了pid /var/run/nginx.pid; - 用
ps过滤主进程：例如pgrep -f "nginx: master process"或ps aux | grep 'nginx.*master' | grep -v grep
注意：必须用启动 Nginx 时的同一用户（通常是 root）执行命令，否则因权限不足无法读取 pid 文件或向主进程发信号。
推荐的三种发送方式（按优先级）
以下命令本质都是向 Master 发送 SIGHUP，但封装程度和安全性不同：
-
sudo nginx -s reload：最常用。内部自动调用nginx -t校验 + 权限检查 + 发送信号，出错会明确提示 -
sudo systemctl reload nginx：systemd 环境首选。自动走 ExecReload 指令，兼容服务单元配置，适合运维标准化场景 -
sudo kill -HUP $(cat /var/run/nginx.pid)：手动方式，适合调试或脚本中需要精确控制信号时机的场合
如何确认重载真正成功
不能只看终端没报错，要交叉验证三个层面：
-
进程时间：执行
ps aux | grep nginx，新 Worker 进程的 START 时间应接近你 reload 的时刻；Master 进程启动时间不变 -
错误日志：查看
tail -n 5 /var/log/nginx/error.log，应出现reopening logs或signal 1 (SIGHUP) received，且无 ERROR/WARN 级报错 -
实际行为：改了
server_name就用curl -H "Host: xxx" http://127.0.0.1测试；改了location就访问对应路径；改了端口就用ss -tlnp | grep :新端口确认监听已更新
