最简单有效的负载均衡权重配置是在upstream块中为每台服务器设weight，需位于http{}内、server{}外，紧接server地址后；权重为正整数相对比例，应基于实测QPS或CPU折算，并配合max_fails、fail_timeout、slow_start等健康机制，避免与ip_hash等策略混用。
直接在 upstream 块里为每台后端服务器设 weight，是最简单也最有效的做法。它不依赖额外模块，把硬件能力差异翻译成可读、可调、可验证的整数比例。
权重必须写在正确位置
weight 只能在 http{} 块内、所有 server{} 外的 upstream 中定义，且必须紧接在 server 地址之后：
- ✅ 正确：
upstream my_backend { server 10.0.0.1:8080 weight=5; } - ❌ 错误：写在
location或server块里，Nginx 会报unknown directive "weight" - ❌ 错误：绕过
upstream直接proxy_pass http://10.0.0.1:8080，weight 完全无效
数值要真实反映服务能力
weight 不是百分比，也不是小数，而是正整数相对比例。设得准，才能避免“新机空转、旧机打满”：
- 以最强节点为基准（如设
weight=10），其余按实测 QPS 或 CPU 核心数折算：旧机性能约为新机 40%，就设weight=4 - 避免用太小的数（如 1 和 2），微小误差会导致流量偏差放大；推荐统一放大 10 倍——
10:4:2比5:2:1更易对齐实际负载 - 上线前建议用
wrk对单台压测相同并发下的 QPS，直接按比例设 weight，结果最可靠
光设 weight 不够，必须配健康机制
weight 只管“正常时怎么分”，不管“出问题了怎么办”。没健康检查，慢节点照样收请求：
- 每个
server行加上max_fails=2 fail_timeout=30s：连续失败两次，暂停转发 30 秒 - 故障期间，剩余健康节点会按各自 weight 重新归一化分担流量（例如原 5:3:2，C 下线后 A/B 实际承接比变为 5:3）
- 新节点上线或恢复可用时，加
slow_start=60s，让流量从 0 开始逐步爬升，防冷启动冲击 -
weight=0可临时下线节点，且不触发健康检查，适合维护窗口期
避开常见冲突和陷阱
有些配置看似合理，实则会让 weight 失效或引发意外行为：
-
ip_hash与 weight 冲突：启用后 weight 仅用于故障剔除后的备用选择，不再影响日常分发 - 别混用
hash $request_uri或least_conn等策略，它们不识别 weight 参数 - 修改 weight 后必须先运行
nginx -t验证语法，再nginx -s reload，否则可能直接中断服务 - weight=0 的节点仍会被健康检查探测（除非显式加
down）；而down则完全跳过该节点，连探测都不做
