权重参数本身不提升服务器物理性能，但能按后端真实能力分配请求，避免强机空转、弱机过载；必须写在upstream块内server指令后，设为正整数，配合健康检查与实测吞吐量设定才有效。
权重参数本身不提升服务器的物理性能，但它能让请求按后端真实能力分配，避免强机空转、弱机过载，从而把已有资源用得更实、更稳。
权重要设在 upstream 块里才有效
必须写在 upstream 定义中，紧贴 server 地址之后：
- ✅ 正确：
server 10.0.1.5:8080 weight=4; - ❌ 错误：写在 location 或 proxy_pass 后面；或单独成行；或用小数、负数、字符串
- weight 只对 round_robin（默认）和 ip_hash 生效，第三方算法如 fair 不识别
- 默认值是 1；设为 0 表示暂不参与分发，但仍接受健康检查探测
权重不是拍脑袋定的，得靠数据说话
别凭 CPU 使用率或“看着新”就设 weight=10。真正管用的是可测指标：
- 用 wrk 或 ab 对每台后端压测相同接口，记录稳定吞吐量（如 A：1200 req/s，B：300 req/s → 权重比 4:1）
- 硬件差异明显时，可先按 CPU 核数粗调（如 16C vs 4C → 4:1），再结合压测微调
- 权重是相对值，
weight=4和weight=8效果一样，关键看比例是否匹配实际能力 - 避免极端比例（如 100:1），否则小权重节点长期闲置，失去冗余价值
光设权重没用，必须配健康检查
静态权重不管机器是不是卡住了。没健康机制，流量照旧往慢节点上送：
- 每台 server 都加上
max_fails=3 fail_timeout=30s，连续失败 3 次就暂停转发 - 故障期间，剩余节点会按各自权重重新归一化分担流量（原 5:3:2，一台下线后变成 5:3）
- 新节点上线建议加
slow_start=30s，让权重从 0 缓慢升至设定值，防冷启动打崩 - 配合 keepalive 连接复用，减少建连开销，尤其减轻高权重节点的 CPU 压力
上线后盯住这三项指标才算真优化
配置 reload 后不能只看日志 IP 分布，得验证实际效果：
- 各节点请求数（
$request_number）是否趋近设定比例（需数百次以上请求才稳定） - 响应时间（
$upstream_response_time）有没有分化——高权重节点延迟是否明显上升 - 错误率（
$upstream_status ≥ 500）是否异常升高，可能意味着权重过高或后端存在瓶颈 - 发现某台长期高负载？优先查它自身问题（慢 SQL、PHP-FPM 队列满），而不是一味调高权重
