加速器速度实测方法的核心不是打开测速站跑一次,而是把测量条件固定下来,让今天的结果和下周的结果能放进同一张表里比较。延迟、抖动、丢包、带宽这四项回答的是不同问题,晚高峰的表现又和平常时段差出一截。下面按顺序给出可复现的流程:测哪几个指标、在什么时段测、测几次取什么值、结果怎么读,以及为什么各家宣传页上的数字彼此不可比。
测速到底测哪几个指标
「快不快」是一个笼统说法,拆开至少是四个可以分别测量的量:延迟、抖动、丢包与带宽。它们之间没有换算关系——延迟低的线路带宽可能很小,标称带宽大的线路在晚高峰可能抖得厉害。把四项分开记录,才能判断问题出在物理距离、链路拥塞,还是本地网络本身。
| 指标 | 单位 | 常用测法 | 判读时注意 |
|---|---|---|---|
| 延迟 RTT | 毫秒 | 客户端内置延迟测试、TCP 握手耗时 | 物理距离决定下限,跨洲不可能与同城相同 |
| 抖动 | 毫秒 | 连续 10 个以上样本之间的差值 | 中位数好看但抖动大,通话照样断续 |
| 丢包 | 百分比 | 连续探测或 TCP 重传统计 | 先看丢包再看延迟,顺序不能反 |
| 下行 / 上行带宽 | Mbps | 单线程与多线程各测一遍 | 结果不会超过本地宽带套餐上限 |
| DNS 解析耗时 | 毫秒 | 首次访问一个新域名时的耗时 | 解析走本地还是走隧道,结果差很多 |
| 首字节时间 | 毫秒 | 浏览器开发者工具的网络面板 | 受目标站点自身影响,不能全算在线路上 |
ICMP 探测在部分网络里会被限速或直接丢弃,ping 不通不等于线路不通。判断连通性用 TCP 握手耗时或客户端内置的延迟测试更可靠,也更接近浏览器实际建立连接的过程。
先把测试条件固定下来
同一个节点,在不同设备、不同无线频段、不同后台负载下,实测结果能差出一倍。测速的第一步不是点开始,而是把变量固定住,否则后面的数据只能当参考,不能当依据。
- ✅ 全程用同一台设备、同一个网络,中途不换 Wi-Fi、不切移动数据。
- ✅ 优先用网线;只能用无线时,固定在 5GHz 频段并保持同一位置。
- ✅ 关闭系统更新、网盘同步、在线视频等后台流量。
- ✅ 同一组对比里,客户端、协议与目标节点保持一致。
- ✅ 每次测完记录时间戳,晚高峰与平常时段分开统计。
- ❌ 不要一边下载一边测速,也不要在测速途中切换节点。
协议也要固定。VMess 依赖客户端与服务端时间一致,系统时间偏差会导致握手失败,而不是单纯变慢;Hysteria2 与 TUIC 基于 QUIC 走 UDP,在高丢包的链路上通常比 TCP 类协议更稳,但如果本地网络对 UDP 有限速,结果会反过来。换协议必须单独记一行,不要和上一组混在一起求平均。
时段安排:晚高峰单独列一行
国际线路的带宽是共享的。晚上 20:00 到 23:00,本地运营商的出口与跨境方向同时吃紧,同一条线路在这个时段的实测值可能只有上午的一半。只在空闲时段测速,得到的是一天里最好看的那组数字,和你真正要用它的时间对不上。
建议的时段是上午 10:00 作为基线、下午 15:00 作为次基线、晚上 21:00 作为晚高峰样本、深夜 00:30 作为对照。每个时段测 3 轮,轮与轮之间隔 2 到 3 分钟,取中位数。平均值容易被一次异常样本拉偏,最好值不能代表你打开网页时的常态,中位数对个别异常不敏感,更接近日常体感。
延迟、抖动与丢包怎么读
光在光纤里的传播速度约为每秒 20 万公里,往返距离直接决定延迟下限。亚洲邻国节点往返一两千公里,理论下限就在几十毫秒;跨太平洋往返两万公里以上,下限本身已经超过 100 毫秒。所以同一张截图里出现「东京 30 毫秒」和「洛杉矶 30 毫秒」,后者测到的多半是本地入口,不是真正的出口节点。
- 同区域:30 毫秒以内,点击与翻页基本无感。
- 亚洲邻国:30 到 80 毫秒,网页、视频与文件下载都正常。
- 跨洲:120 到 250 毫秒,页面能开,实时对战类操作会感到迟滞。
- 超过 300 毫秒:从点击到响应之间有明显的等待。
以上是经验参考区间,不是承诺值,实际结果还受本地运营商、线路类型与目标站点位置影响。抖动看的是相邻样本之间的差值:连续 10 个样本里最大与最小相差 50 毫秒,即使中位数只有 60 毫秒,语音通话也会出现断续。对实时音视频来说,抖动比延迟更致命。丢包率在 1% 以下基本无感,3% 以上视频开始花屏、网页偶发加载失败,10% 以上基本不可用;丢包一旦出现,先换线路类型,再考虑换协议。
只测一次就下结论是最常见的错误。一次结果里混着线路状态、瞬时拥塞与本地网络波动三种因素,至少 3 轮、每轮 10 个样本,数字才有可比性。
带宽:单线程、多线程与单位换算
单线程带宽决定单个连接的吞吐,看高码率视频、下载单个大文件都靠它;多线程带宽决定总量,多任务并行时才用得上。浏览器里的测速站通常同时开多个连接,数字好看;客户端内置测速多为单线程或可指定连接数,数字更接近单个应用的真实体感。两者都要测,但不能混着比较。
单位先对齐。Mbps 是每秒兆比特,MB/s 是每秒兆字节,两者相差 8 倍,100 Mbps 约等于 12.5 MB/s。把下载器显示的 12 MB/s 当成 12 Mbps,会误以为线路只有标称值的一成。
带宽上限受三重约束:本地宽带套餐、节点侧的带宽分配、协议封装开销。实测下行不会超过本地套餐,通常还会低一截;上行普遍远小于下行,视频会议卡顿时先看上行,而不是继续测下行。
宣传数字为什么彼此不可比
两个速度数字能不能放在一起比,先看四件事是否一致:测速目标的位置、连接线程数、测试时段、探测方式(ICMP、TCP 还是应用层)。这四项里有一项不同,结论就可能反过来。
| 常见口径 | 实际含义 | 复现需要的条件 |
|---|---|---|
| 标称最高带宽 | 最优时段、最优节点下的多线程峰值 | 同一时段、同一节点、同样线程数 |
| 标称最低延迟 | 到最近入口或最近节点的探测值 | 说明测的是入口还是出口、用哪种探测 |
| 不限速 | 没有人为的速率上限 | 仍受本地宽带与线路容量约束 |
| 晚高峰稳定 | 该时段相对白天的下降幅度小 | 给出对比时段与样本数量 |
一家服务在宣传页写一个很高的峰值,你在家里用单线程测出它的一小部分,两者并不矛盾,因为条件不同。要做判断,只能把条件拉齐后对比:同一时段、同一节点、同一协议、同样的线程数,再看谁的晚高峰下降幅度更小。
一张可以照抄的记录表
下面是记录表的表头,一行代表某个时段的一次完整测量。用表格软件或纯文本记都可以,关键是列固定,不要中途加列。
date,slot,node,protocol,rtt_med_ms,jitter_ms,loss_pct,down_mbps,up_mbps,notedate/slot:日期与时段。时段写固定值(如 10:00、15:00、21:00、00:30),便于按列排序。node/protocol:节点城市与协议名。换过节点或协议就另起一行,不要覆盖旧数据。rtt_med_ms/jitter_ms:延迟中位数与抖动,各取 10 个以上样本。loss_pct:丢包百分比。没有丢包写 0,不要留空,留空会让后续统计漏行。down_mbps/up_mbps:下行与上行带宽,单线程、多线程各测一遍,并在备注里注明线程数。note:本地宽带档位、是否高峰、当时的异常现象(如视频同时播放)。
填写顺序建议固定成六步:
- 未连接状态下先测一轮,作为本地网络基线。
- 连接目标节点,等 10 秒让连接稳定后再开始。
- 连续 3 轮延迟测试,每轮 10 个样本,记中位数与抖动。
- 单线程、多线程各测一次带宽,分别记下行与上行。
- 换时段重复第 1 到第 4 步,结果追加到同一张表。
- 一周后按「晚高峰下行 ÷ 上午下行」算出下降比例。
下降比例在 20% 以内属于正常波动,不必处理;20% 到 50% 是能感知到的降速,可以开始比较其他线路;超过 50% 说明这条线路在该时段被挤得厉害,应当换线路类型,而不是反复换协议碰运气。
结果判读与常见误区
线路分直连、中转与专线三类。直连从本地运营商直接出境,路径最短,但高峰期波动大;中转先到国内入口再出国,路径多一跳,稳定性通常更好;专线走点对点链路,延迟与带宽更平稳,成本也更高。测的时候按线路类型分组统计,比按城市分组更容易看出规律。线路列表里每条线路都标了类型,可以直接对照着填记录表。
- 用 ping 域名测延迟:第一次结果包含 DNS 解析时间,偏高;从第二次起才是真正的往返时间。
- 把 Mbps 当成 MB/s,误以为带宽只有标称值的八分之一。
- 在测速站里选了离节点很远的测试服务器,测出来的是那台服务器到节点的距离,不是你家到节点的距离。
- 只在深夜测速,得出「从不掉速」的结论,却从没在 21:00 用过。
- 换节点后不重测基线,把新旧数据混在一张表里求平均。
测速的目的不是找一个最好看的数字,而是找出「在你要用的那个时段里最稳的那条线路」。同一时段、同一节点、同一协议,连续三轮的中位数,才是可以拿来做决定的依据。