要验证Nginx轮询流量分配是否均匀，需模拟真实请求并采集足够样本：确保后端返回可识别标识、开启访问日志、发起无缓存且串行的短连接请求（如ab -c 1 -n 1000），统计响应标识频次，理想情况下N台后端计数应基本均等（如3台各约333次）；差异超±5%时需检查weight设置、服务状态及是否误启ip_hash等非轮询策略。
要验证 Nginx 轮询（round-robin）模式下后端服务的流量分配是否均匀，核心是模拟真实请求、采集足够样本，并排除干扰因素——不能只看几条日志或单次 curl 结果。
准备一致的后端服务与监控点
确保所有 upstream server 返回可识别的标识（如响应头 X-Server-ID 或响应体中包含实例名），便于后续归因。同时，在每台后端服务上开启访问日志，记录客户端 IP、时间戳和请求路径；若使用容器或云环境，建议额外记录宿主机/实例 ID，避免因负载均衡器透传 IP 导致统计偏差。
发起足够数量且无缓存的请求
轮询策略按请求顺序分发，单连接多次请求（如 keepalive）可能命中同一台后端，造成误判。推荐用以下方式压测：
- 使用 curl + 循环脚本：每次新建连接，加 -H "Cache-Control: no-cache" 和随机查询参数（如
?t=123456）绕过代理或浏览器缓存 - 用 ab（Apache Bench） 或 wrk 并设置 -c 1 -n 1000（并发 1，总请求数 1000），保证请求严格串行，完全反映轮询顺序
- 避免使用浏览器直接刷新——会复用连接、触发预加载、带 cookies，干扰结果
统计并分析分配结果
收集全部响应后，提取后端标识字段，做频次统计。例如用 awk 统计响应头：
curl -s http://your-nginx/ | grep "X-Server-ID" | awk '{print $2}' | sort | uniq -c | sort -n
理想情况下，N 台后端的计数应基本接近（如 3 台各约 333 次）。若差异超过 ±5%，需检查：
- upstream 中是否有 weight 设置未重置（默认 weight=1，但显式写了 weight=2 就不是纯轮询）
- 是否有某台 server 状态异常（如 max_fails 触发临时摘除，即使健康检查未失败）
- Nginx 是否启用了 ip_hash 或 hash $request_uri 等其他负载策略（配置中注释不等于未生效）
注意连接复用与健康检查的影响
keepalive 连接池会让单个 client 复用 TCP 连接，导致后续请求持续打到同一台后端——这不属于轮询失效，而是 HTTP/1.1 行为。测试时务必关闭 keepalive（在 upstream 中设 keepalive 0）或使用短连接。另外，健康检查（health_check）若配置了 fail_timeout 和 max_fails，短暂超时也会临时剔除节点，让剩余节点承接更多流量，需确认所有后端在测试期间始终处于 up 状态（可通过 nginx -T | grep -A 10 "upstream" 和 /status 模块验证）。
