直接在upstream块中为高性能服务器设置更大的整数权重值，就能让它承接更多请求；权重必须位于http{}内独立upstream中且紧接server地址后，需以实测qps为依据设定比例（如6:3:2），并搭配max_fails、fail_timeout等健康机制，避免与ip_hash等策略混用。
直接在 upstream 块中为高性能服务器设置更大的整数权重值，就能让它承接更多请求。关键是数值要真实反映处理能力差异，而不是随意填大数字。
权重必须写对位置才生效
weight 参数只能出现在 http{} 块内、独立定义的 upstream 中，且紧接在 server 地址之后：
- ✅ 正确：
upstream backend { server 192.168.1.10:8080 weight=5; } - ❌ 错误：写在
server或location块里，Nginx 会报unknown directive "weight" - ❌ 错误：用
proxy_pass http://192.168.1.10:8080直连 IP，绕过 upstream 名称，weight 完全不生效
权重值怎么定才合理
推荐以实测 QPS 为依据，比纯看 CPU 核数更可靠：
- 对每台后端单独压测（如用
wrk -t4 -c100 -d30s http://ip:port/health），记录稳定支撑的 QPS - 假设结果为：A 服务器 1200 QPS，B 为 600，C 为 400 → 比例 ≈ 6 : 3 : 2
- 直接设为
weight=6、weight=3、weight=2，总权重 11，理论分发比就是 54.5% : 27.3% : 18.2% - 避免用太小的数（如 3 和 1），误差容易放大；统一放大 10 倍（如 30 和 10）更稳
光设 weight 不够，必须配健康机制
weight 只管“正常时怎么分”，不管“出问题了怎么办”。没健康检查，慢节点照样收请求：
- 每个
server行加上max_fails=2 fail_timeout=30s：连续失败 2 次，30 秒内不再转发 - 故障期间，剩余健康节点会按各自 weight 重新归一化分担流量（例如原 6:3:2，C 下线后 A/B 实际承接比变为 6:3）
- 新节点上线或恢复可用时，加
slow_start=60s，让流量逐步爬升，防冷启动冲击 - 临时下线用
weight=0，它仍接受健康检查探测；若想完全跳过探测，改用down
避开常见冲突和陷阱
有些配置会让 weight 失效或引发意外行为：
-
ip_hash与weight冲突：启用后 weight 仅用于故障剔除后的备用选择，日常分发失效 - 别混用
hash $request_uri或least_conn等策略，它们不识别 weight 参数 - 修改后必须先运行
nginx -t验证语法，再nginx -s reload，否则可能中断服务 - 未显式写 weight 的服务器，默认为 1，容易打破预期比例，所有 server 行建议都明确写出 weight
