关键是通过$upstream_addr日志验证请求是否严格按顺序循环分发，需确保upstream配置纯净（无weight、ip_hash等干扰）、健康检查参数统一，并结合rr.log观察192.168.1.10→192.168.1.11→192.168.1.12→192.168.1.10的循环序列。
轮询模式下监控流量分配，关键不是“看总量”，而是验证请求是否真正在后端服务器间按顺序均匀流转。最直接有效的方式是结合 Nginx 日志与 upstream 分发记录，不依赖外部工具也能快速定位偏差。
用 $upstream_addr 记录每次分发目标
在 server 或 location 块中配置自定义日志格式，显式输出请求最终落到哪台 upstream 机器：
- 添加 log_format： log_format roundrobin_log '$remote_addr - [$time_local] "$request" $status $upstream_addr';
- 启用该格式的日志： access_log /var/log/nginx/rr.log roundrobin_log;
- 确保 upstream 块中所有 server 行无 weight、ip_hash 等干扰项，仅保留纯 IP 和端口（如 server 192.168.1.10:8080;）
通过日志验证轮询序列是否成立
发起连续请求（例如用 curl 循环 12 次），然后查看 rr.log：
- 理想输出应呈现严格循环：
10.0.1.5 - [29/Jun/2026:13:05:01] "GET /health HTTP/1.1" 200 192.168.1.10:8080
10.0.1.5 - [29/Jun/2026:13:05:02] "GET /health HTTP/1.1" 200 192.168.1.11:8080
10.0.1.5 - [29/Jun/2026:13:05:03] "GET /health HTTP/1.1" 200 192.168.1.12:8080
10.0.1.5 - [29/Jun/2026:13:05:04] "GET /health HTTP/1.1" 200 192.168.1.10:8080 - 若出现某台 IP 长时间重复或跳步，说明健康检查参数不一致（如某台 max_fails=1，另一台 max_fails=5），或存在未注释干净的 ip_hash 指令
配合 vhost_traffic_status 查看各 upstream 实时请求数
启用 nginx-module-vts 后，在 http 块中配置：
- vhost_traffic_status on;
- vhost_traffic_status_zone;
- 在 location /status 中启用 HTML 展示，并确保访问控制已设
- 打开 /status 页面 → 切换到 “Upstreams” 标签页 → 找到你的 upstream 名称 → 观察每台 server 的 “Requests” 列数值是否随时间同步缓慢增长
- 该值反映的是该 server 自启动以来累计接收请求数，长期观察其差值应接近相等（例如三台机分别为 1203、1201、1205）
避免常见误判陷阱
轮询行为本身确定性强，但监控失效往往源于配置细节：
- upstream 块顶部残留 # ip_hash 注释——Nginx 不忽略注释行中的指令关键词，必须整行删除
- 部分 server 行带 backup 或 down 标记，导致列表实际参与轮询的节点数减少
- 不同 server 设置了不同的 fail_timeout，造成故障摘除窗口不一致，间接打破轮询节奏
- 使用了 proxy_next_upstream 且后端返回 502/504，请求被重试并可能落到下一节点，日志里显示为“非轮询”，实为重试逻辑所致
