轮询负载均衡本身不暴露具体节点调度顺序，需结合stub_status全局指标、upstream日志（$upstream_addr等字段）及max_fails/fail_timeout健康配置交叉验证：stub_status看系统是否活跃阻塞，日志统计各节点调用量是否均衡，健康配置确保故障节点及时剔除。
轮询负载均衡本身不直接暴露“哪个节点被轮到了”，但结合 stub_status 并不是用来监控轮询逻辑本身，而是通过它提供的全局连接与请求指标，配合其他关键配置和日志，间接判断轮询是否正常、后端是否健康、流量是否真正分发出去。核心思路是：用 stub_status 看“总量是否活跃”，再用日志和 upstream 状态看“分发是否均匀、节点是否存活”。
1. stub_status 提供的是整体运行基线，不是轮询明细
stub_status 返回的是 Nginx 进程级指标，例如：
- Active connections：当前所有 TCP 连接数（含 keepalive），突增或长期高位可能意味着后端响应慢、连接堆积；
-
accepts / handled / requests：三者应基本持平；若
handled ，说明有连接被接受但未完成处理，可能是 worker 崩溃或 upstream 超时未响应； - Reading / Writing / Waiting：Waiting 高而 Writing 低，常表明请求卡在等待后端响应，而非 Nginx 自身瓶颈。
这些值不能告诉你“此刻轮到了 server A 还是 B”，但能快速识别轮询系统是否陷入阻塞、是否整体失活。
2. 真正验证轮询健康，必须依赖 upstream 日志 + 状态字段
要在轮询场景下确认“各节点是否真实参与、是否响应正常”，需主动记录转发行为：
- 定义专用日志格式，捕获后端信息：
log_format upstream_log '$remote_addr - $upstream_addr $upstream_response_time $upstream_status $request_time'; - 在 proxy_pass 所在 location 中启用该格式：
access_log /var/log/nginx/upstream.log upstream_log; - 关键变量说明：
–$upstream_addr显示实际转发到的后端地址（如192.168.1.10:8080）；
–$upstream_response_time是后端真实耗时，可用于对比各节点性能；
–$upstream_status是后端返回的状态码（如502、504），直接反映节点故障。
用 awk '{print $3}' /var/log/nginx/upstream.log | sort | uniq -c | sort -nr 就能快速统计各后端被调用次数——轮询正常时，各节点计数应大致接近（尤其在无权重、无故障前提下）。
3. 让轮询“可观察”的最小增强配置
仅靠默认轮询，Nginx 不会主动探测后端是否活着。需手动加入基础健康兜底：
- 为每个 upstream server 设置失败熔断：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
} - 这样当某节点连续 3 次超时或返回 5xx，Nginx 会将其临时剔除 30 秒，后续请求不再轮到它；
- 配合
stub_status中的requests总量趋势 + 日志中各节点调用频次，就能交叉验证：“总量涨了，但某节点调用量归零” → 很可能已被自动摘除。
4. 快速检查是否轮询生效的实操命令
无需重启服务，几条命令即可现场验证：
- 查看当前活跃连接与请求速率变化：
watch -n 1 'curl -s http://127.0.0.1/nginx_status | grep "Active\|requests"' - 实时观察最近 10 条 upstream 日志：
tail -10f /var/log/nginx/upstream.log | awk '{print $3,$5}'（输出形如192.168.1.10:8080 200） - 统计过去一分钟各节点响应状态分布：
awk '$4>=600{print $3,$4}' /var/log/nginx/upstream.log | tail -600 | sort | uniq -c
如果发现某节点长期无日志、或大量 504 / timeout，而 stub_status 中 Waiting 持续偏高，基本可判定轮询仍在进行，但该节点已不可用且未及时剔除——此时应检查 max_fails 和网络连通性。
