两套测速界面的口径差异：为什么不同工具的结果不能放在一起比

两套界面的结果只能各自成组阅读

本站的测速截图来自两套测试界面，它们的测试后端、延迟口径和记录项都不相同。不同工具给出的数字，即使字段名相近，也不是同一把尺子量出来的，所以只能各自成组阅读，不能放进同一张表比高低。

本文对照两套界面的口径，不评价工具的好坏，也不转写任何截图数值。所属专题见 本站测速批次记录与局限，测速方法的总体框架见 机场测速方法。

两套界面的身份与使用范围

版本号要照图内原样记录。工具升级后，同一个字段的计算方式可能改变，只记“某某测速”而不记版本，以后就无法判断两次结果是否同口径。

逐项口径对照

以下按 brands.ts 记录的测试条件整理，具体以图内底栏为准：

表中只有线程数一项可以确认一致。延迟口径的差别，详见 TLS RTT 和普通 RTT 有什么不同；后端带宽为什么决定吞吐天花板，详见 测速线程数和测试后端会怎样影响吞吐结果。

名称相同的字段也可能口径不同

最容易出错的不是名称不同的字段，而是名称相同的字段。两套界面都有“平均速度”，但平均的是哪段时间、是否剔除了起步阶段、采样间隔多长，截图上通常看不出来。“UDP 类型”也一样，不同工具判定 NAT 行为时使用的探测服务器和步骤不同，可能对同一节点给出不同结果。

所以读两套界面的截图时，应当把“字段名相同”理解为“大致在测同一类东西”，而不是“可以直接相减”。

工具差异与协议差异叠在一起

本站批次里有一个容易被忽略的特点：界面与截图协议完全重合。使用界面 A 的 14 张截图全部显示 Shadowsocks，使用界面 B 的 3 张全部显示 VLESS。

这在统计上叫作混杂：两个变量同时变化，就无法分辨结果差异来自哪一个。即使有人想“只比较 VLESS 与 Shadowsocks 节点”，也会同时比较到两套工具；想“只比较两套工具”，又会同时比较到两种协议。再加上测试时段与品牌也各不相同，任何跨界面的数值比较都缺少可解释的基础。

什么条件下才能并列阅读

如果以后要对两套工具的结果做并列，至少需要满足以下条件：

1. 同一节点、同一时段，用两套工具各测一次，以便观察工具本身带来的差异。
2. 延迟字段分开列，RTT 与 TLS RTT 不放在同一列。
3. 测试后端规格写进表头，不把后端不同的吞吐结果放在同一排序中。
4. 每组重复多次，记录取值方法，例如平均数或中位数。
5. 单位原样保留，确实需要换算时注明换算规则。

在满足这些条件之前，本站的做法是：每张截图只在它所在品牌页单独展示，并写明使用的界面，例如 宇宙云品牌页的测速报告 会标注它属于界面 B。

一个常见误读的拆解

设想有人把宇宙云截图和光速云截图并排放在一起，说“前者延迟更高，所以线路更差”。按上面的对照，这句话至少有四处站不住：宇宙云截图的延迟字段是 TLS RTT，光速云截图是普通 RTT，计时范围不同；两张图的测试后端规格不同；一张显示 VLESS、一张显示 Shadowsocks；两次测试分别在晚间和午后。任何一处不同都足以让比较失效，四处叠加更无从解释。

类似的误读还有“同样 32 线程，谁的平均速度高谁的带宽大”。线程数一致并不能抵消后端规格和时段的差异，结论同样不成立。遇到这类比较时，先把两张图的条件逐项列出来，通常就能看出它们不在同一口径上。

自测时如何避免口径混用

读者自己测速时，最简单的办法是在整个测试周期内只用一套工具、一个版本、一个后端。如果中途必须更换，就把更换前后的结果分成两组，不合并计算。完整的自测步骤与记录项见 自己动手测速。

关于两套界面的追问

哪套更准：本站不评价，两者各有口径，问题在于不能直接比较。

线程一样为何不能比：后端规格、延迟计时范围不同，且界面与协议重合，差异无法拆分。

同一界面内能否比较：时段、次数、节点选择都不统一，同样不做排名。测速时请遵守所在地法律法规与平台条款。