加权轮询在低并发下“不准”是因周期未跑满导致的小样本偏差，非算法失效；其本质是确定性累积计数调度，需请求总数≥3×周期长度才具统计意义，并须排除连接复用、配置覆盖等干扰。
加权轮询在低并发下看起来“不准”，通常不是算法失效，而是轮询机制的确定性本质 + 小样本偏差被放大所致。它本身不追求每 N 个请求严格按权重比例切分，而是在完整周期内趋近理论比值。低并发时周期未跑满，自然显得“偏”。排查重点是确认是否真偏离、还是正常波动，同时排除干扰因素。
理解加权轮询的周期性行为
加权轮询不是概率随机，而是基于最大权重的累积计数器调度。例如 server A(weight=3)、B(weight=1)，完整轮询周期为 4 次请求：A→A→A→B。只有连续发够 4 次以上，才开始体现 3:1；若只发 5 次，可能得到 A,A,A,B,A（4:1），看似“A 太多”——其实是周期刚开头，完全正常。
- 用 nginx -T 确认实际生效的 weight 值，避免拼写错误（如 weigth）导致回退为默认 weight=1
- 手动算出理论周期长度 = 所有 weight 的最大公约数归一后的总和（如 weight=6,4,2 → 归一为 3,2,1 → 周期长=6）
- 低并发测试时，请求总数应 ≥ 3×周期长度，否则统计无意义
排除连接复用与客户端行为干扰
低并发场景下，客户端复用单个 TCP 连接（keepalive）非常普遍。Nginx 在该连接上会倾向复用上次选择的后端，尤其当配置了 proxy_http_version 1.1 和 proxy_set_header Connection '' 时，容易造成“一个用户始终打到同一台”。这跟权重无关，是连接粒度问题。
- 临时关闭 upstream keepalive：注释掉 keepalive 指令，或设为 0
- 强制短连接测试：用 curl -H "Connection: close" 或工具如 wrk -H "Connection: close" -d 5s -c 1 发单并发、无复用请求
- 检查 access log 中同一 $remote_addr + $request_id 是否反复命中同一 $upstream_addr —— 若是，大概率是连接复用或会话保持干扰
验证是否被其他负载策略覆盖
哪怕 upstream 块里写了 weight，只要 location 或 http 块中存在更高优先级的指令，加权轮询就会被静默绕过。
- 搜索配置中是否存在 ip_hash、hash $cookie_session、least_conn 等指令 —— 它们与 weight 不兼容，一旦启用，weight 全部失效
- 检查 proxy_pass 引用的 upstream 名是否拼写一致（如写成 backend 但定义的是 backends），Nginx 会当作域名解析失败，fallback 到第一个 server
- 确认没有意外启用 sticky 模块或第三方会话模块，它们会接管分发逻辑
用最小化环境做可重现验证
脱离业务流量，构建干净测试链路，才能隔离变量：
- 停掉健康检查：max_fails 和 fail_timeout 全部删掉或设为极宽松值，防止节点被临时摘除
- 后端部署极简服务：比如每台用 Python -m http.server 启一个返回固定字符串的端口，确保响应快、无超时
- 发起明确可控的请求数：用 for i in {1..20}; do curl -sI http://test/ | grep Server; done，配合 add_header X-Upstream "A" 区分后端
- 观察前 20 次结果分布 —— 若仍严重偏离（如 20 次全到 A），说明 weight 未生效；若呈 A,A,A,B,A,A,A,B… 节奏，则算法工作正常
