机场节点测速教程：正确比较延迟、吞吐、抖动与晚高峰表现

选节点时只看列表里最小的延迟数字，容易错过持续传输能力和晚高峰表现。测速的目的，是验证自己的常用任务能否稳定完成，而不是追求一次最高分。

本文提供测试方法和空白记录表，没有对任何机场或节点作实际测速排名。

四类指标，回答不同问题

Cloudflare 的测速页展示下载、上传、延迟、抖动和丢包等维度，可以作为认识指标的参考；这类网页也只代表到其测试服务的路径。参考：Cloudflare Speed Test

节点测试的四个指标与固定条件流程

使用同一台设备和同一种联网方式，暂停其他大流量任务，选择相同测试目标，并确认请求确实走了待测节点。

每次记录客户端、节点、模式和时间。如果测试页面被规则分到直连，测到的就是本地直连路径，不是该节点表现。策略组自动切换时，也应记录实际选中的节点。

Wi-Fi 信号差和本地宽带拥塞会影响所有节点。先做必要的基础网络对照，再比较代理路径，避免把本地瓶颈全部算在服务商头上。

客户端显示的延迟、HTTP 请求耗时、系统 ping 和网页加载时间，可能测量不同环节。浏览器代理通常不会自动代理系统 ping；TUN 场景中的 ICMP 行为也依赖核心与设置。

v2rayN 的官方界面说明单独描述了 TUN 的 ICMP 路由策略，某些配置还可能返回本地模拟响应。因此不能仅用 ping 数字证明真实代理路径更快。参考：v2rayN TUN 与 ICMP 说明

使用同一种工具比较同一目标，不要把工具 A 的 50 ms 与工具 B 的 80 ms 直接排成名次。先问清楚测的是什么，再看数字。

可以在相同条件下重复三次，保留全部结果，再查看中位数与波动。示例：三次结果为 115、120、600 ms，中位数是 120 ms；600 ms 的波动也要保留，不能为了表格好看而删掉。该数字仅演示计算方法。

白天表现良好，还应在自己的常用晚间时段补做测试。至少核对一次持续任务，例如合法文件下载、在线会议或常用网页请求。一次速度峰值不能代表整晚稳定。

对于实时应用，留意卡顿、重连和持续延迟变化；对于文件下载，留意稳定速率与中断次数。两种用途未必会选出同一个最佳节点。

网络速率常用 Mbps，文件下载常用 MB/s。按十进制单位的理论关系，MB/s = Mbps ÷ 8。例如 100 Mbps 理论上对应 12.5 MB/s，实际传输还受协议开销等影响。不要把 100 Mbps 看成每秒下载 100 MB。

测速也会消耗流量。Cloudflare 页面提示一次测速可能消耗约 200 MB，具体量应以页面及实际过程为准；机场按倍率扣量时，计费消耗可能更高。参考：测速页面流量提示

小额度套餐不适合反复跑大文件测速。先用少量请求筛选，再对候选节点做有目的的持续测试。

日期与时段	网络方式	实际节点	测试目标与工具	三次结果	持续任务表现
待填写	待填写	待填写	待填写	待填写	待填写
待填写	待填写	待填写	待填写	待填写	待填写

另记失败次数、流量消耗与是否切换过策略。若目标服务不同，分开建表。