平滑重启后需确认新旧进程按预期切换：执行ps aux | grep nginx应见master与worker双进程结构，用ps -eo pid,comm,lstart | grep nginx比对启动时间，新worker应接近reload时刻；nginx -t和curl -i验证配置生效，ss -tnlp与持续curl测试确保连接不中断。
平滑重启后，关键不是“有没有重启成功”，而是“新旧进程是否按预期切换”——监控重点在于确认 master 是否已加载新配置、worker 是否已更新、旧进程是否正在退出。
检查 master-worker 进程结构是否完整
执行 ps aux | grep nginx，应看到两类进程：
- 一个 master process（通常属 root 用户，命令行含
nginx: master process） - 多个 worker process（通常属 nobody 或 www-data，命令行含
nginx: worker process）
若只有 master 没有 worker，说明新配置加载失败或权限/端口冲突；若只有 worker 没有 master，说明 master 异常退出，服务不可靠。
对比进程启动时间判断是否完成切换
使用 ps -eo pid,comm,lstart | grep nginx 查看各进程的精确启动时间：
- 新 master 进程的启动时间应略晚于你执行
nginx -s reload的时刻 - worker 进程的启动时间应与新 master 接近（而非旧时间）
- 如果仍存在明显早于 reload 时间的 worker 进程，说明旧 worker 尚未退出，仍在处理残留请求——这是正常现象，只要它们数量逐步减少即可
验证配置是否生效
进程存在 ≠ 配置生效。需进一步确认：
- 执行 nginx -T（大写 T），输出全部生效配置，搜索你修改过的段落（如 server_name、proxy_pass），确认内容已更新
- 访问一个受你改动影响的接口（例如新增的 location 或改过的返回头），用 curl -I 观察响应是否符合预期
- 查看 error.log 最后几行：tail -n 10 /var/log/nginx/error.log，确认无
reload failed或bind() to 0.0.0.0:80 failed类报错
观察连接过渡是否平稳
真正体现“平滑”的是连接不中断：
- 用 ss -tnlp | grep :80 看监听状态，reload 前后都应显示 nginx 占用 80（或对应端口）
- 持续请求测试：在 reload 同时用
while true; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost/; sleep 0.1; done，应全程返回 200，无 502/连接拒绝 - 旧 worker 退出前会将活跃连接数逐步归零，可通过 lsof -p [worker_pid] | wc -l 粗略观察其打开文件数变化
