加权轮询实际分配严重偏离设定比例（如weight=3:1却呈9:1或1:1），主因是健康检查剔除、会话保持指令覆盖、连接复用干扰及流量特征失配等隐性因素干扰调度逻辑，非权重配置错误。
加权轮询分配结果明显偏离设定比例（比如 weight=3:1 却跑出 9:1 或 1:1），不是权重写错了，而是多个隐性环节在“悄悄改写”调度逻辑。排查要从请求路径逐层验证，重点看真实分发行为是否被覆盖、干扰或抑制。
确认是否真在走加权轮询
很多情况下，你以为启用了 weight，其实根本没生效：
- 检查 upstream 块里有没有混用 ip_hash、hash $request_uri、sticky 等会话保持指令——只要存在任一这类指令，weight 全部失效，流量按哈希规则绑定，不再轮询
- 查看 Nginx 配置中是否误将 least_conn 写在 upstream 第一行（如
upstream backend { least_conn; server ... }），它会覆盖轮询逻辑，优先按连接数分发 - 用
nginx -T | grep -A 10 "upstream.*backend"输出实际加载的 upstream 定义，确认 weight 值和指令顺序未被模板或 include 覆盖
查后端节点是否被健康检查动态剔除
weight 再高，节点不可用也接不到请求。Nginx 默认不启用健康检查，但一旦配了 max_fails，异常节点会被临时下线：
- 检查 access log 中 $upstream_addr 字段，观察高权节点是否长期缺席；再查 error log 是否频繁出现 "no live upstreams" 或 "connect failed"
- 确认每台 server 行是否都配置了
max_fails=2 fail_timeout=15s类似参数，且后端确有偶发超时或 5xx ——哪怕只失败两次，该节点就会停摆 15 秒，期间所有流量涌向剩余节点 - 临时去掉健康检查（注释掉 max_fails/fail_timeout），reload 后观察比例是否回归预期，可快速定位是否为健康机制导致的“假偏差”
看连接复用是否掩盖了真实分流
短连接场景下，日志请求数≈分发数；但长连接（keepalive）下，一个 TCP 连接承载大量请求，全落到同一台后端，造成“看起来分得不均”：
- 在后端服务器执行
ss -tnp | grep :8080 | wc -l，统计各节点 ESTAB 连接数，对比是否严重倾斜；若连接数均衡但请求数不均，说明是客户端复用导致的假象 - 检查 Nginx upstream 是否配置了
keepalive 32，同时 location 中是否设置了proxy_http_version 1.1和proxy_set_header Connection ''——这些会强化连接复用，放大单节点负载 - 临时关闭后端 keepalive（如 Spring Boot 设
server.tomcat.connection-timeout=5000），或在 Nginx 中禁用 upstream keepalive，观察请求数分布是否趋近权重比
验流量特征是否让权重“失准”
weight 按请求数分配，但不同请求资源消耗差异极大，会导致实际负载与请求比例脱钩：
- 压测单个大文件上传接口 vs 小 JSON 查询，观察两台 weight 不同的后端 CPU/内存使用率，若弱节点在处理大请求时迅速打满，说明 weight 未反映真实算力瓶颈
- 检查是否有部分 URL 固定打到某台（如 /report/export 总发给 weight=1 的机器），需确认是否被 location 或 proxy_pass 的匹配规则绕过了 upstream
- 若业务含 WebSocket/gRPC 流式调用，轮询本身就不适合——连接建立后长期驻留，应改用
least_conn或会话保持，而非强行调 weight
