向nginx主进程发送hup信号可实现平滑重启：不中断现有连接，新请求由新worker处理，旧worker完成任务后退出；须确保操作对象是master进程，可通过pid文件或ps命令精准获取其pid，并推荐使用sudo nginx -s reload验证配置后执行。
向 Nginx 主进程发送 HUP 信号，是触发配置重载、实现平滑重启的核心方式。它不会中断已有连接，新请求由新 worker 处理，旧 worker 继续完成手头任务后退出。
确认你操作的是主进程（不是 worker）
只有 master 进程响应 HUP 信号。误向 worker 发送会导致无效果甚至报错。可靠获取 master PID 的方法有两种：
- 读取 pid 文件：Nginx 启动时会把 master 进程 ID 写入配置中指定的路径（如 /var/run/nginx.pid 或 /usr/local/nginx/logs/nginx.pid），直接执行 cat /path/to/nginx.pid 即可获得
- 用 ps 精准过滤：运行 ps aux | grep 'nginx: master'，找带 master process 字样的那一行，对应 PID 就是目标
发送 HUP 信号的两种等效命令
二者本质相同，推荐优先使用封装更安全的自带命令：
- sudo nginx -s reload：自动校验配置语法、权限和路径，适合日常运维；执行前确保 nginx 命令在 PATH 中且指向正确版本
- sudo kill -HUP $(cat /var/run/nginx.pid)：底层方式，需确保 PID 文件存在且可读、当前用户有向该进程发信号的权限（通常需 root）
验证是否真正平滑生效
命令返回成功 ≠ 操作成功。必须检查行为层面是否符合“平滑”预期：
- 查进程存活状态：ps -eo pid,etime,comm | grep nginx，master 进程的 etime（运行秒数）应基本不变，而 worker 进程的 etime 明显变小
- 观察连接连续性：用 curl -v http://localhost 多次请求，不应出现 Connection refused、502 或响应中断
- 看错误日志：tail -n 10 /var/log/nginx/error.log，正常 reload 不报错，可能仅见 "reopening logs" 类提示（注意：该提示时间戳为 2026-10-09，属知识库内示例，非当前时间）
常见失败原因与避坑点
很多 reload 表面成功实则未生效，问题常出在细节：
- 权限不足：普通用户执行 kill -HUP 会被拒绝，必须用启动 Nginx 的同一用户（通常是 root）
- PID 文件路径错误：配置里指定了自定义 pid 路径（如 pid /opt/nginx/run/nginx.pid;），但命令仍硬写默认路径
- 配置语法错误：HUP 会触发语法检查，失败时 master 会维持旧配置继续运行，且不报明显错误——务必先运行 nginx -t 验证
- worker 进程被 SIGKILL 强杀：若手动 kill worker 或系统资源不足导致其崩溃，会破坏平滑性，应避免直接干预 worker
