nginx后端权重必须在upstream块内server指令中用weight=参数指定，仅对round_robin和ip_hash生效；权重为正整数，默认1，设0表示不参与轮询但接受健康检查。
直接说结论：Nginx后端权重必须写在 upstream 块内的 server 指令里，用 weight= 参数指定，且只对 round_robin（默认轮询）和 ip_hash 算法生效；fair、url_hash 等第三方算法不认这个参数。
weight 参数只能用在 upstream 的 server 行里
很多人误以为 weight 可以写在 location 或 proxy_pass 附近，其实完全无效。它只属于 upstream 上下文，且必须紧贴 server 地址之后：
-
upstream backend { server 10.0.0.1:8080 weight=5; }✅ 正确 -
upstream backend { server 10.0.0.1:8080; weight=5; }❌ 错误，weight 不是独立指令 -
location / { proxy_pass http://backend; weight=3; }❌ 语法错误，Nginx 启动会报unknown directive "weight"
权重值必须是正整数，默认为 1；设为 0 表示该节点不参与轮询（但依然会被健康检查探测）。
weight 和实际请求比例不是严格数学关系
权重影响的是“概率分布”，不是精确计数。比如 weight=3 和 weight=1 的两台服务器，在小流量下可能连续 5 次都打到 weight=3 的那台——这是正常现象，Nginx 不做请求计数器式调度。
- 真实比例需在数百次以上请求中统计才接近理论值（如 3:1）
- 若启用
ip_hash，weight 仅用于故障剔除后的备用选择，不改变哈希绑定逻辑 - 若同时配置
max_fails和fail_timeout，权重高的节点一旦失败，恢复后会更快被重新纳入流量池
weight 配合 backup 和 down 才能应对真实运维场景
单纯调权重解决不了扩容、维护或临时降级问题。必须组合使用状态标记：
-
server 10.0.0.1:8080 weight=3;—— 主力节点 -
server 10.0.0.2:8080 weight=1 backup;—— 仅当所有非 backup 节点不可用时才启用 -
server 10.0.0.3:8080 down;—— 强制摘除，不参与任何调度（包括健康检查）
注意：backup 节点不会出现在 ip_hash 的哈希计算中，但会参与 round_robin 的权重分配逻辑（只是默认不启用）。
reload 之前必须做语法检查，否则直接宕机
改完 weight 后最常踩的坑是忘记验证配置，导致 nginx -s reload 失败，worker 进程退出，整个代理中断：
- 永远先运行
nginx -t，看到test is successful再 reload - 权重值写错（如负数、小数、字符串）会导致
nginx -t报invalid number of the "weight" parameter - 修改后建议用
curl -I http://your-vip/快速验证是否仍能返回 200，再查后端 access_log 确认流量是否按预期分发
权重本身不消耗额外资源，但盲目设过高（比如 weight=100）而没配 max_fails，可能让单点过载却无法自动熔断——这才是线上最容易被忽略的隐性风险。
