配置 weight 后需通过可观测数据验证实际流量分发比例：查看 stub_status 中 upstream 的 requests 增长比，或解析 access_log 中 $upstream_addr 统计占比，结合 curl 脚本快速验证，注意排除 ip_hash、sticky session、后端异常及请求量不足等干扰因素。
配置完 weight 后，不能只看 reload 成功就认为生效了。实际流量是否按设定比例分发，得靠可观测数据来验证。
查 Nginx 内置状态页（stub_status）
前提是已编译启用 stub_status 模块，并在 server 块中开放访问路径（如 /nginx_status）：
- 访问该地址，能看到类似
Active connections: 123和server accepts handled requests的汇总数据 - 更关键的是
Reading:、Writing:、Waiting:下方的Requests列——它统计的是每个 upstream server 被选中的总次数 - 持续观察 5–10 分钟，对比各 server 的
requests增长比，应接近你设的 weight 比（例如 weight=4:1:2 → 请求计数比 ≈ 4:1:2）
解析 access_log 中真实转发目标
在 Nginx 的 log_format 中加入 $upstream_addr 变量，它会记录每次请求最终转发到的后端地址和端口：
- 示例日志格式：
log_format main '$remote_addr - $upstream_addr [$time_local] "$request" $status $upstream_response_time'; - 用
awk或脚本统计日志中各 IP 出现频次，比如：awk '{print $3}' access.log | sort | uniq -c | sort -nr - 统计几百到上千条请求后，各后端 IP 占比应与 weight 比基本一致（允许 ±10% 偏差）
注意干扰因素，避免误判
即使配置正确，也可能因其他机制导致比例失真：
- ip_hash 开启时 weight 不生效：请求固定绑定 IP，weight 只在节点失效时起替补作用
- sticky session 或 cookie 路由：用户被长期打到某台机器，短期统计看不出权重效果
- 后端主动断连或超时：触发健康检查下线，剩余节点自动重归一化，此时看到的比例是“动态调整后”的，不是原始 weight 比
- 请求量太少：几十次请求很难体现比例，建议压测发起 500+ 并发请求再统计
用简单脚本做快速验证
不需要复杂工具，一个循环 curl 就能初步判断：
- 执行：
for i in {1..200}; do curl -s http://your-domain.com/test | grep "server-id" >> result.txt; done - 假设后端返回里带标识（如
Server: node-a），再用sort result.txt | uniq -c统计分布 - 若 weight 是 3:1:2，200 次请求里三台服务器出现次数应在 100、33、67 左右浮动
