加权轮询本身不导致严重不均，但权重与后端能力错配或受健康检查、重试、响应异常等干扰时会放大偏差；需验证首转流量分布是否符权重比，并排查节点是否被静默摘除或响应异常。
加权轮询本身不会自动导致负载极度不均，但当权重配置与后端真实能力严重错配，或被其他机制干扰时，就会放大偏差，让部分节点吃满、另一些空转。排查关键不是盯着 weight 数字，而是验证“流量是否真按权重走了”以及“为什么该走的没走成”。
看 access log 里 $upstream_addr 的首次分发分布
别直接统计日志里的 $upstream_addr，它可能含重试地址（比如第一次发给 B 超时，自动重试 A，日志记为 “B, A”），导致比例失真。要确认首转目标：
- 临时关闭健康检查（注释掉 max_fails / fail_timeout）和 proxy_next_upstream 相关重试逻辑，避免 fallback 干扰
- 用短连接压测：wrk -c 100 -d 30s --latency -H "Connection: close" http://your-domain/
- 在 access log 中提取每条记录的首个 upstream 地址：grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}:[0-9]+' access.log | head -n 1000 | sort | uniq -c | sort -nr
- 对比结果是否接近你配置的权重比（如 weight=6 和 weight=2 应约 3:1）
查 error log 确认有没有节点被“悄悄踢出”
即使 weight 写对了，只要某节点因响应慢、超时或返回非 2xx，Nginx 就会按 max_fails 规则把它标记为不可用，在 fail_timeout 期间彻底跳过——这时权重再高也分不到流量。
- 搜错误日志中是否集中出现某个 backend 的失败：grep "upstream.*failed" /var/log/nginx/error.log | grep "192.168.1.20:8080"
- 检查该节点是否频繁触发 listen overflows（netstat -s | grep "listen overflows"）、连接数爆满（ss -s | grep "inuse"）、或后端自身报 OOM / too many open files
- 确认所有 server 行的健康检查参数是否一致：不能有的写 max_fails=2 fail_timeout=30s，有的完全没写——不一致会导致部分节点永远在线、另一些动不动下线
验证各节点响应行为是否真正一致
加权轮询不校验后端响应质量。如果某节点返回的响应头过大（如带长 JWT 或冗余 Cookie）、HTTP 状态行格式异常、或响应体含非法字符，Nginx 在读取阶段就直接断连并记 502，而这个节点在轮询序列里还一直存在，造成“看起来有流量、实际全失败”的假象。
- 逐个直连测试：curl -v http://192.168.1.10:8080/health 2>&1 | grep '^
- 若某节点响应头大小明显超标（例如超 4KB），且 Nginx 没调大 proxy_buffer_size 或 large_client_header_buffers，就会只在这台机器上反复报 “upstream sent too big header” 类 502
- 用 tcpdump 抓包对比：同一请求打到不同后端时，TCP 层 FIN/RST 行为是否一致；是否存在某节点在 TLS 握手后迟迟不发 HTTP 响应
排除 upstream 外部干扰因素
有些配置看似无关，实则会让加权轮询完全失效：
- 检查 location 块中 proxy_pass 是否拼写正确：写成 proxy_pass http://backends/，但 upstream 名是 backend（少 s），Nginx 会当成域名解析，失败后 fallback 到第一个 server，等效单点
- 确认没混用 ip_hash 或 hash $cookie_jsessionid：只要启用任意一种会话保持，weight 就被忽略，Nginx 文档明确说明
- 检查是否误用了拼错指令：weigth、max_conn（应为 max_conns）、fail_time_out（应为 fail_timeout）——Nginx 静默忽略，权重或健康检查实际未生效
- 用 nginx -T 输出最终生效配置，搜索 upstream 块，确认每个 server 后面解析出的 weight 值是你写的那个，而不是默认 1
