加权轮询通过weight参数按服务器处理能力比例分配流量，避免负载失衡；需配合least_conn应对实时负载、max_fails/fail_timeout实现故障隔离，并验证实际流量占比是否符合权重设定。
按能力配比流量，让每台机器跑在合理区间
新旧服务器混用、云主机规格不一、容器实例资源差异大——这些常见场景下，纯轮询会把请求平均分，结果是低配节点 CPU 长期 90%+，高配节点才用 30%。加权轮询通过 weight 参数显式表达相对处理能力：
- 若一台服务器 CPU 核心数是另一台的 2 倍，可设
weight=2vsweight=1 - 若某节点内存翻倍、IO 更强，且实测吞吐高约 40%，可设
weight=7vsweight=5 - 权重值无绝对上限，只看比例关系；Nginx 按总权重归一化后分配，比如
weight=4、weight=2、weight=1对应约 57%、29%、14% 的长期流量占比
必须搭配 least_conn 才能应对真实负载波动
加权轮询只管“历史比例”，不管“此刻连接数”。一个 weight=2 的节点如果正在处理大量长连接（如 WebSocket、文件上传），实际已接近满载，但轮询仍会继续派发新请求。
- 在
upstream块中启用least_conn指令，Nginx 会优先选当前活跃连接最少的节点，再按权重微调 - 尤其适用于微服务中存在耗时接口、异步任务或连接复用率高的场景
- 注意：
least_conn和weight可共存，Nginx 内部会做加权最小连接选择，不是简单取最小值
配套健壮性配置不能省
权重再合理，若故障节点不自动隔离，流量照样打空转，整体服务能力就打折。
- 每个
server行加上max_fails=3 fail_timeout=30s，30 秒内连续失败 3 次即临时摘除 - 配合
keepalive 32复用到后端的 TCP 连接，降低握手开销，提升单位时间请求数 - 务必设置
proxy_set_header X-Real-IP $remote_addr，确保后端限流、日志和审计基于真实客户端 IP
验证是否真按权重运行
别只看配置写了 weight，要确认流量走向符合预期：
- 用脚本快速发起 20+ 请求：
for i in {1..20}; do curl -s http://your-domain/api/test | head -1; done - 检查各后端 access 日志中请求计数，比例应接近设定权重比（允许小幅波动）
- 若发现某节点始终偏低，检查它是否被健康检查误判剔除，或是否存在防火墙、超时等隐性拦截
