机场测速，不只是看客户端里那个毫秒数。延迟、下载速度、抖动和丢包回答的是不同的问题：请求多久开始有响应、单位时间能传多少数据、响应稳不稳定，以及测试中有多少数据没按规则到达。我们建议先弄清每个数字测的是什么，再动手测、再比较。
延迟、下载速度和丢包有什么区别
| 指标 | 可以帮助观察 | 不能直接证明 |
|---|---|---|
| 延迟 | 指定测试请求的响应快慢 | 所有网站都同样快 |
| 下载速度（吞吐量） | 当时这条路径的数据传输能力 | 其他时段或全部节点的表现 |
| 抖动 | 多次延迟结果的变化幅度 | 某种服务永远不卡顿 |
| 丢包或失败率 | 对应方法下的异常比例 | 所有失败都由机场造成 |
尤其要核对“延迟”测的是什么。浏览器请求、ICMP 测试和客户端健康检查未必采用同一种方法。Cloudflare 明确说明了自己的延迟和抖动计算方式，也解释了不同测速结果可能受路由和方法影响；所以先看工具说明，再把结果放进同一张比较表。Cloudflare 测速方法
客户端内测速：节点延迟测试不是带宽测试
多数客户端的节点列表都有延迟测试按钮，测的是通过这个节点请求一个测试网址需要多久。以 Mihomo 的 url-test 为例，它通过候选节点请求配置好的测试 URL，再依据结果选择节点，容差字段的单位是毫秒。这个 URL 是测试目标，不是订阅下载地址。一次探测较快，并不意味着大文件能持续高速下载，也不能证明视频片库或账号功能可用。Mihomo 自动选择文档
所以，先确认应用实际使用的节点和策略，再分别记录健康检查、下载速度和目标应用的结果。自动选择切换节点后，旧连接不一定代表刚选中的路径，比较时要重新建立对应的请求，并记下节点。
网页测速：测下载、上传和抖动
想知道“能跑多快”，要用网页或专门的测速工具测吞吐量。我们建议这样做：
- 选定一个节点，确认浏览器确实在走这个节点。
- 关掉其他设备和程序的大流量下载，避免互相干扰。
- 打开测速页面（例如上面提到的 Cloudflare 测速），记录下载、上传、延迟和抖动。
- 同一个节点隔几分钟再测一两次，看结果是否接近；只测一次的数字参考价值有限。
- 记下测试时间、本地网络（宽带或手机网络）、节点名称和测速工具，方便以后对照。
晚高峰怎么测
晚上用的人多，不少线路在这个时段表现会变化。如果你主要在晚上用，就在晚上同一时段、连续几天，用同样的方法测几次，再和白天的结果对比。完整的时段安排和记录表，见机场晚高峰怎么测；测之前先选对地区，可以看机场节点推荐。
怎么看测速结果
比数字之前先统一单位
Mbps 表示兆比特每秒，MB/s 表示兆字节每秒，两者不能直接比较。**计算示例，不是实测结果：**80Mbps 按每字节 8 比特换算，约为 10MB/s；实际应用显示还可能受传输与统计口径影响。把 80 和 10 当成八倍的性能差距，会得到错误结论。
条件不同的结果不能直接横比
比较两张测速图时，还要核对测试目标、文件大小、并发方式、浏览器、本地接入，以及是否有其他设备在同时传输。只要这些条件明显不同，就应该说明不能直接横比，而不是挑最好看的数字给所有品牌排队。我们自己也按这个原则处理：没有实测的品牌，不写速度结论。
常见问题
延迟很低，看视频还是卡，先看什么？
看实际播放用的节点、持续传输能力和播放器状态，同时检查本地网络。一个健康检查的毫秒数不能定位全部原因。
丢包显示为零，就能写长期稳定吗？
只能描述这一次测试在对应方法和时长里的结果。要说长期稳定，需要跨时段、重复记录，并写明条件。
几款工具结果不一致，哪款算准？
先核对测试目标和算法。结果可能都正确地描述了各自的方法，不能不加分析就把最高值当作服务能力。