平滑重载时waiting连接数变化最能反映长连接复用状态：短时下降正常，持续为0或长期偏低说明复用失效，快速回升则表明过渡成功；需同步监控active、reading、writing并校验三者之和是否等于active。
平滑重载（nginx -s reload）本身不中断连接，但监控重载过程中的连接数变化，关键在于区分“旧 worker 正在处理的连接”和“新 worker 接管的新连接”，并观察 Waiting 连接是否出现异常波动。直接看 Waiting 值最能反映长连接在重载期间的实际复用状态。
重点盯住 Waiting 连接数的变化趋势
重载过程中，Nginx 会启动新 worker 进程，同时让旧 worker 继续处理已建立的连接（包括 Reading、Writing 和 Waiting 状态），直到它们自然关闭或超时。因此：
- Waiting 数值短时下降是正常现象：部分空闲 Keep-Alive 连接可能在旧 worker 退出前被主动关闭，或客户端恰好在此时发起新请求，导致 Waiting 暂时减少；
- Waiting 持续为 0 或长期低于日常均值，说明长连接未被有效复用，可能是重载频率过高、keepalive_timeout 设置过短，或客户端未正确复用连接；
- Waiting 在重载后快速回升并稳定，表明长连接顺利过渡到新 worker，复用机制工作正常。
配合 Active、Reading、Writing 分项观察
仅看 Waiting 不够全面，需同步采集三组数值，每秒打点持续 30 秒以上：
- Active 总体应保持平稳：大幅跳变（如骤降再飙升）可能意味着部分连接被强制断开，或新旧 worker 衔接异常；
- Reading/Writing 应无明显堆积：若重载后 Writing 长时间居高不下，说明响应发送受阻，可能与新 worker 初始化延迟或资源争用有关；
- Waiting + Reading + Writing ≈ Active：该等式始终成立，可用于校验数据有效性；若偏差大，说明 stub_status 输出不稳定或采集有误。
使用脚本实现自动化采样
手动刷新 status 页面无法捕捉瞬时变化，建议用简单循环脚本持续抓取：
- Linux 示例（每 0.5 秒采集一次，共 60 次）：
for i in $(seq 1 60); do echo "$(date +%s.%3N) $(curl -s http://127.0.0.1/nginx-status 2>/dev/null | awk '/Waiting/ {print $2}')"; sleep 0.5; done > reload_monitor.log - 采集后用 Excel 或 gnuplot 绘制 Waiting 时间序列图，对比重载命令执行时刻（可用
date +%s.%3N记录）； - 若使用 Zabbix/Prometheus，可配置
nginx_waiting指标采集间隔缩至 1s，并设置重载操作标记（如通过自定义 tag 或外部事件注入）。
辅助验证：检查 error.log 是否有连接异常
重载本身不报错，但若连接处理异常，日志中可能出现线索：
- 搜索
"client closed connection"或"broken pipe"：高频出现说明客户端在重载期间主动断连； - 留意
"accept() failed (24: Too many open files)"：表示系统文件描述符耗尽，可能导致新连接被拒，间接拉低 Waiting； - 确认
worker_connections和worker_rlimit_nofile配置合理，避免重载后因资源未及时继承引发抖动。
