权重调整是nginx集群实现负载均衡的核心手段，需在upstream块内server指令中正确配置weight参数，仅对round_robin和ip_hash生效，配合健康检查与动态调控可提升集群整体性能。
权重调整是 Nginx 集群实现资源合理分发的核心手段，不是简单“多分一点流量”，而是让每台后端服务器承担与其实际能力匹配的负载，从而提升整体吞吐、降低平均延迟、避免单点过载。它本身不提升单机性能，但能显著改善集群层面的资源使用表现。
权重必须写对位置才生效
weight 参数只能出现在 upstream 块内的 server 指令中，且紧贴 IP 和端口之后：
-
正确写法：
server 10.0.0.1:8080 weight=3; -
错误写法：把 weight 写在 location 或 proxy_pass 后面；或写成独立行如
server 10.0.0.1:8080; weight=3;；或设为小数、负数、字符串——这些都会导致 nginx -t 报错。 - weight 仅对 round_robin（默认）和 ip_hash 生效；第三方算法如 fair、url_hash 不识别该参数。
- 默认值为 1；设为 0 表示不参与轮询，但仍接受健康检查探测。
静态权重要结合节点真实能力设定
不能只看 CPU 或内存空闲率就拍脑袋定权重。应综合响应时间、处理能力、稳定性等维度：
- 用
$upstream_response_time和$request_time日志字段统计各节点 P95 延迟，延迟低的可适当提高权重。 - 若某节点 RTT（网络往返时延）为 1.2ms，另一台为 4.1ms，归一化后可设权重为 5 和 1，而非简单按倒数取整。
- 权重不是精确比例控制器——weight=3 和 weight=1 的两台机器，在少量请求下可能连续打到同一台，属正常行为；真实分流效果需在数百次以上请求中观察。
- 配合
max_fails=2 fail_timeout=15s，让短时高延迟自动触发临时剔除，与权重调节形成协同保护。
动态权重才是应对真实波动的关键
静态配置无法响应后端性能劣化、网络抖动或突发流量。生产环境推荐以下三种可行路径：
-
OpenResty + Lua 实时调控：适合已有 OpenResty 环境的场景。用
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接口。 - nginx-upsync-module + Consul/etcd：云原生首选。后端应用启动/下线或指标异常时，由 sidecar 自动更新 Consul KV 中的 JSON 节点列表（含 weight 字段），Nginx 每 300ms 同步一次，天然支持权重热更新。
权重必须和其他状态标记配合使用
单独调权重解决不了维护、扩容或故障隔离问题：
-
backup：仅当所有非 backup 节点不可用时启用，适合灾备节点；它参与 round_robin 权重分配，但不参与 ip_hash 计算。 -
down：强制摘除，不参与任何调度（包括健康检查），适合计划内停机。 - 组合使用示例：
server 10.0.0.2:8080 weight=5 max_fails=3;+server 10.0.0.3:8080 down;+server 10.0.0.4:8080 backup weight=2; - 每次修改后务必执行
nginx -t验证语法，再nginx -s reload，避免配置错误导致代理中断。
