平滑重启nginx是向master进程发送hup信号实现零中断更新，需先确认pid（查pid文件或ps命令），再执行kill -hup；多机集群须逐台滚动操作；二进制升级则需usr2+winch组合信号。
平滑重启 Nginx 服务不是“重启整个集群”，而是向 master 进程 发送特定信号，由它协调新旧 worker 进程交替，实现零中断更新。所谓“集群”通常指多台服务器上的多个 Nginx 实例，它们彼此独立；单台 Nginx 本身不构成集群，但可通过信号机制在本机完成平滑重启。
确认 master 进程 PID 是前提
必须先准确拿到当前运行的 master 进程 ID，否则信号会发错目标，导致异常或无响应：
- 读取默认 pid 文件：cat /var/run/nginx.pid 或 cat /usr/local/nginx/logs/nginx.pid（路径以 nginx.conf 中
pid指令为准） - 用 ps 过滤验证：ps -ef | grep "nginx: master process"，取第一列数字（注意排除含 grep 的行）
- 若 pid 文件不存在，说明 Nginx 未正常启动，或启动时用了自定义 pid 路径（如
-g "pid /opt/mynginx.pid;"），需按实际查找
用 kill 发送 HUP 信号实现平滑 reload
这是最常用、最安全的平滑操作，等价于 nginx -s reload，适用于配置变更：
- kill -HUP $(cat /var/run/nginx.pid)
- master 进程收到 SIGHUP 后，先校验新配置（语法+权限），失败则报错且不影响现服务
- 校验通过后，master 拉起新 worker 进程，同时通知旧 worker 在处理完当前请求后优雅退出
- 整个过程不关闭监听 socket，客户端连接不受影响，新请求由新 worker 接收
多实例或跨机器场景需逐台操作
如果你管理的是多台服务器组成的“Nginx 集群”，没有统一信号接口，必须分别登录每台机器执行：
- 不能对所有机器同时发 kill —— 缺乏协调机制，易引发短暂服务抖动或配置不一致
- 推荐按批次滚动操作：例如先更新 20% 节点 → 观察日志与监控 → 再扩至 50% → 全量
- 可配合 Ansible、SaltStack 等工具批量下发命令，但底层仍是每台执行一次
kill -HUP - 切勿尝试用
killall nginx或kill -9，这会强制终止进程，丢失连接、残留锁文件、破坏平滑性
升级二进制程序需用 USR2 + WINCH 组合信号
当要替换 nginx 可执行文件（如版本升级），才需要更复杂的平滑升级流程，而非普通重启：
- 先备份旧 binary，拷贝新 binary 到原路径（如
/usr/local/nginx/sbin/nginx） - 发送 kill -USR2 $(cat /var/run/nginx.pid)：旧 master 重命名自身 pid 文件为
.oldbin，并 fork 新 master 启动新 binary - 此时新旧 master 和 worker 并存，共同处理请求
- 验证新进程稳定后，再发 kill -WINCH $(cat /var/run/nginx.pid.oldbin)：逐步关停旧 worker
- 最后发 kill -QUIT $(cat /var/run/nginx.pid.oldbin)：退出旧 master
