权重不能直接平衡负载，仅通过调整请求分发概率间接引导流量；其效果依赖算法（仅 round_robin 和 ip_hash 生效）、健康检查与状态标记协同，并需结合 least_conn 或响应时间感知算法及监控验证。
权重优化不能直接“平衡”负载差距，而是通过调整请求分发概率，间接引导流量向高配节点倾斜，从而缓解整体不均。真正实现负载均衡，需要权重配合算法选择、健康检查和状态标记协同工作。
权重只影响轮询类算法的请求分布
weight 参数仅在 round_robin（默认） 和 ip_hash 算法下生效；least_conn、hash、random 等算法完全忽略 weight。这意味着：
- 若用 least_conn（最少连接），即使 server A 权重设为 10、server B 设为 1，Nginx 仍会优先把新请求发给当前连接数更少的那台——权重无效
- 若启用了 ip_hash，weight 不改变哈希绑定逻辑，只在某台被踢出后、回退到备用节点时起作用
- 单纯调高某台机器的 weight，无法让它的 CPU 或响应时间自动降下来；它只是更大概率被选中
权重值不是精确比例，而是调度倾向
weight=3 和 weight=1 的两台服务器，理论请求比接近 3:1，但这是统计意义上的长期趋势：
- 小流量下可能连续 6 次都打到 weight=3 的节点——这属于正常行为，Nginx 不维护全局计数器
- 真实比例需在数百次以上请求中观察 access_log 才能验证是否趋近设定值
- 权重不能补偿后端性能瓶颈：如果 weight=3 的节点本身响应慢、排队多，反而会放大延迟和超时
必须搭配状态标记与健康检查才有效
仅靠 weight 无法应对运维现实。要缩小实际负载差距，需组合使用：
- max_fails + fail_timeout：让高权重节点一旦失败，恢复后更快重新纳入流量（因健康检查更积极）
- backup：将低配或临时扩容节点设为 backup，只在主力节点全不可用时启用，避免拖累整体水位
- down：维护期间直接标 down，彻底隔离，不参与任何调度（包括健康探测）
- 配合 least_conn 或 响应时间感知算法（如第三方模块），比纯 weight 更贴近真实负载
验证是否真正在缩小差距
改完权重后不能只看配置是否生效，要确认效果：
- 先运行 nginx -t，确保语法无误再 reload
- 用 curl -I 快速确认代理仍通，返回 200
- 查各后端 access_log，按时间窗口（如每分钟）统计请求数，对比是否符合权重比趋势
- 同步监控各节点的 CPU、连接数、平均响应时间——若某节点请求数下降但响应时间飙升，说明它仍是瓶颈，需优化应用而非调 weight
