Nginx的weight参数需结合健康检查、least_conn及实测性能动态设定，仅调权重无法优化流量分配；应以P95响应时间为基准计算权重，搭配max_fails、fail_timeout和proxy_next_upstream实现故障自动切换，并通过日志频次、延迟与错误率验证效果。
Nginx 的 weight 参数本身不直接“优化流量分配比”，而是让请求按服务器相对处理能力做长期倾向性分发。真正实现任务流量合理分配，靠的是权重设定 + 健康检查 + 连接策略的协同，而不是单改一个数字。
权重值要基于实测吞吐或延迟来设
凭 CPU 核数、内存大小设 weight 容易失真，因为瓶颈常在磁盘 IO、锁竞争或慢查询。更可靠的做法是：
- 对每台后端用相同压测工具（如
wrk -t4 -c100 -d30s）测出稳定 QPS 或 P95 响应时间 - 以性能最好的节点为基准，其余节点 weight = 基准 P95 ÷ 自身 P95（四舍五入取整）
- 例如：A（P95=80ms）、B（P95=200ms）、C（P95=160ms）→ weight ≈ 1 : 0.4 → 1 : 0.5 → 取整为 1:1:1，说明三者实际承载力接近，强行设成 5:2:3 反而造成倾斜
必须搭配健康检查，否则权重失效
weight 只对“健康节点”生效。一台 weight=5 的机器若正在卡顿，Nginx 不会自动绕过它——除非触发失败机制：
- 每个
server行加上max_fails=3 fail_timeout=30s - 在
location中配proxy_next_upstream error timeout http_500 http_502 http_503 http_504 - 这样请求失败时自动切到下一个加权节点，避免把流量持续打向已响应缓慢的实例
长连接或耗时任务场景，加 least_conn 更公平
纯轮询+weight 在请求处理时长差异大时容易堆积连接。比如有文件上传、报表导出等接口：
- 在
upstream块开头加least_conn;（注意不能和ip_hash共存） - 它会让新请求优先落到当前活跃连接最少的节点，既尊重权重倾向，又缓解瞬时堆积
- 示例配置：
upstream app { least_conn; server 192.168.1.10:3000 weight=4 max_fails=3 fail_timeout=30s; server 192.168.1.11:3000 weight=2 max_fails=3 fail_timeout=30s; }
上线后必须验证真实效果，不是看配置是否生效
reload Nginx 后，别只查进程是否启动成功，要盯三项指标：
- 各后端 IP 在 access log 中出现频次（用
awk '{print $NF}' access.log | sort | uniq -c），数百次以上才趋于理论比例 - 每台后端的 P95 延迟是否同步上升——如果高 weight 节点延迟明显变长，说明它实际扛不住，weight 设高了
- 错误率（尤其是 5xx）是否某台异常突出，可能暴露应用层瓶颈（如未调优的数据库连接池）
权重不是一锤定音的静态参数，建议每周结合监控数据微调一次。比如某台机器升级 SSD 后延迟下降 25%，可将其 weight 提升 1～2 点。
