全球云服务器iPerf3带宽排行榜怎么测？哪家厂商不缩水？

云服务器的标称带宽和实际能跑到的吞吐经常是两回事。以 1Gbps 规格为例，有些厂商能稳定跑满 950Mbps 以上，有些跨地域或晚高峰只有 300Mbps 左右。用 iPerf3 做压测可以得到相对客观的数据，但前提是排除本机 CPU、磁盘和测试端带宽的干扰。否则测出来的数值可能不是真实网络带宽，而是被单核性能卡住。

本文基于公开测试数据和自建环境，整理全球主流云厂商的 iPerf3 带宽表现，并说明测试参数和榜单局限性。读者可以根据自身业务所在区域选择合适的云服务器，避免被标称带宽误导。

一、为什么标称带宽不等于实际吞吐

云厂商给云服务器标注的带宽一般分为独享、共享和突发三种。独享带宽通常表示该实例独享物理端口速率，但公网出口仍然经过运营商级 NAT 和 BGP 选路，实际可用吞吐会受到拥塞控制、丢包和线路抖动影响。共享带宽则更不稳定，同一台宿主机上其他租户的流量高峰会直接拉低你的可用带宽。

另外，不少厂商把网络性能与 vCPU 数量挂钩。例如 1 核 1G 实例标称能跑到 1Gbps，但在实际测试中，单核处理数据包转发的 CPU 占用很容易达到 100%，导致吞吐只能到 300Mbps 左右。升级到 4 核以上后，同样的网络环境往往能接近标称值。这说明测试云服务器带宽时，一定要先确认实例规格是否满足网卡队列和 CPU 处理能力。

跨境链路的问题更突出。从中国大陆到海外节点的测试经常出现去程走 CN2、回程走普通线路的“路由绕路”情况，iPerf3 的单线程成绩会非常难看，而多线程可以部分绕过单流限制。因此排行榜数据必须注明测试地域和方向，否则没有可比性。

二、iPerf3 测试方法与关键参数

iPerf3 是命令行网络性能测试工具，支持 TCP、UDP 和 SCTP 协议。服务端只需要监听端口，客户端发起连接并发送数据。典型测试流程如下：在目标云服务器上运行服务端，本地机器作为客户端，或者反过来测试上行方向。建议两个方向都测，因为很多云厂商上行和下行带宽不是对称的。

# 服务端监听 5201 端口
iperf3 -s

# 客户端发起 4 个并发线程，持续 30 秒，每秒输出报告
iperf3 -c 服务器公网IP -P 4 -t 30 -i 1

# Windows 客户端示例，注意路径反斜杠
C:\iPerf3\iperf3.exe -c 服务器公网IP -P 4 -t 20

-P 参数控制并发线程数，-w 控制 TCP 窗口大小，-R 表示反向测试。如果怀疑 CPU 瓶颈，可以先用 top 或 Windows 任务管理器观察客户端和服务端的 CPU 使用率。若单核接近 100%，需要提高线程数或更换更高规格实例。UDP 测试使用 -u -b 1000M 可以指定发送速率，适合排查丢包率。

测试时要保证两端带宽都高于被测目标。例如测 1Gbps 云服务器，本地最好有 1Gbps 以上带宽，否则测试结果被本地运营商限速。另一个常见误区是使用公网 IP 直接测速，但云厂商的限速可能只针对出方向，入方向一般不限速，所以上行和下行要分开记录。

三、全球主流云服务器 iPerf3 带宽排行榜解读

下面的表格汇总了多个公开测试和自建实验中，同地域公网、TCP 多线程条件下，主流云厂商部分实例的实测带宽中位数。单位统一为 Mbps，测试时长 60 秒，客户端和服务端均采用 4 核以上实例。

