买 VPS（Virtual Private Server，虚拟专用服务器）的时候，商家页面上写的 100Mbps、300Mbps 大带宽（带宽指服务器与外界之间的数据传输能力，通常以 Mbps 计量），到底有多少能真正跑出来？很多站长等到业务上线才发现晚高峰掉速、跨机房传输只有标称值的一半，却又说不清问题出在哪。这篇文章教你如何用 iperf3 这款开源测试工具，把 VPS 的真实网络吞吐变成可复现的实测数据：从单线程基础测试到跨机房多线程压测，每一步都给出具体命令和结果解读方法，帮助你用数据而不是商家宣传页来判断一台机器的网络质量。
iperf3 是什么，为什么选它
iperf3 是一个专门测量网络吞吐的命令行工具：一端启动服务端，另一端启动客户端，让两者之间持续打满数据流，统计单位时间内成功传输的数据量。它测的是”管道有多粗”，即链路的裸吞吐上限，与业务无关，最适合验证服务商承诺的带宽数值。
相比 ping 只能看延迟、speedtest 只能测到固定节点的速度，iperf3 有三个适合站长使用的特点：支持 TCP 和 UDP 双模式，前者看实际上限，后者能暴露丢包率；支持多并行连接，能填满长距离链路；部署成本几乎为零，一条 apt install iperf3 就能装好。
需要说明的是，iperf3 测的是两点之间的吞吐，它不能替代对网站访问速度的完整评估——后者还涉及页面体积、缓存和CDN（Content Delivery Network，内容分发网络）分流静态资源等因素。但在”这台 VPS 的带宽到底虚不虚”这个问题上，它是最直接的证据。
测试前的准备：两端环境与注意事项
iperf3 需要两端都有机器：一端是你的 VPS，另一端叫对端。对端选择直接决定数据怎么解读：同机房或同城的对端测出的是内网/同城链路，数值最接近标称带宽；服务商提供的公共 iperf3 节点方便，但走的是商家预设路径；拿自己另一台不同机房的 VPS 做对端，测出的才是真实跨机房链路，这也是本文的重点。
环境上有四个细节要提前处理，否则数据会失真：测试至少持续 30 秒以上（建议 -t 60 跑一分钟，每组参数跑三次取平均）；按流量计费的机器要控制次数，满速测试 60 秒大约消耗 700MB 到 1GB 流量；国际链路晚高峰（北京时间 20:00 到 23:00）普遍拥塞，同一组参数建议白天和晚高峰各测一轮；关闭两端机器上的备份同步、爬虫等大流量任务，避免抢带宽。
还有一个容易被忽略的点：部分服务商的防火墙默认只开放 22、80、443 等常用端口，iperf3 默认使用 5201 端口，测试前需要在对端放行，命令是 firewall-cmd --add-port=5201/tcp（CentOS）或 ufw allow 5201（Ubuntu），否则客户端会一直连接失败。
第一步：单线程测试，摸清链路基础值
先在最简单的场景下跑一轮。假设你手里有两台不同机房的 VPS，A 机（比如香港）做服务端，B 机（比如美国）做客户端，两台都装好 iperf3 后，A 机执行：
iperf3 -sB 机执行：
iperf3 -c A机的IP -t 60跑完后重点看输出末尾的两行汇总：sender 是 B 机发出的平均速率，receiver 是 A 机实际收到的速率。两端数值理论上应该接近，如果 sender 很高但 receiver 明显偏低，说明链路中间丢包或限速严重。假设 B 机套餐标称 500Mbps，实测 receiver 稳定在 85 到 95Mbps，这个结果先别急着骂商家，因为单线程 TCP 在跨洋链路上几乎必然跑不满，原因下面解释。
第二步：多线程并行，逼出链路上限
TCP 协议用”滑动窗口”控制传输节奏，发送方每发一批数据都要等接收方确认，链路越长（延迟越高），等待确认的时间占比越大，单条连接能跑满的速率就越低，这是带宽时延积限制，物理规律而非商家问题。跨太平洋链路延迟普遍在 150 到 200ms，单线程能跑到 100Mbps 已属正常，此时必须用并行连接填满管道。
在客户端命令后加 -P 参数：
iperf3 -c A机的IP -t 60 -P 8-P 8 表示同时开 8 条并行连接。实测经验是：同城或同机房链路 -P 4 基本就能跑到标称值；跨机房链路建议从 -P 8 开始试，如果总吞吐还在爬升，就加到 -P 16；当增加线程数后总吞吐不再明显增长时，就是这条链路的实际上限了。举个例子，同一对机器，-P 1 实测 92Mbps，-P 8 实测 380Mbps，-P 16 实测 415Mbps 且继续加线程无增长，那 400Mbps 左右就是这条跨机房链路的真实可用吞吐，对照 B 机的 500Mbps 套餐，属于正常损耗范围。
这一步还有个进阶参数值得记：-R 反向测试。默认是客户端推数据到服务端，加 -R 反过来拉。很多跨境链路上下行不对称，去程 400Mbps、回程 200Mbps 并不少见，两个方向都要测。
第三步：UDP 模式，暴露丢包和抖动
TCP 模式的高吞吐有一个隐藏前提：丢包由 TCP 自动重传兜底，数字好看但实际体验可能很差。UDP 模式不重传，能直接暴露丢包率：
iperf3 -c A机的IP -t 60 -u -b 200M-u 指定 UDP 模式，-b 200M 表示以 200Mbps 的目标速率发包。跑完后服务端会输出丢包率（Lost/Total）和抖动值（jitter）。判断标准：同城链路丢包率应接近 0；跨境链路晚高峰丢包率低于 1% 属于优秀，1% 到 3% 已能被用户感知（网页变慢、视频卡顿），超过 5% 基本可判定线路不合格。普通建站业务对 30ms 以内抖动不敏感，语音、实时通讯类业务建议控制在 10ms 以内。
结果解读：什么算正常，什么算翻车
把前面的实测方法汇总成判断口径：多线程实测吞吐达到标称值 85% 以上且时段波动不超过 20%，属于正常水平；实测值在 50% 到 85% 之间，先排除对端瓶颈再找商家核查；实测值不足标称值一半且 UDP 丢包率同时偏高，基本可以判定线路超售或路由质量差，提交工单时附上完整测试数据，比一句”你们太慢了”有效得多。
实测值远低于预期时，按三个方向排查：先用 ethtool eth0 | grep Speed 确认网卡协商速率，虚拟化环境偶尔会协商在 100Mbps 低速状态；再用 tc qdisc show 检查是否配置了令牌桶限速规则，一些便宜套餐靠它实现”大带宽”；最后检查 net.core.rmem_max 等内核缓冲参数，跨机房高延迟链路建议适当调大。三个方向都排除后仍跑不满，问题大概率在运营商路由上，可以参考站内这篇 BGP 线路在国内的真实表现分析 理解高峰期拥塞的机理。
把测试沉淀成选机房的依据
单次测试只是快照，更重要的是沉淀数据：给每台在用或准备采购的 VPS 记录白天多线程吞吐、晚高峰多线程吞吐、晚高峰 UDP 丢包率三个数字，换机房之前先跑一轮与旧机器对比。评估跨境业务时，吞吐之外还要看延迟与丢包的组合表现，站内 香港云主机延迟实测分析 和 美国服务器跨境访问实测 提供了不同区域的基准数据，可与你的测试结果对照。
如果你正处在选型阶段，建议把 iperf3 实测纳入验收流程：新机器开通后第一时间跑一轮多线程 TCP 加一轮 UDP，数据不达标的机器在退款期内直接处理。正在挑选 VPS 的朋友，可以先浏览 VPS 主机 频道了解不同机房的口碑差异，再结合本文方法逐一验证商家承诺的带宽；比如 Hostease 的 VPS 方案在控制面板里直接标注了端口速率，实测前先记下标称值，测完对比就知道虚不虚。
总结一下完整路径：单线程测基础值，多线程逼出上限，UDP 暴露丢包，不同时段各测一轮并以较低值作为规划基准。这套流程跑完一台机器不超过二十分钟，却能避开”标称大带宽、实际跑一半”的绝大多数坑。如果你需要，现在就可以找一台测试机把这三条命令跑一遍。
