VPN测速怎么测才准?2026 加速器速度实测方法与工具推荐
宣传页上的速度数字不能直接当参考。本文给出自己动手测速的完整方法:选什么工具、在哪些时段测、看哪几个指标,以及如何识别被美化的测速截图。
为什么宣传页上的测速数字不能直接用
VPN测速怎么测才准,先给结论:一次测速的结果,是「本地宽带 → 国内出口 → 跨境线路 → 海外机房 → 测速服务器」这条链路上最慢那一段的表现。宣传页上的数字通常只说明某一天、某一条线路、某一个测速服务器上的结果,换一个服务器,数字就可能换一个量级。
最常见的干扰来自测速服务器的位置。测速软件默认挑延迟最低的服务器,如果它选中的是同城节点,你测到的是本地宽带的数字,整段跨境路径根本没有参与进来。想比较线路,必须手动把测速服务器固定到目标地区。
第二个干扰是单位。测速软件用 Mbps(兆比特每秒),下载工具用 MB/s(兆字节每秒),两者相差 8 倍:100 Mbps 约等于 12.5 MB/s。截图里出现 100 MB/s,等于 800 Mbps,先做一次换算,再判断它是否落在自家宽带的量级之内。
「Mbps」与「MB/s」只差一个字母,数字却差 8 倍。看到特别漂亮的截图,先找单位,再做一次除法。
- 8× 1 MB/s 与 Mbps 之间的换算倍数,截图放大数字最常用的手法
- 3 次 同一时段最少重复次数,取中位数而不是峰值
- 3 档 白天、晚高峰、深夜,至少覆盖三个时段
- 20–23 北京时间晚高峰所在的小时区间,跨境线路掉速最集中的窗口
测速前先固定的五个变量
测速不是打开网页点一下按钮,而是一次条件受控的对比。下面五个变量只要有一个变动,前后两次的数字就不能直接比较。
- 设备与接入方式 —— 同一台设备、同一个浏览器;能用网线就不用 Wi-Fi。走 Wi-Fi 时先确认信号强度,否则测到的是设备与路由器之间的距离。
- 客户端与协议 —— Shadowsocks、VMess、Trojan、VLESS 的常见配置走 TCP 传输,遇到丢包时受拥塞控制影响,速度会明显下滑;Hysteria2、TUIC 基于 QUIC/UDP,在高丢包链路上更容易保住吞吐,但对运营商的 UDP 策略更敏感。比较数字时,协议必须保持一致。
- 分流模式 —— 全局模式与规则模式的流量走向可能完全不同。规则模式下,测速服务器的域名可能命中直连规则,这时你测的其实是本地宽带。
- 测速服务器 —— 固定同一座城市、同一家运营商的服务器。换服务器等于换了一把尺子。
- 时段 —— 至少覆盖白天、晚高峰、深夜三档,并连续记录几天,而不是只挑状态最好的那一刻。
测速前打开我的 IP页面,确认出口 IP 属于目标地区。如果显示的仍是本地 IP,说明流量走了直连,后面的数字与线路无关。
用哪些工具测:浏览器、命令行与客户端内置
工具没有绝对的好坏,关键是知道每个工具在测什么。带宽、延迟、丢包是三件不同的事,很少有工具能把三件事同时测准。
| 工具 | 类型 | 主要看什么 | 注意点 |
|---|---|---|---|
| Speedtest(Ookla)网页版 / 桌面端 | 多线程带宽 | 下行、上行、延迟、抖动 | 默认自动挑最近服务器,必须手动指定目标地区 |
| fast.com | 多线程带宽 | 下行带宽,可切换上行 | 节点由 Netflix 指定,不能更换,适合作为视频场景参考 |
| Cloudflare Speed Test | 延迟与带宽 | 空载与负载延迟、抖动、丢包、上下行 | 能看到跑满带宽时的延迟变化,不只是一个峰值数字 |
| iperf3 | 裸吞吐 | 自建服务端与客户端之间的上下行 | 需要自备境外服务器,结果与服务端位置强相关 |
| mtr / WinMTR | 路径质量 | 逐跳延迟与丢包 | 只测路径不测带宽,用来定位从哪一跳开始劣化 |
| curl / 浏览器下载 | 单连接实测 | 单个 HTTPS 连接的实际吞吐与首字节时间 | 最接近打开网页、拉一个文件的真实体验 |
另外,不少客户端内置的「测速」按钮只对节点做一次握手或一次 HTTP 请求,量出来的是延迟,不是带宽。把它当作挑节点的初筛可以,当作速度结论不行。
看哪几个指标:延迟、抖动、丢包与单线程带宽
带宽数字最容易看,也最容易误导。按对体验的影响排序,依次是丢包、抖动、延迟,最后才是带宽上限。
- 延迟(RTT):数据一个来回的毫秒数,决定点击之后的反应速度。数值低、波动小才算好。
- 抖动(jitter):连续多次延迟的波动幅度。抖动大的线路,带宽再高,视频会议与实时对战也会卡。
- 丢包:跨境链路上最伤体验的一项。TCP 类协议遇到丢包会降速重传,带宽数字跟着掉;UDP 类协议不重传,但画面会花、声音会断。
- 下行带宽:决定下载与视频播放的上限。
- 上行带宽:通常低于下行,直播推流、网盘同步、云端保存更依赖它。
- 首字节时间(TTFB):从发起请求到收到第一个字节的时间,受延迟与 DNS 解析共同影响。
还要区分单线程与多线程。多线程测速把多条连接的结果相加,能跑到带宽上限,却会掩盖单条连接的劣化;单线程更接近看视频缓冲、下载一个文件时的真实感受。两个数字都记下来,差距越大,说明这条线路越依赖并发。
# 单连接实测:看真实吞吐与首字节时间(Cloudflare 测速端点)
curl -o /dev/null -s -w 'dns %{time_namelookup}s | connect %{time_connect}s | ttfb %{time_starttransfer}s | speed %{speed_download} B/s\n' \
'https://speed.cloudflare.com/__down?bytes=100000000'
# 路径质量:连续 50 个探测包,看逐跳延迟与丢包
mtr -rwzc 50 1.1.1.1每次测试记六列:时间、线路与地区、协议、延迟、抖动、单线程下行。多线程结果另记一列,不要拿它和单线程数字互相比较。
分时段、分天数记录:一份可复现的测试流程
下面这套流程不需要额外工具,一台设备、一张表格就能跑完。它测的不是「最快能到多少」,而是「这条线路在什么时段、以多大波动提供多少带宽」。
- 断开线路,先测基线:同一台设备、同一个测速服务器,记录本地宽带的延迟与下行。
- 连上线路,把客户端切到全局模式,或确认分流规则覆盖了测速服务器的域名。
- 打开 IP 查询页面,确认出口 IP 已经变成目标地区。
- 使用同一个测速服务器连续测 3 次,记录每次的延迟、抖动、下行与上行。
- 用 curl 或浏览器下载做一次单线程测试,记录实际吞吐与首字节时间。
- 用 mtr 跑 50 个探测包,看从哪一跳开始出现丢包。
- 换到下一个时段,重复第 2 至第 6 步,至少覆盖白天、晚高峰、深夜三档。
- 连续记录几天之后,比较各时段的中位数与波动范围,而不是最好看的那一次。
如何识别被美化的测速截图
先把线路类型分清楚
直连、中转与 IEPL 专线的路径完全不同,数字放在一起比没有意义。
- 直连:客户端直接连到境外机房,全程走公网。成本低,晚高峰受国际出口拥塞的影响最明显。
- 中转:先连到国内中转服务器,再由中转出海。路径可控、跳数少,通常比直连稳定,瓶颈可能出现在中转节点本身。
- IEPL 专线:端到端的国际以太网专线,不经过公网国际出口,延迟与抖动更稳定,成本也更高。
截图自检清单
- ✅ 截图里能看到测速服务器的城市与运营商,以及测试时间。
- ✅ 单位标注清楚是 Mbps 还是 MB/s,并且前后一致。
- ✅ 延迟、抖动、丢包与带宽一起给出,而不是只给一个下行数字。
- ✅ 单线程与多线程结果分开列出,并注明测试的是哪条线路。
- ❌ 只截峰值那一次,不显示服务器、时间与单位。
- ❌ 数字在 Mbps 与 MB/s 之间来回切换,看起来大了一截。
- ❌ 用同城测速服务器或局域网 iperf3 的结果,冒充跨境线路速度。
- ❌ 不说明协议与线路类型,把直连、中转、IEPL 专线的结果混在一张图里比较。
常见误区与结论
- 数字越大越好 —— 带宽只决定上限,延迟与丢包决定下限。
- 测一次就能下结论 —— 跨境链路的状态随时段变化,单次结果说明不了稳定性。
- 同一个客户端里所有线路速度一样 —— 不同地区、不同线路类型的路径完全不同,要分别测。
- 延迟低就等于快 —— 带宽不足时带宽不足时,低延迟也只够发文字消息,视频照样要缓冲。
- 只盯测速软件的单个数字 —— 网页打开慢、视频缓冲,常常来自 DNS 解析或单连接质量,聚合带宽的测速结果未必反映得出来。
回到开头的问题:准确的测速,本质是把变量固定住之后的重复对比。先固定设备、协议、分流模式与测速服务器,再分时段记录延迟、抖动、丢包与单线程带宽,最后比较中位数与波动范围,而不是最好看的那一次。这样得到的数字,才能用来判断一条线路是否值得长期使用。