必须逐节点独立压测而非Nginx层整体压测，因加权轮询是请求级调度，需绕过Nginx直连后端测出真实承载力，再按最大稳定QPS比设定weight，并通过$request_number分布、$upstream_response_time分位值及error.log异常验证权重有效性。
直接对每个后端节点单独压测，而不是在Nginx层整体打流量——这是验证权重配置是否合理的关键前提。
为什么不能在Nginx上游统一压测
因为加权轮询是请求级调度，Nginx本身不缓冲、不聚合请求。如果从客户端对Nginx发起1000 QPS压测，你看到的是“最终分发结果”，但无法区分：某节点QPS偏低，到底是它真实扛不住，还是Nginx还没轮到它？更难定位是权重设高了，还是该节点响应变慢导致Nginx健康检查把它临时摘除了。
正确测试步骤：逐节点独立压测
用 wrk 或 ab 直连单个后端服务（绕过Nginx），模拟真实业务请求：
- 固定并发数（如 -c 100），逐步增加请求数（-n）或持续压测（-t 60s），观察QPS稳定值
- 重点关注两个拐点：CPU利用率突破75%，以及P95响应时间开始明显上升（比如跳涨30%以上）
- 记录该节点在不触发上述瓶颈前提下的最大稳定QPS（例如：A节点 1200 QPS，B节点 400 QPS）
- 按比例换算权重：1200:400 = 3:1 → 可设 weight=3 和 weight=1（或 6 和 2，比值一致即可）
上线后验证权重是否生效
配好 upstream 后，别只看日志“有没有转发”，要盯三项指标：
- $request_number 分布：长期统计各 server 的请求计数，看是否接近设定权重比（如 3:1 的节点，实际请求数偏差超15%，就要查是否连接未复用、健康检查误剔除等）
- $upstream_response_time 分位值：高权重节点的 P95 延迟不应显著高于低权重节点；若出现“权重高但延迟更高”，说明它已成瓶颈，权重可能设高了
- error.log 中的异常：“upstream timed out” 频发，或 “no live upstreams”，往往意味着某节点持续过载，权重需下调，或后端存在慢SQL、GC风暴等隐藏问题
配套必须打开的配置项
否则压测出的QPS和线上表现会严重脱节：
- upstream 块中加 keepalive 32（数值建议为后端连接池容量 × 0.6～0.8）
- 对应 location 中设置 proxy_http_version 1.1 和 proxy_set_header Connection ''
- 确认后端返回头含 Connection: keep-alive，且其 keep-alive timeout > Nginx 的 keepalive_timeout
- 每个 server 行加上 max_fails=2 fail_timeout=30s，再加 slow_start=10s 防雪崩
