权重拼写错误（如weigth、wight）会被nginx静默忽略，导致对应server退化为weight=1；须用nginx -t确认实际解析值，并通过stub_status或唯一响应头统计验证真实流量分布是否符合预期比例。
权重符号拼写错误在 Nginx 加权轮询中不会报错，而是被静默忽略，导致节点退化为默认 weight=1，流量比例严重失真。排查关键在于跳出“语法正确即生效”的误区，聚焦运行时行为验证。
查 nginx -T 输出确认最终解析值
nginx -t 只校验语法，无法发现语义错误。必须用 nginx -T（大写 T）输出完整生效配置，人工搜索 upstream 块：
- 查找是否出现 weigth=3、wight=3、weights=3 等错误写法——这些行会被完全跳过，对应 server 的 weight 实际为 1
- 确认每行 server 后紧跟着的是 weight=数字，且中间无换行、无多余空格或等号两侧空格（如
weight = 3会报 invalid number of arguments） - 检查是否误把 weight 写在 upstream 块外（如 location 中），这类写法直接报 unknown directive，nginx -t 就会失败
看 stub_status 或日志统计真实分发比
权重是否生效，最终要看请求实际打到哪台后端。仅靠 access log 的 $upstream_addr 不可靠（含重试地址），推荐两种方式：
- 启用 stub_status 模块（需编译时带
--with-http_stub_status_module），访问/nginx_status查看各 server 的Requests计数，对比是否接近 weight 比例（如 weight=3 和 weight=1 应接近 3:1） - 临时在每个后端加唯一响应头：
add_header X-Backend-ID "A";，然后用脚本发起 100 次请求并统计：for i in {1..100}; do curl -sI http://upstream/ | grep X-Backend-ID; done | sort | uniq -c
排除干扰性拼写错误
有些错误看似无关 upstream，实则间接让权重失效：
-
proxy_pass 地址写错：比如 upstream 名是
api_v2，但 proxy_pass 写成http://api_v2/（少下划线）或http://api-v2/（短横线），Nginx 会当作域名解析失败，fallback 到第一个 server，等效单点 -
混用 ip_hash：只要 upstream 块里有
ip_hash;，所有 weight 都被忽略，流量按客户端 IP 哈希固定到某台——哪怕你写了 weight=10 也无效 -
backup 节点误配 weight：backup 节点的 weight 永远不生效，若同时写
weight=5 backup，容易误判为“高权重 backup 会优先启用”，实际它只在所有非 backup 全不可用时才触发
结合 error.log 排除变量类拼写问题
如果在 log_format 或 set 指令中引用了类似 $upstrem_addr（少一个 e）、$backend_ulr（url 拼错）等变量，Nginx 不报错，但该字段始终为空。可在 access_log 中显式打印可疑变量，再查日志内容是否为空；更直接的是搜 error.log 中的 unknown log variable 警告行，它会明确指出哪个变量名拼错了。
