在构建高可用服务时，我们经常需要让Nginx把请求按比例分发给多个后端。Nginx的upstream模块通过weight参数支持加权轮询，但很多工程师配置完后并不确定流量是否真的按照预期比例分配。weighttp是一款用C语言编写的高性能HTTP压测工具，体积小、并发控制简单，非常适合在本地或测试环境做精确的权重验证。借助它发起大量请求，再统计各后端收到的连接数，就能用数据证明权重配置的正确性。
搭建带权重的Nginx反向代理环境
要验证权重，第一步是准备一个清晰的Nginx配置。我们在upstream块中定义两个后端服务，分别赋予不同的weight值。Nginx默认使用加权轮询算法，某个server的weight越大，它被分配到的连接数在理想状态下就越多。需要注意的是，weight并不表示优先级，而是在多轮调度中出现的频率比例。
下面是一段最小可运行的配置示例，将请求转发到本机两个端口，权重设为7和3，意味着长期来看大约百分之七十的流量会到8001，百分之三十到8002。
upstream backend_pool {
server 127.0.0.1:8001 weight=7;
server 127.0.0.1:8002 weight=3;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
}
}
为了让测试可观测，两个后端可以用简单的Python服务返回带端口标识的内容，这样从访问日志或响应体就能区分请求落在了哪台机器。测试期间建议关闭keepalive超时带来的复用干扰，或者在weighttp中使用短连接模式，确保每次请求都经过调度器重新选节点。
使用weighttp发起可控压测流量
weighttp的命令参数直观：-n指定总请求数，-c指定并发数，-t指定线程数。为了验证权重，我们通常发起一个较大的总请求数，例如一万次，并用较低并发避免系统瓶颈掩盖调度逻辑。这样得到的比例更稳定，也更容易和配置中的七比三对照。
执行命令如下，将流量打向Nginx监听的地址。由于weighttp本身不解析HTML，它只记录成功响应数，非常适合做纯分发验证。
# 安装后执行，总请求10000，并发50 weighttp -n 10000 -c 50 http://127.0.0.1/
压测完成后，不要只看weighttp的汇总吞吐，而要去两个后端的日志里分别统计接收的请求行数。可以用grep配合wc命令快速计数。如果8001收到约7000条、8002收到约3000条，说明weight配置生效。若比例偏差过大，应检查是否有其他upstream参数如max_fails或backup影响了调度，或者是否因为某后端响应极慢导致加权轮询动态降级。
权重测试中的常见误区与精准统计法
一个广泛存在的误解是：weight会按照响应时间或处理能力分配流量。实际上Nginx的加权轮询只基于连接调度次数，和后端快慢无关。如果8001处理慢、8002处理快，在并发较高时，慢节点会堆积连接，但Nginx仍按权重发新连接过去，这可能让慢节点更慢。因此在权重测试中应保持两个后端性能接近，才能纯粹验证调度比例。
另一个误区是依赖Nginx自带的status页面估算比例。默认stub_status只显示总连接和请求数，不区分upstream节点。要精确，必须在后端服务写日志，或在Nginx的access_log中通过upstream_addr变量记录实际转发地址。下面给出日志格式配置片段，把被调度的后端地址写进日志，方便后续分析。
log_format weight_test '$upstream_addr $request_time $status';
server {
listen 80;
access_log /var/log/nginx/weight_test.log weight_test;
location / {
proxy_pass http://backend_pool;
}
}
统计时可用awk提取第一列并计数：
awk '{print $1}' /var/log/nginx/weight_test.log | sort | uniq -c
该命令会输出每个upstream地址的出现次数。通过对比weight设定的比例，能形成闭环验证。如果做多轮测试，建议每轮重启后端清空日志，避免历史数据干扰。利用weighttp配合这种日志统计，开发者可以用极低资源成本，在每次调整Nginx权重后获得可信的量化反馈，而不是凭经验猜测负载分布。
Nginxweighttpload_balancing修改时间：2026-08-18 04:36:13