机场评测里那种一屏装不下的彩色表格，第一次看多半只会盯着数字最大的那几行。图上真正决定它能不能用来做判断的东西，在最下面两行小字里。
表格里那几列分别是什么
本站用的测速工具会输出这么几列。
| 列名 | 它在量什么 |
|---|---|
| 序号 | 排序后的行号，不是订阅里的原始顺序 |
| 节点名称 | 机场自己填的标签，怎么读见术语部分 |
| 类型 | 协议，VLESS、Trojan、AnyTLS 之类 |
| TLS RTT | 一次数据交换来回的耗时，图注写的是单次数据交换延迟 |
| HTTPS 延迟 | 一次完整 HTTP 请求的耗时，图注写的是单次请求体感延迟 |
| 平均速度 | 整段测试的平均下载速度 |
| 最高速度 | 测试过程中出现过的瞬时峰值 |
| 每秒速度 | 一个小柱状图，画出速度随时间的变化 |
| UDP 类型 | 该节点的 NAT 类型 |
最后一列容易被跳过。FullCone、RestrictedCone、Symmetric 这几个词出自 RFC 3489 对四种 NAT 类型的划分，Full Cone 的限制最少，内网映射到外网之后任何外部主机都能往回发包。打联机游戏、用点对点通话的人要盯这一列，只看网页和视频的人可以忽略它。
每秒速度那个小柱状图比平均值更能说明问题。柱子一路平齐，说明这个节点全程都稳。柱子开头冲得很高随后一路往下掉，说明它只是开头那几秒抢到了带宽。本站 2026-07-18 测闪跃时，日本那十个节点的曲线全是后一种形状。
页脚那两行决定这张图能不能比
表格底下通常有两行参数。本站 2026-07-18 那张图的页脚写着后端是珠海联通 9Gbps，线程等于 32，概要 50 比 50，排序按平均速度降序，测试时间是当天 21 点 18 分 08 秒。
这五项缺一项，图就没法和别的图并排看。
后端宽带定的是天花板。在 1Gbps 的线路上测，任何节点都不可能超过 125MB/s 左右。本站 2026-07-19 用广东中山电信 1Gbps 的线路测星岛梦，香港 19 个节点均速 63 到 99MB/s。前一天用珠海联通 9Gbps 的线路测同一份订阅，香港最高 432MB/s。换算一下就明白，后一个数字贴着 1Gbps 线路的上限，节点还有多少余量，在那条线上根本测不出来。
线程数定的是测法，下一节单说。
概要那一项写的是跑通了多少个节点。50 比 50 表示全部跑完。本站另一轮测星岛梦是 65 个节点，其中 11 个速度为零，这时候看的应该是 54 比 65。
排序方式决定你看到的顺序。按平均速度降序，末尾那几行零值就被推到最底下，一屏截图很容易把它们裁掉。按延迟降序又是另一个样子。
测试时间决定这张图属于哪个时段。晚上九点和下午三点的结果不能混着看，为什么会差，写在机场晚高峰速度慢里。
32 线程和单线程测的不是同一件事
多线程的意思是同时开若干条连接下载同一份数据，把它们的速度加起来。
这件事有学术界的对比结论可引。MacMillan 等人比较 Ookla Speedtest 和 NDT7 的论文里写明，NDT7 只开一条 TCP 连接、固定跑十秒，Ookla 会根据测到的速度动态调整连接数，延迟到 20 毫秒就开始用多条，延迟超过 100 毫秒时最多开到八条。在有背景流量的情况下，单连接的 NDT7 报出来的是自己那一份公平份额，也就是链路容量的一半上下，多连接的 Ookla 能报到八成以上。论文的结论写得很直白，使用多条 TCP 连接或者跑得更久的测速工具，在高延迟和有背景流量时会报出更高的速度。
机场节点的延迟正好落在那篇论文说的高延迟区间。本站图上香港节点的 TLS RTT 在 90 到 120 毫秒，美国在 240 毫秒以上。所以 32 线程测出来的 500MB/s，量的是这个节点在那一刻能给到的带宽上限，单台设备开一个下载任务达不到这个数。
那为什么还用多线程。因为它把节点之间的差距放大了，比起来更容易看清哪个地区、哪条线路给得足。想知道日常体验，看单线程或者看实际应用里的数字更贴近，比如播放器自己显示的码率。
哪几个数字基本没有参考价值
最高速度那一列。它是瞬时峰值，取决于测试开头那零点几秒抢到了多少带宽，两个平均速度差三倍的节点，峰值可能差不多。
跨机场比绝对速度。不同机场的图往往是在不同后端上跑的，本站手里这几批就分别来自珠海联通 9Gbps、广东中山电信 1Gbps 和广州移动的线路。数字直接对比没有意义，能比的是同一张图里节点之间的相对差距。
按延迟排的名次。延迟和带宽经常不同步。2026-07-18 那轮里，闪跃的美国节点 TLS RTT 是 243 到 249 毫秒，看着很正常，平均速度只有 8.63 到 13.89MB/s。灵动云 7 月那一轮反过来，HTTPS 延迟普遍偏高，速度落在 20 到 80MB/s 的够用区间。客户端里那个「自动选择」的策略组对应 Mihomo 的 url-test，它比的也只有延迟，看不见带宽。
单次测试的绝对值。一张图是一个时刻的切片，节点表现会变。本站测星岛梦时，2026-06-17 是 60 个节点、香港均速 375 到 424MB/s，一个月后复测变成 65 个节点、11 个速度为零。两张图都是真的。
解锁表要单独读
解锁测试是另一张表，前面几列一样，后面换成 INTL_youtube、INTL_netflix、INTL_disney_plus 这类检测项，格子里写着「解锁(HK)」或者别的地区码。
读它有两个要点。第一，这类测试通常走单线程，页脚的线程数和测速图不一样，两张图的速度列不能互相印证。第二，括号里的地区码要和节点所在地对得上。本站 2026-06-27 测星岛梦的解锁，60 个 VLESS 加 10 个 AnyTLS 节点里，新加坡和台湾节点的 YouTube 多数被判到中国区，这种情况在表上写作送中，看起来是解锁了，实际拿到的是中国区内容。
解锁结果的保质期比速度更短。今天全绿，下个月平台换一轮风控规则就可能变，这也是本站不把解锁写进长期结论的原因。
自己测的时候怎么让结果可比
把变量固定住就行。
宽带、设备、测速工具三样每次保持一致，并且记下时间。测之前把模式临时切到全局，保证测速流量确实走了你选的那个节点，测完切回规则模式。要比晚高峰，就固定在晚上九点前后，连测三到五天，别拿一天的结果下结论。
要比不同机场，最好在同一个晚上依次测完，中间不要换网络环境。
本站的测法、样本范围和结论停在哪里，写在评测方法里。挑机场时这些数据该怎么用，见怎么选机场；第一单为什么建议先买月付，见这一篇。