机场测速怎么看？延迟、速度与丢包率详解

打开机场客户端，每个节点后面都挂着一个延迟数字；测速网站跑一次，又得到一组下载上传速度。这些数字到底说明什么、哪个更重要、怎么判断一条线路适不适合自己，是很多用户在选购和排查时的共同困惑。本文从指标定义讲起，给出参考表与测试命令，最后澄清几个常见误区。

五个核心指标的定义

延迟（Latency / RTT）

数据包从你的设备到目标服务器再返回所需的时间，单位毫秒。它由物理距离、路由跳数和中间设备处理时间共同决定。深圳到香港的物理延迟底线约 5ms，到美国西海岸约 130ms，到欧洲约 200ms，任何线路都无法低于物理极限。

抖动（Jitter）

延迟的波动程度，通常用延迟的标准差或最大最小差值表示。抖动大意味着数据包到达时间不规律，对实时语音、视频会议和 AI 流式输出影响显著。

丢包率（Packet Loss）

发送的数据包中未能到达目标的比例。TCP 会重传丢失的包，但重传需要时间，并且会触发拥塞控制降低发送速率。对长连接而言，丢包是最致命的指标。

下载速度 / 上传速度

单位时间内能传输的数据量，通常以 Mbps（兆比特每秒）表示。它受机场节点带宽、本地宽带、协议开销与服务器端限制共同影响。注意 Mbps 与 MB/s 相差 8 倍。

首字节时间（TTFB）

从发出请求到收到第一个字节响应的时间，包含 DNS 解析、TCP 握手、TLS 握手和服务器处理时间。对 AI 工具来说，它直接决定提问后多久出现第一个字。

读数参考表

以下参考值基于到常见目标（美国西海岸、日本、新加坡等 AI 服务常用区域）的端到端测试，适用于中国大陆用户。

指标	优秀	良好	一般	较差
延迟（香港 / 日本节点）	< 60ms	60–120ms	120–200ms	> 200ms
延迟（美国节点）	< 160ms	160–220ms	220–300ms	> 300ms
延迟标准差	< 15ms	15–40ms	40–80ms	> 80ms
丢包率	< 0.5%	0.5%–1%	1%–2%	> 2%
下载速度	> 100Mbps	50–100Mbps	20–50Mbps	< 20Mbps
TTFB	< 0.8s	0.8–1.5s	1.5–3s	> 3s

读表时记住一个原则：对日常浏览与视频，带宽与延迟均值最重要；对 AI 工具、远程办公与游戏，丢包率与标准差最重要。一条「延迟一般、丢包优秀」的线路，跑 AI 工具的体验往往好于「延迟优秀、丢包较差」的线路。原因在 AI 工具网络延迟与连接稳定性分析 中有详细说明。

测速工具与方法

客户端内置延迟测试

Clash Verge Rev、Mihomo Party、Clash Meta for Android 等客户端的延迟测试，默认是向一个测试 URL（通常是 Google 或 Cloudflare 的 204 页面）发一次 HTTP 请求并计时。它只能回答「节点通不通」，不能回答「节点稳不稳」。合理的用法是：用它快速排除完全不通的节点，然后对候选节点做下面的深入测试。

ping：连续延迟与丢包

# macOS / Linux，发 100 个包
ping -c 100 www.google.com

# Windows
ping -n 100 www.google.com

关注末尾统计中的丢包数、最小/平均/最大延迟。最大值与平均值相差过大说明有抖动。测试时客户端应处于规则或全局模式，并确保该域名走代理。

mtr：逐跳诊断

# -r 报告模式，-c 100 发 100 个包，-n 不解析主机名
sudo mtr -r -n -c 100 api.anthropic.com

mtr 输出每一跳的丢包率（Loss%）、平均延迟（Avg）和标准差（StDev）。判断规则：

1. 中间某跳丢包但后续跳不丢，是该路由器限制了 ICMP 响应，可忽略。
2. 从某一跳开始后续所有跳都丢包，问题出在那一跳。
3. 最后一跳的 Loss% 和 StDev 是最终结论。

curl 计时：分解请求耗时

curl -o /dev/null -s -w "namelookup: %{time_namelookup}\nconnect: %{time_connect}\nappconnect: %{time_appconnect}\nstarttransfer: %{time_starttransfer}\ntotal: %{time_total}\n" https://chatgpt.com/

各阶段差值分别对应 DNS、TCP、TLS 与服务器响应时间。TLS 阶段明显偏长通常说明代理层开销大或线路丢包导致握手重传。

带宽测试

浏览器访问 Speedtest、Fast.com 等测速网站是最简单的方式。需要注意：测速网站会自动选择最近的测速服务器，经过代理后「最近」指的是距离节点最近，结果反映的是节点带宽，不完全等于访问特定服务的速度。

更精确的方法是用 iperf3 连接一个已知带宽的境外服务器，或者直接下载一个大文件观察稳定速率：

# 下载测试文件并显示平均速度，结果中 Average Dload 即平均下载速度
curl -o /dev/null https://speed.cloudflare.com/__down?bytes=100000000

一套完整的测速流程

把上面的工具组合起来，可以形成一个 15 分钟内完成的标准流程：

1. 客户端批量测延迟，剔除超时节点。
2. 对候选节点逐个做 100 包 ping，记录丢包与最大延迟。
3. 对丢包最低的 2–3 个节点做 mtr，确认最后一跳的 Loss% 与 StDev。
4. 对最终候选做 curl 计时，确认 TTFB。
5. 在晚高峰重复第 2–4 步。
6. 用目标应用（例如让 Claude 输出一篇长文）做实际验证。

这个流程也是本站评测各机场品牌时的基本方法，评分规则见 机场排行是怎么计算的。

常见误区

误区一：延迟越低越好。 延迟低于一定值后，体验差异几乎不可感知。50ms 和 80ms 打开网页的区别人眼无法分辨，但 0% 和 3% 的丢包区别一目了然。

误区二：测速网站跑分高就是好线路。 测速网站使用多线程、短时间突发传输，对丢包不敏感。一条高带宽但高丢包的线路可以跑出漂亮分数，实际使用却频繁中断。

误区三：只测一次就下结论。 网络是动态的，节点负载、路由变化、本地网络波动都会影响单次结果。至少三次、覆盖不同时段的测试才有参考价值。

误区四：把客户端延迟当作到目标服务的延迟。 客户端测试 URL 通常是 CDN 节点，距离代理出口很近。到 AI 服务真实 API 的延迟往往高出不少。

误区五：忽略本地网络。 很多「机场慢」其实是 Wi-Fi 信号差或本地运营商拥塞。先在直连模式下测一次本地网络，排除本地问题再评估机场。

小结

测速不是为了得到一个漂亮的数字，而是为了回答「这条线路能不能满足我的用途」。先确定用途，再决定看哪个指标：浏览和视频看带宽，AI 工具和会议看丢包与抖动。用 ping、mtr、curl 三件工具覆盖晚高峰做多次测试，结论才可靠。线路类型对这些指标的影响，可以继续阅读 IEPL 与 IPLC 线路知识介绍，更多内容见 线路与测速栏目。