nginx upstream 中 server 的 weight 参数用于按后端实际能力分配流量，仅在 round_robin 和 ip_hash 算法下生效，须紧贴 ip:端口书写，不可为负数或小数，配合动态权重机制可提升集群吞吐、降低延迟并规避单点过载。
直接在 upstream 块里给 server 指令加 weight= 参数，就能让 Nginx 按能力分发流量。这不是“多分点请求”那么简单，而是让每台后端承担它真能扛住的负载，避免有的机器吃撑、有的闲着——集群整体吞吐上去了，平均延迟降下来了，单点过载风险也少了。
权重必须写对位置才生效
weight 只认 upstream 上下文，而且得紧贴在 IP 和端口后面：
- ✅ 正确写法：
server 10.0.0.1:8080 weight=3; - ❌ 错误写法：写在
location或proxy_pass后面；或者单独成行如server 10.0.0.1:8080;下面再写weight=3;；或者设成小数、负数、字符串——这些都会让nginx -t报错 - weight 默认值是 1；设为 0 表示不参与轮询，但健康检查仍会探测它
权重只对部分算法起作用
它只在 round_robin（默认）和 ip_hash 下生效：
- 在
round_robin中，weight 决定请求概率分布，比如weight=3和weight=1的两台，理论分流比约是 3:1 - 在
ip_hash中，weight 不影响哈希绑定逻辑，只在某节点失效时，作为备用选择的优先级参考 -
least_conn、hash $request_uri、fair等第三方或内置非轮询算法，完全不识别 weight 参数
静态权重要结合真实指标设定
不能光看 CPU 使用率就拍脑袋定值。建议用实际观测数据反推：
- 查 Nginx 日志里的
$upstream_response_time字段，统计各节点 P95 延迟，延迟低的可适当提高权重 - 如果一台 RTT 是 1.2ms，另一台是 4.1ms，归一化后权重可设为 5 和 1，而不是简单按倒数取整
- 权重不是精确比例控制器——少量请求下连续打到同一台是正常现象；真实分流效果需在数百次以上请求中观察才接近理论值
- 搭配
max_fails=2 fail_timeout=15s，短时高延迟会触发临时剔除，和权重形成协同保护
动态权重才是应对真实波动的关键
静态配置扛不住性能劣化、网络抖动或突发流量。生产环境推荐两条实用路径：
- OpenResty + Lua：用
ngx.timer.at每 2–5 秒探测后端延迟，按公式weight = base × (ref_rt / actual_rt)²动态计算，并通过balancer.set_current_peer()在内存中更新，无需 reload -
nginx-upstream-dynamic-servers + HTTP API：编译加载模块后，脚本定时拉取 Prometheus 指标（例如
http_request_duration_seconds_bucket{le="0.2"}），算出新权重，再 POST 到/upstream/servers接口
