加权轮询不是简单按weight数值比例分配请求，而是受健康状态、连接行为、流量特征等多因素影响的动态调度结果；weight=3与weight=1在理想条件下接近3:1，但实际中因超时剔除、短连接开销、处理耗时差异等常显著偏离该比例。
加权轮询不是“让权重更高就一定多接请求”的简单比例映射，而是结合调度逻辑、健康状态和连接行为共同作用的结果。实际效果差异，主要来自配置是否完整、后端是否稳定、流量特征是否匹配，而非仅看 weight 数值本身。
权重数值只决定理论分配比例
weight=3 和 weight=1 的两台服务器，在理想无故障、无超时、长连接复用充分的条件下，请求分配比接近 3:1。但真实环境中，以下因素会显著偏移这个比例：
- 某台服务器响应慢或偶发超时，Nginx 会通过 max_fails/fail_timeout 将其临时剔除，导致权重高的节点反而“掉线”，流量全涌向剩余节点
- 短连接场景下频繁建连，若未启用 keepalive，连接开销会放大弱节点延迟，使其实际吞吐远低于权重预期
- 请求体大小、处理耗时差异大时（如上传大文件 vs 简单 API），单纯按请求数计权无法反映真实算力消耗
纯轮询与加权轮询的真实表现差异
当所有服务器配置相同（weight 全为 1 或不写），轮询确实能实现长期请求数均等；但一旦存在性能落差，纯轮询会让强节点和弱节点承担相同数量的请求，结果是弱节点响应变慢、错误率上升、平均延迟拉高。而合理设置 weight 后：
- 8 核服务器 weight=3，4 核服务器 weight=1 → 强节点承担约 75% 请求，弱节点维持在可承载范围内
- 若未调权，两者各接 50% 请求 → 弱节点 CPU 持续 95%+，请求排队，P99 延迟翻倍
- 实测中，加权配置通常可降低整体平均响应时间 20%～40%，前提是配合健康检查与连接复用
影响效果的关键增强项缺一不可
只改 weight 很难看到明显改善，真正起作用的是组合策略：
- 健康感知：max_fails=2 fail_timeout=15s 可在两次失败后暂停调度，避免持续打到异常节点
- 连接复用：upstream 内加 keepalive 32，并在 location 中配 proxy_http_version 1.1 和 Connection header 清空，减少 30%+ TCP 开销
- 重试兜底：proxy_next_upstream error timeout http_500 可在失败时自动切到下一节点，提升成功率
安全后端适配会间接影响权重效果
如果后端启用 HTTPS 或需校验证书，而 Nginx 未配 proxy_ssl_verify off（测试环境）或 proxy_ssl_trusted_certificate（生产），会导致大量 SSL 握手失败，触发重试和节点剔除，使权重分配完全失真。同样，X-Real-IP 或认证头缺失可能引发后端拒绝，表面看是“权重没生效”，实则是代理链路不完整。
