加权轮询分发准确度需通过后端日志验证，而非仅依赖配置；应在nginx中透传x-upstream头标识后端机器，并统计各节点请求占比，偏差超±5%需排查健康检查、keepalive、权重梯度或响应延迟等问题。
加权轮询的分发准确度不能只靠配置“看着对”，必须结合后端日志验证是否真按权重比例落地。重点不是算理论值，而是看请求实际落到哪台机器、频次是否匹配预期权重比。
从日志里提取关键字段做统计
每台后端服务器的日志中，需确保记录能唯一标识请求来源和本机身份。推荐在 Nginx 的 proxy_set_header 中透传标识：
- X-Forwarded-For 或 X-Real-IP：用于识别客户端真实 IP（可选，主要用于排查）
- X-Upstream 自定义头：server_name 或 hostname，让后端写入日志时带上本机标识
- 例如在 Nginx 配置中加：proxy_set_header X-Upstream $hostname;
后端服务收到请求后，把 X-Upstream 值写进访问日志，比如：[2026-10-03T00:10:22] 192.168.1.101 "GET /api/user" 200 - X-Upstream: web01
用简单命令快速验证权重分布
假设三台后端日志路径统一为 /var/log/app/access.log，可分别执行：
- grep "X-Upstream: web01" /var/log/app/access.log | wc -l → 得到 web01 接收请求数
- grep "X-Upstream: web02" /var/log/app/access.log | wc -l → web02 数量
- grep "X-Upstream: web03" /var/log/app/access.log | wc -l → web03 数量
若配置为 weight=3、weight=2、weight=1，总权重为 6，则理想占比应是 50% : 33.3% : 16.7%。抽样 600 条请求，期望值约为 300 / 200 / 100 —— 实际偏差超过 ±5% 就值得查原因。
常见偏差原因与排查点
- 健康检查干扰：某台机器因 max_fails 触发临时下线，日志突然变少。检查 /var/log/nginx/error.log 是否有 upstream server temporarily disabled 记录
- 连接复用未关闭：HTTP/1.1 keepalive 导致单个客户端长连接反复打到同一台，掩盖了轮询逻辑。可在 upstream 中加 keepalive 32; 并配 proxy_http_version 1.1; + proxy_set_header Connection ''; 确保复用不干扰分发
- 权重设置过极端：比如 weight=100 和 weight=1，小权重节点可能长时间无流量，日志为空。建议权重比控制在 1:2:3 或 2:3:4 这类平滑梯度
- 后端响应时间差异大：加权轮询不感知响应快慢。若某台延迟高、处理慢，它会积压连接，后续请求仍被轮到，但日志里看起来“分得少”——其实是卡住了。此时要配合 least_conn 或监控响应 P95
自动化校验的小技巧
写一个简短脚本，定时汇总各节点请求数并计算偏离度：
#!/bin/bash total=$(grep -c "X-Upstream:" /var/log/app/access.log) w1=$(grep -c "X-Upstream: web01" /var/log/app/access.log) w2=$(grep -c "X-Upstream: web02" /var/log/app/access.log) w3=$(grep -c "X-Upstream: web03" /var/log/app/access.log) echo "web01: $(echo "scale=1; $w1*100/$total" | bc)%" echo "web02: $(echo "scale=1; $w2*100/$total" | bc)%" echo "web03: $(echo "scale=1; $w3*100/$total" | bc)%"
跑完就能一眼看出是否贴近 50/33/17。搭配 cron 每 5 分钟执行一次，比人工翻日志更可靠。
