Nginx加权轮询并非严格按权重比例实时分配，而是通过current_weight与effective_weight动态调整：每次所有节点current_weight累加自身weight，选最大者并减去sum_weight；偶发失败会降低effective_weight，导致短期不均。
加权轮询（Weighted Round Robin）在 Nginx 中实际分配请求时，**并不严格按权重比例实时累加分配**，而是通过一个内部“当前权重”（current_weight）和“有效权重”（effective_weight）机制动态调整，导致短期观察常出现“分配不均”的错觉。排查关键在于理解该算法逻辑，而非简单对比权重比值与请求计数比值。
理解 Nginx 加权轮询的真实调度逻辑
Nginx 不是每轮都按 weight[1]:weight[2]:... 直接切分请求数，而是：
- 每个 upstream server 维护两个值：weight（配置的静态权重）和 current_weight（运行时动态值，初始为 weight）
- 每次选 server 时，所有节点的 current_weight 同时加上各自的 weight；然后选出 current_weight 最大的节点，为其 current_weight 减去所有节点 weight 总和（sum_weight）
- 当某节点因失败被临时降权（effective_weight 减少），其 current_weight 增长变慢，进一步影响短期分布
? 举例：后端为 server A weight=3; server B weight=1;，前 8 次请求调度序列为：A, A, B, A, A, B, A, A —— 并非严格 3:1（如 6:2），而是呈现周期性但非整块分组的模式。
用 $upstream_addr 和 access_log 验证真实分配序列
仅看总请求数会掩盖波动性。应记录每次请求落到哪个后端：
- 在 log_format 中加入
$upstream_addr（含 IP:port 和可能的重试跳转） - 示例日志配置：
log_format upstream_detail '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$upstream_addr $upstream_response_time'; - 压测时收集 200+ 请求日志，用
awk '{print $12}' | sort | uniq -c统计频次，再人工查看前 20 行序列，观察是否符合加权轮询的“累积-选取-衰减”节奏
检查 effective_weight 是否被意外干预
权重“失效”常因健康检查或错误自动降权导致：
- 启用
health_check或配置了max_fails/fail_timeout时，某节点若偶发超时，effective_weight 会被临时置为 0，current_weight 停止增长，造成连续多轮跳过该节点 - 用
curl http://localhost/status（需启用 stub_status）或 OpenResty 的ngx.var.upstream_next（需 Lua）可查当前 effective_weight，但更直接的是：临时关闭健康检查，用proxy_next_upstream off，再压测对比分布变化 - 确认没有配置
down或backup属性干扰主权重队列
避免常见误解与验证建议
- 不要只看短时间小样本：10 次请求里 A:B=7:3 不代表权重错，需数百次以上看趋势；理想分布 ≈ weight_i / sum(weight)
- 权重必须为整数：Nginx 不支持小数权重（如 1.5），配置会被截断为 1，导致预期偏差
- 重启 Nginx 不重置 current_weight 状态：它随 worker 进程生命周期存在；若要彻底重置，需 reload + 逐个 kill worker（不推荐），或依赖自然衰减（无失败时几轮后恢复）
- 调试时可开启
error_log ... debug;，搜索"select a peer"日志行，看到每步的 current_weight 计算过程（日志量大，仅限定位）