从数据看，小规格实例的带宽缩水普遍存在。阿里云 t6 和 Azure B2s 因为共享出方向带宽且 CPU 配额有限，实际吞吐明显低于标称。AWS 的 t3 系列虽然标称最高 5Gbps，但突发性能需要消耗 CPU 积分，积分耗尽后网络吞吐会大幅下降。Google Cloud 和 Vultr 的表现相对扎实，尤其 Google Cloud 的入方向带宽几乎不限制，适合数据备份和日志收集场景。

对于国内用户，跨地域到海外节点的测试结果差异更大。例如从上海到东京的 iPerf3 单线程成绩可能只有 50Mbps，但同一时刻使用 8 线程可以跑到 400Mbps。这说明国际线路的拥塞窗口限制比本地限速更严重。选择出海业务云服务器时，不能只看官网标注的 1Gbps，还要实际测试目标线路的稳定性和晚高峰表现。

四、影响 iPerf3 成绩的非带宽因素

首次接触 iPerf3 的人容易把吞吐低归咎于云厂商限速，其实很多成绩差是测试环境自己造成的。最常见的是 CPU 单核瓶颈。iPerf3 每个线程默认使用一个 CPU 核心处理数据包，如果实例的 vCPU 是共享调度，那么其他租户的负载会让可用 CPU 时间片减少，进而拖慢网络吞吐。解决办法是用 -P 8 提高并发，并在客户端和服务端同时观察 mpstat -P ALL 1 的输出。

内核网络参数也会影响结果。Linux 默认的 TCP 接收缓冲区可能只有 128KB，在高带宽高延迟线路（BDP 很大）下会限制单线程吞吐。可以临时调大缓冲区再测试：

# 调整 TCP 缓冲区和窗口扩展参数
sudo sysctl -w net.core.rmem_max=134217728
sudo sysctl -w net.core.wmem_max=134217728
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

另外 MTU 和网卡多队列配置也值得检查。如果虚拟网卡的队列数小于 vCPU 数，数据包处理只能集中在少量核上，性能无法线性扩展。部分云厂商允许在实例创建时选择增强型网络，例如 AWS 的 ENA 和阿里云的弹性网卡多队列，开启后往往能把 1Gbps 规格跑到接近满载。

还有一个容易被忽略的因素是测试工具的版本。旧版 iPerf3 对多线程和窗口管理不够完善，在 Windows 上还可能出现 2Gbps 以上的性能天花板。建议使用 3.10 以上版本，并在服务端使用 -A 参数绑定 CPU 核，避免进程被内核随意迁移。

五、根据业务场景选择云服务器带宽

如果你的业务是视频点播或大文件分发，需要的是持续高下行带宽，那么优先选入方向不限速的厂商，比如 Google Cloud 和 AWS 的部分实例。但要注意流量费用，这些厂商通常按 GB 计费，大流量成本可能远高于包月带宽。相比之下，国内云厂商的按量带宽包月封顶方式对预算更友好。

对于 Web API 和数据库同步这类小包密集场景，带宽数值反而不是最关键，连接数和包转发率更重要。此时 iPerf3 的多线程大包测试可能无法反映真实体验，建议配合 wrk 或 sysbench 做应用层压测。云服务器的网络质量还要关注 PPS（每秒包转发数）指标，部分厂商对小规格实例的 PPS 限制很严格，即使带宽没跑满，小包请求也会排队。

出海业务建议先购买按量计费实例，在目标地域用 iPerf3 测试到国内多个运营商线路的吞吐和延迟。晚高峰与凌晨各测一次，记录丢包率。如果发现去程和回程路径不一致，可以使用 MTR 工具定位运营商互联节点。整体来看，没有哪家厂商在所有场景都领先，阿里云和腾讯云在国内 BGP 多线有优势，Vultr 和 DigitalOcean 在海外性价比高，AWS 和 Google Cloud 则在全球节点和网络基础设施上更完善。先测后买，才能避免带宽参数虚标带来的业务风险。

iPerf3云服务器带宽带宽排行榜修改时间：2026-09-28 11:12:21