关键不是看“有没有 reload 成功”，而是确认 master 是否已加载新配置、新 worker 是否已就位、旧 worker 是否正在退出但尚未终止；需通过 ps 查进程结构与状态、比对启动时间、nginx -t 和 curl 验证配置生效、ss 与持续 curl 测试连接不中断。
验证 Nginx 平滑重载后新旧 Worker 进程是否正在交替运行，关键不是看“有没有 reload 成功”，而是确认 master 是否已加载新配置、新 worker 是否已就位、旧 worker 是否正在退出但尚未终止。这个过渡状态通常持续数秒到数分钟，取决于活跃连接数量和 worker_shutdown_timeout 设置。
查进程结构与角色状态
执行：
ps aux | grep nginx
应同时看到：
- 一个
nginx: master process（属 root，PID 稳定不变） - 多个
nginx: worker process（属 www-data 或 nobody） - 部分 worker 命令行末尾可能带
(exiting)字样（表示已收到 QUIT，正优雅退出）
若只看到 master 没有 worker，说明新配置加载失败；若全是 (exiting) 且无新 worker，说明新进程启动异常或权限/端口冲突。
比对进程启动时间确认切换阶段
执行：
ps -eo pid,comm,lstart | grep nginx
观察输出中的 启动时间（lstart）：
- 新 master 和新 worker 的启动时间应非常接近你执行
nginx -s reload的时刻 - 仍存在的旧 worker 启动时间明显早于 reload 时间——这是正常现象，只要它们数量在减少、且不再接受新请求即可
- 若所有 worker 启动时间都远早于 reload，说明 reload 实际未生效（可能是语法错误被跳过，或信号未送达）
验证配置是否由新 worker 承载
仅进程存在不代表配置已生效。需交叉验证：
- 运行
nginx -T | grep -A2 "server_name\|listen\|proxy_pass"，确认你修改的配置段已出现在输出中 - 用
curl -I http://your-domain/访问一个受改动影响的路径（如新增的location /api），检查响应头、状态码或重定向行为是否符合新配置 - 查看错误日志末尾：
tail -n 5 /var/log/nginx/error.log，应有类似reloading configuration和exiting日志，且无bind() to 0.0.0.0:80 failed或open() "/path/to/cert" failed类报错
观察连接是否自然过渡
真正体现“平滑”的是连接不中断：
- 执行
ss -tnlp | grep :80（或对应端口），reload 前后都应显示 nginx 在监听，且 PID 应指向当前 master - 持续发起请求：
while true; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost/; sleep 0.1; done，全程应稳定返回 200，不出现 502、连接拒绝或超时 - 挑一个旧 worker 的 PID（如
12345），运行lsof -p 12345 | wc -l多次，数值应随时间缓慢下降——说明它正逐步释放活跃连接
