控制Nginx需向master进程发信号而非杀进程；先用pid文件或ps命令准确获取PID；推荐nginx -s quit优雅停止、reload平滑重启、reopen轮转日志、t验证配置。
控制 Nginx 服务的核心在于向 master 进程发送正确信号，而不是直接杀进程或反复启停。关键前提是：先确认 master 进程 PID，再用 nginx -s 或 kill 发送对应信号，整个过程不中断现有连接。
如何准确获取 master 进程 PID
master 进程只有一个，是所有操作的入口。推荐两种稳定方式：
- 查看 pid 文件：默认路径为
/usr/local/nginx/logs/nginx.pid或/var/run/nginx.pid，执行cat /var/run/nginx.pid即可读出 PID - 用 ps 命令过滤：运行
ps -ef | grep "nginx: master"，第一列数字即为 PID；注意排除带grep的那行
若 pid 文件不存在，说明 Nginx 未正常启动，或启动时指定了非默认 pid 路径（如通过 -g "pid /path/to/pid;"），需按实际配置查找。
停止服务：quit（优雅）比 stop（强制）更安全
停止不是“一刀切”，而是让 worker 进程完成手头请求后再退出，避免用户看到 502 或连接中断。
-
推荐使用
nginx -s quit：自动读取 pid 文件并发送 QUIT 信号，worker 处理完当前请求后关闭，master 随后退出 -
nginx -s stop等价于kill -TERM $PID：立即终止 master，worker 进程被强制中止，正在传输的数据可能丢失 - 绝对避免
kill -9 $PID：绕过 Nginx 自身清理逻辑，容易残留 worker 进程或锁文件
重启与重载：reload 是平滑更新配置的标准操作
所谓“重启”，日常几乎不需要真正 stop + start，reload 就能实现无缝切换。
-
nginx -s reload触发 HUP 信号：master 先校验新配置（语法+文件权限），成功则拉起新 worker，再通知旧 worker 优雅退出 - 若配置有误，reload 会失败并报错，旧服务不受影响——这是它比手动 kill + nginx 启动更可靠的原因
- 执行后可通过
ps -ef | grep nginx观察：应同时存在旧 worker（状态为is shutting down）和新 worker
辅助操作：日志轮转与配置验证不可少
运维中常被忽略但非常实用的两个动作：
-
日志重开（reopen）：执行
nginx -s reopen，等效于 USR1 信号，让 master 和所有 worker 关闭并重新打开日志文件，便于 logrotate 切割归档 -
配置预检（t）：每次改完
nginx.conf，务必先运行nginx -t；它只检查语法和路径有效性，不加载也不影响运行中服务
配置验证通过再 reload，能大幅降低线上故障概率。
