验证Nginx加权轮询灰度流量的关键是确认请求是否真实稳定按权重比例落至后端，而非仅配置生效；需通过响应头标识（如X-Backend-Version）、批量curl统计、access.log中upstream_addr字段分析，并排除健康检查失效、keepalive连接复用等干扰因素。
验证 Nginx 加权轮询在灰度发布中的权重分配，关键不是看配置写了多少，而是确认请求是否真实、稳定地按设定比例落到对应后端。配置 reload 成功只是第一步，偏差常出现在连接复用、健康状态或采样不足等环节。
响应头打标 + 批量 curl 统计
让新旧服务在 HTTP 响应头中返回明确标识，比如 X-Backend-Version: v1 或 X-Backend-Version: v2。然后用脚本快速发起大量请求并统计分布：
- 执行 curl -sI http://your-domain.com | grep "X-Backend-Version" 1000 次，用 awk 提取版本并计数
- 若设的是 weight=20（v1）和 weight=1（v2），理论比应为 ≈95.2% : 4.8%，实测允许 ±5% 偏差
- 注意避开浏览器缓存或代理干扰，建议用 curl -H "Cache-Control: no-cache"
分析 access.log 中 upstream_addr 字段
Nginx 默认日志里的 upstream_addr 字段记录了实际转发的目标地址和端口，是最直接的流量落点证据：
- 确保 log_format 包含 $upstream_addr，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_addr';
- 采集至少 1000 条访问日志后，用命令快速统计：awk '{print $12}' access.log | sort | uniq -c | sort -nr
- 结果应接近权重比，如 v1:192.168.1.10:8080 出现 950 次，v2:192.168.1.11:8080 出现 50 次
检查健康检查是否干扰权重生效
即使 weight 配得再准，如果某台后端因健康检查被标记为 down，它就完全不参与调度——此时实际流量会全部压到另一台，导致“零流量”假象：
- 查 error.log 是否有 unhealthy 或 max_fails 相关报错
- 临时调松探测参数验证，例如：max_fails=1 fail_timeout=10s，观察 v2 是否开始收请求
- 用 nginx -T | grep -A5 "upstream" 确认当前生效的 upstream 配置含 health check 参数
留意 keepalive 和长连接带来的偏差
客户端复用 TCP 连接时，Nginx 的加权轮询是按连接粒度而非请求粒度调度的。一个长期存活的连接可能始终打到同一台后端，尤其在低并发、高 keepalive_time 场景下：
- 若实测 v2 流量长期为 0，先检查客户端是否复用连接（如浏览器、Postman 默认开启 keepalive）
- 测试时改用短连接：curl 加 --no-keepalive，或 ab 工具加 -k 关闭
- 生产环境可适当降低 keepalive_timeout（如设为 15s），减少单连接滞留影响
