自己怎么给机场测速？延迟测试与真实下载测速方法

先分清两种测速

很多人说的“测速”，其实是两件不同的事：

• 延迟测试：客户端里点一下“测速”，每个节点旁边出现一个毫秒数。它通过节点访问一个很小的测试地址，只衡量往返时间；
• 真实下载测速：通过节点下载一个大文件，衡量实际能跑多少 Mbps，同时能暴露丢包、限速和拥堵问题。

延迟测试适合快速筛掉不可用和明显过远的节点，下载测速才能回答“这个节点晚上看 4K 卡不卡”。本站的测试流程同样同时包含这两部分，完整标准见 机场测速方法。

对比项	客户端延迟测试	真实下载测速	丢包测试
测什么	小请求往返时间	实际吞吐量	数据包丢失比例
耗时	几秒	每次十几秒到一分钟	一到两分钟
消耗流量	几乎为零	每次数十至数百 MB	很少
能发现的问题	节点失效、距离过远	限速、拥堵、带宽不足	线路不稳、断流隐患
局限	不反映带宽与稳定性	受本地带宽上限约束	ping 通常只测到入口这一段

准备工作

1. 记录测试环境：城市、运营商、宽带带宽、客户端名称与版本，填入文末模板；
2. 使用有线或稳定 Wi-Fi：避免无线信号波动干扰结果；
3. 关闭其他占用：暂停下载、网盘同步和其他设备的视频播放；
4. 确认本地端口：在客户端设置中查看混合端口或 HTTP 端口，Clash Verge Rev 常见默认值为 7897，以实际设置为准；
5. 固定节点：关闭自动选择、负载均衡和故障转移，手动选中要测的节点，并保持规则模式。

分步操作

第一步：客户端延迟测试

在客户端的节点列表中执行一次批量测速，记下候选节点的延迟。超时或明显高于同地区其他节点的，直接排除。多数客户端允许修改测试地址，保持默认即可，同一轮对比中不要中途更换。

第二步：命令行多次测延迟

客户端只显示一次结果，命令行可以连续测 10 次，看中位数和波动。

Windows PowerShell：

1..10 | ForEach-Object { curl.exe -x http://127.0.0.1:7897 -o NUL -s -w "%{time_total}\n" https://www.gstatic.com/generate_204 }

macOS / Linux：

for i in $(seq 1 10); do curl -x http://127.0.0.1:7897 -o /dev/null -s -w "%{time_total}\n" https://www.gstatic.com/generate_204; done

输出单位为秒。把 10 个结果排序取中间值作为延迟，最大值与最小值之差可以粗略反映抖动。

第三步：真实下载测速

Windows PowerShell：

curl.exe -x http://127.0.0.1:7897 -o NUL -s -w "%{speed_download}\n" "https://speed.cloudflare.com/__down?bytes=100000000"

macOS / Linux：

curl -x http://127.0.0.1:7897 -o /dev/null -s -w "%{speed_download}\n" "https://speed.cloudflare.com/__down?bytes=100000000"

speed_download 的单位是字节/秒，换算方法是乘以 8 再除以 1000000 得到 Mbps。例如输出 25000000，即约 200Mbps。这是单线程结果；想测多线程，可以在浏览器中打开常用测速页面，在代理开启的情况下测试。

第四步：测到入口的丢包

在客户端的节点详情中找到服务器地址，然后：

# Windows：连续发送 100 个包，最后一行显示丢失百分比
ping -n 100 节点入口地址

# macOS / Linux
ping -c 100 节点入口地址

ping 使用 ICMP，一般不经过代理，测的是你到节点入口这一段，这恰好是晚高峰最容易拥堵的部分。部分入口禁止 ping，全部超时并不代表节点不可用。

第五步：按时段重复

在白天（如 14:00–17:00）和工作日晚高峰（20:00–23:00）各做一轮第二到第四步，至少连续 3 个工作日。晚高峰可以在 20:30 和 22:00 各测一次，覆盖高峰的前段与峰值。

测速记录模板

把下面的表格复制到笔记或表格软件中，每测一次填一行：

日期	时段	节点（地区 / 线路）	延迟中位数 ms	延迟最大值 ms	丢包率 %	下载 Mbps	异常记录
9 月 22 日	15:00	香港
9 月 22 日	20:30	香港
9 月 22 日	22:00	香港
9 月 22 日	22:00	日本

一周后计算：晚高峰平均下载速度 ÷ 白天平均下载速度，得到晚高峰保持率；再统计晚高峰丢包超过 1% 的次数和出现断流的次数。这三项结合起来，比任何单次测速都更能说明问题。

手机上怎么测

手机没有方便的命令行，可以用下面的简化方法：

1. 在 Shadowrocket、Stash 或安卓客户端的节点列表中做一次延迟测试，记录候选节点；
2. 手动选中一个节点，关闭自动选择；
3. 打开浏览器中的测速页面测下载速度，同一节点连续测 3 次；
4. 打开常用的视频应用播放一段高清视频，观察是否需要缓冲、清晰度是否自动下降；
5. 同样在白天和晚高峰各测一轮，填入上面的模板。

手机测速更容易受 Wi-Fi 信号和后台应用影响，建议靠近路由器、关闭后台下载后再测。

如何解读测速结果

拿到一周的记录之后，可以按下面的思路判断：

• 白天和晚高峰都快、丢包低：线路质量好，可以放心使用；
• 白天快、晚高峰下降一半以上但不断流：线路存在高峰拥堵，看视频可能需要降低清晰度，AI 对话一般不受影响；
• 晚高峰丢包频繁超过 1%、出现断流：不适合 AI 长连接和视频会议，建议换同机场的其他线路节点，或考虑更稳定的机场，选购思路见 晚高峰不卡的机场怎么选；
• 所有节点晚上都慢，关掉代理测国内也慢：问题在本地宽带或家庭网络，排查方法见 晚上网速变慢怎么办。

验证结果是否可信

1. 同一时段多次结果相差不应过大，差距超过一倍时应重测；
2. 白天下载速度接近本地宽带上限时，说明瓶颈在本地，晚高峰下降幅度更有参考意义；
3. 关闭代理后测一次直连国内测速，若本地网络本身晚上也变慢，说明问题不全在机场。

本站 8 家机场的实测数据可以作为对照：香港节点延迟实测 与 晚高峰实测。

常见错误

• 开着自动选择测速：节点在测试中途自动切换，数据混在一起；
• 只在白天测：白天好不代表晚上好，晚高峰数据才是重点；
• 用全局模式测国内测速站：测到的是绕行海外的速度，没有意义；
• 只测一次就下结论：偶发拥堵或偶发空闲都会误导判断；
• 忽视本地带宽上限：100M 宽带测不出 200Mbps 的节点实力。

延迟、丢包、带宽三个指标的含义见 看懂测速结果的三个指标。

请在遵守当地法律法规与相关服务条款的前提下使用网络工具。