加权轮询配置错误不会报错但会导致流量偏斜，需验证实际分发是否匹配权重：检查weight拼写、upstream名称一致性、哈希指令覆盖、统计$upstream_addr分布。
加权轮询配置参数错误不会报错，但会让 Nginx 退化为默认轮询或行为失真，导致流量明显偏斜。关键不是看配置写没写对，而是验证实际分发是否匹配权重比例。
检查 weight 指令是否被静默忽略
Nginx 对拼写错误的指令（如 weigth、wight、weights）完全不识别，直接跳过该行，对应 server 回退为默认 weight=1。这种错误无法通过 nginx -t 发现。
- 用
nginx -T 2>/dev/null | grep -i -A2 -B2 "weigth\|wight\|weights"扫描所有疑似拼错行 - 检查 upstream 块中每个
server行是否都显式写了weight=；没写的默认是 1，可能与预期严重不符 - 特别注意 include 进来的配置文件——错误常藏在被引用的 conf 里
确认 upstream 名称是否匹配 proxy_pass
location 中写 proxy_pass http://backend/;，但 upstream 块定义的是 upstream backends { ... }（少个 s），Nginx 会把 backend 当作域名解析，DNS 失败后 fallback 到第一个 server，等效单点转发。
- 执行
nginx -T | grep -A10 "upstream" | grep -E "^upstream|proxy_pass"，人工核对名称是否完全一致（含大小写和下划线） - 若使用变量拼接 upstream 名（如
proxy_pass http://$upstream_name），需确认变量值稳定且已正确定义
识别哈希类指令对加权轮询的覆盖
只要 upstream 块启用了 ip_hash、hash $request_uri 或 hash $cookie_sessionid，weight 就完全失效。Nginx 官方文档明确说明：哈希策略优先级高于权重。
- 搜索配置中是否存在
ip_hash、hash、sticky等关键字，并确认它们是否作用于同一 upstream 块 - 即使只在某个 location 中用了
proxy_pass指向该 upstream，只要 upstream 块本身含哈希指令，整个块都受约束 - 临时注释掉哈希指令，reload 后用短连接压测（如
wrk -c100 -d5s --timeout 1s http://test/），观察$upstream_addr分布是否回归权重比
验证实际请求分配是否符合权重比例
理论权重比（如 3:1）不等于实时百分比，但大量请求下应趋近该比例。偏差超过 ±10% 就说明配置未生效或被干扰。
- 在 log_format 中加入
$upstream_addr，用awk '{print $NF}' access.log | sort | uniq -c | sort -nr统计各后端出现次数 - 启用 stub_status（需编译支持），访问
/nginx_status查看各 server 的活跃连接数和累计请求计数（部分版本需配合 vts 模块） - 避免用长连接测试——keepalive 会复用连接，掩盖轮询逻辑；务必用禁用 keepalive 的短连接（如 curl -H "Connection: close"）或 wrk 参数
--timeout 1s
