VPN 速度怎么测:工具、时段与指标的自测方法

VPN 速度怎么测,决定结论的不是测速站点的界面,而是你测的是哪一段链路、在什么时段测、连测了几次。同一台设备、同一条订阅,换一个测速节点、换一个小时,结果可以差出好几倍——这不是线路在骗人,而是两次测量回答的根本不是同一个问题。下面把测量拆成三层、四个指标和一套可以重复执行的流程,让不同线路之间的对比真正有意义。

先把口径定下来:四个指标各管什么

日常说的"网速慢"至少对应四种不同的量。延迟、抖动、丢包属于链路质量,吞吐属于传输结果。四个指标里任何一个变差,体感都可能表现为"卡",但处理方式完全不同:丢包要换线路,抖动要避开高峰,吞吐上不去可能只是单线程的问题,跟线路好坏无关。

带宽和吞吐不是一回事。带宽是链路标称的上限,吞吐是你在终端上真实拿到的量,中间隔着协议开销、服务端限速、单连接的窗口限制,以及同线路其他用户的占用。所以看到 Mbps 这个单位时,先确认它说的是带宽还是吞吐,再决定要不要把它当成比较依据。

工具:分三层测,别用一个网页跑分定论

把测量分成三层,每层用一个合适的工具,结论才立得住。层级混着用,数字就会互相打架。

网页测速站点大多跑多线程 HTTP,适合看这条线路的上限。它默认挑离你近的节点,给出的数字回答的是"到最近测速服务器有多快",而不是"到你要用的那个服务有多快"。这两个数字可以同时成立,一个很高一个很低,谁都没错。

iperf3 适合点对点验证,可以指定并发连接数和测试时长,排除浏览器与测速站点的干扰,代价是两端都得有可控的节点。日常自测更实际的做法是:多线程测速站点看上限,单线程下载看下限,两个数字都记下来。

时段与次数:让两次测量具备可比性

单次测量只是一个样本。国际线路的负载有明显的时间规律,晚高峰和凌晨的差距,往往比两条线路之间的差距更大。所以跨时段比较要看趋势,同一时段内的横向比较才有排序意义。

• 高峰与低谷各测一轮,分别记录两个时段的中位数。
• 同一条线路连测三次,取中位数,不取最大值。
• 每次记录:日期、线路名、协议、客户端版本、单线程还是多线程。
• 换线时只改一个变量,设备、客户端、测速节点都保持不变。
• 测之前先更新订阅,确认节点列表没有变化。

指标怎么读:从数字到结论

拿到一组数字后,按固定顺序读,比凭感觉判断可靠得多。

1. 先看丢包。持续不为零的丢包,优先换线路,不要在客户端参数上折腾,调 MTU 也救不回来。
2. 再看抖动。抖动接近延迟本身,说明链路在排队,通常是中转段拥塞或共享带宽被占满。
3. 然后看吞吐。延迟正常、抖动也小,但吞吐上不去,多半是单线程受限、服务端限速或协议开销。
4. 最后看体感。首字节时间、视频起播、游戏内的操作反馈,是前三项的综合结果,也是唯一值得长期跟踪的指标。

高延迟链路还有一个容易被忽略的机制:单条 TCP 连接的吞吐受带宽时延积限制。延迟越高,单连接越难跑满高带宽,需要多条并发连接才能吃满。所以"多线程能跑满、单线程跑不满"是正常现象,不一定是线路出了问题。

协议与线路类型会改变结果

协议差异主要在两处

一是传输层选择。Shadowsocks、VMess、VLESS、Trojan 主体走 TCP,同时可以转发 UDP;Hysteria2、TUIC 基于 QUIC,走 UDP。在丢包明显的链路上,QUIC 系的拥塞控制更激进,恢复更快;但如果网络对 UDP 有限速或阻断,它们的表现会反过来变差,这一点在自测里很容易被误判成"协议不行"。

二是握手与开销。VMess 带时间戳校验,设备时间偏差过大会直接握手失败;VLESS 本身无状态,配合 XTLS 可以减少一次 TLS 加解密,高带宽时 CPU 占用更低;Trojan 依赖标准 TLS,流量形态更接近普通 HTTPS。这些差异在低带宽下几乎测不出来,只有在长肥管道上才会体现。

线路类型:直连、中转、IEPL 专线

• 直连。终端直接连出口,延迟取决于国际出口的拥塞程度,晚高峰波动最大。
• 中转。先接入中转节点再转发到出口,中转段的带宽是否独享,直接决定高峰期的表现。
• IEPL 专线。点到点的专线链路,不走公网国际出口,延迟和丢包最稳,成本也最高。

所以同一个"地区"的节点,线路类型不同,测出来的曲线可以完全不同。比较时把线路类型写进记录里,否则数据没法复用,下周还得从头再测一遍。

按地区切换线路时,可以对照的事实:覆盖 100+ 国家、250+ 线路;订阅不限同时在线设备数,换设备复测不需要重新配置;30 天无理由退款,测完觉得不合适可以直接退。

排除误判:几个常见干扰项

测速结果失真,大多不是线路的问题,而是下面这几件事没做干净。

• ✅ 测前更新订阅,确认测的是同一条线路;节点改名或换 IP 之后,之前的结论直接作废。
• ❌ 开着分流规则直接测。部分流量走直连,结果里混进了两条路径的表现,谁好谁坏分不清。
• ✅ 检查域名解析路径:解析走本地运营商时,可能拿到就近的 CDN 节点,数字好看但不代表出口质量。
• ❌ 用一次视频播放判断吞吐。命中缓存之后,播放流畅和链路能力没有关系。
• ✅ 在同一个客户端里横向比较。不同客户端默认 MTU、UDP 转发开关和分流策略不同,跨客户端比数字没有意义。
• ❌ 把"加速比""降低多少百分比"当成指标。换算过的数字没有基线,也无法复现。

一套可复现的自测流程

下面这套流程按顺序执行,结果可以横向比较,也可以隔一周复测一次看稳定性。

1. 固定变量。同一台设备、同一个客户端、同一个测速节点,先定下来再开始。
2. 更新订阅。记下线路名与协议,后面所有记录都以这一行为准。
3. 测链路层。连续 20 个包看延迟与丢包,再看逐跳路径,定位问题出在哪一段。
4. 测吞吐层。多线程测速一次,单线程下载一次,两个数字分别记录。
5. 测应用层。打开你实际要用的那个服务,记首字节时间和有没有缓冲。
6. 换下一条线路,重复第 3 到第 5 步,变量保持不动。
7. 汇总成一行记录,再决定留哪条线路、什么时段用哪条。

命令行只需要两条就够,Windows 下把 ping 换成 ping -n 20、mtr 换成 pathping 即可。这里用公共解析服务当参考点,它的节点通常就近,延迟低;要判断真实目标的链路,把地址换成你实际访问的域名,同一组对比里目标必须一致。

# 延迟与丢包:连发 20 个包,看平均延迟和丢包率
ping -c 20 1.1.1.1

# 逐跳路径:每跳 50 个包,定位丢包发生在哪一段
mtr -rwc 50 1.1.1.1

常见问题