权重设置不加速单请求，但通过将流量导向高处理能力节点降低整体平均响应时间；需在upstream块内server指令后正确配置，基于p95延迟或吞吐量设定合理比值（建议≤1:4），并配合健康检查、least_conn等动态机制兜底。
权重设置本身不加快单个请求，但能让流量更合理地落在“能扛、能快”的节点上，从而降低整体平均响应时间。关键不是调数字，而是让权重反映真实处理能力，并配合健康机制动态兜底。
权重必须写对位置才生效
只在 upstream 块内 server 指令后 有效，且紧贴地址：
- ✅ 正确：
upstream backend { server 10.0.0.1:8080 weight=4; } - ❌ 错误：把
weight=写成独立行、放在location里、或设为小数/负数——都会导致nginx -t报错 - weight 默认为 1；设为 0 表示不参与调度，但仍接受健康检查
权重要基于可测指标设定，不是拍脑袋
用实际性能数据倒推初始值，比看 CPU 核数更可靠：
- 查各后端
$upstream_response_time日志，取 P95 延迟（比如 A 是 120ms，B 是 360ms），权重比可设为3:1（360 ÷ 120 = 3） - 压测吞吐量（如 wrk 测得 A 能扛 1500 req/s，B 是 500 req/s），按比例设
weight=3和weight=1 - 避免极端比值（如 1:10），建议最大差异控制在 1:4 内，兼顾均衡与容错
静态权重必须搭配动态保护机制
再准的权重也挡不住瞬时过载或慢响应，需靠组合策略兜底：
- 启用健康检查：
max_fails=3 fail_timeout=30s，延迟飙升或失败后自动暂停节点 - 加
least_conn：长耗时请求场景下，优先选当前连接数少的节点，缓解堆积 - 设
max_conns限制单机并发上限，防突发打穿 - 别和
ip_hash混用——它会削弱权重作用，真需会话保持建议改用 sticky cookie
验证效果不能只看配置，要看真实日志
上线后盯住三类指标，确认权重是否真正起效：
- 各后端
$upstream_addr的请求数是否在数百次后趋近设定比例 -
$upstream_response_time是否分化明显，高权重节点是否反而延迟上升（说明过载） -
$upstream_status中 5xx 错误率是否异常升高，可能是权重过高或健康检查未生效
不复杂但容易忽略
