节点测速怎么看？延迟、丢包和晚高峰测试方法
节点测速显示很快，网页却总要等一会儿；白天体验不错，晚上又明显变慢。遇到这些情况，先别急着凭一次结果给节点下结论。
有参考价值的机场测速，要记录测试条件，还要区分延迟、传输速度和实际应用体验。 下面这套方法，适合用来比较自己常用的几个节点，也方便读懂别人发布的测评。
先看懂四个常见指标
| 指标 | 通俗理解 | 比较时要注意什么 |
|---|---|---|
| 延迟 | 一次往返需要等待多久 | 测试目标与测试方法要一致 |
| 下载、上传速度 | 单位时间能传多少数据 | 单位、文件大小、服务器都可能影响结果 |
| 抖动 | 延迟是否忽高忽低 | 对持续通话等场景尤其值得关注 |
| 丢包 | 测试过程中是否有数据包未到达 | 要结合检测方法和样本量判断 |
Cloudflare 的网络质量评估会综合使用这些指标，而不是只看下载速度。查看 AIM 指标说明。对用户来说，最有用的问题是：这些表现会不会影响自己实际要做的事。
客户端里的“延迟”，不一定是 Ping
有些客户端通过请求一个指定网页来做健康检查。以 Mihomo 为例，健康检查有单独的目标地址、超时时间和预期状态设置。查看健康检查文档。
据此可以判断：目标地址不同、超时条件不同，两次数字就不宜直接比较。显示超时，也只说明该次检查没有按预期完成，不能单独证明所有应用都无法连接。
比较节点 A 和 B 时，至少保证它们使用同一客户端、同一测试目标和相近的测试时间。把不同网站、不同软件的数字拼到一起，结论往往会跑偏。
Mbps 和 MB/s，不要当成同一个单位
测速网站常见的 Mbps，与下载工具里的 MB/s 不同。按十进制单位计算，8 Mbps 对应 1 MB/s，100 Mbps 对应 12.5 MB/s。
这是单位换算，不是实际下载速度保证。协议开销、服务器限制、磁盘写入以及网络波动，都可能让最终数字不同。若工具使用 MiB/s，还应先统一单位。
同样，套餐写着较高的速率上限，说明的是一个上限条件，不能理解为任何时间、任何网站都能达到它。
自己做一次对照测试，可以这样记录
先暂停大文件同步和后台下载；条件允许时，用有线连接，或至少固定在同一位置使用 Wi-Fi。选两三个候选节点就够了。
- 记录日期、所在地区、运营商、设备和客户端版本。
- 记录节点名称、测试目标以及客户端当前模式。
- 用同一方法做少量重复测量，保留正常值与异常值。
- 打开自己常用的网页，进行短时间文件传输或通话测试。
- 换到另一个常用时段，按相同步骤再观察一次。
下面这张表可以直接复制到备忘录：
| 测试项目 | 本次记录 |
|---|---|
| 日期、时间、时区 | 自行填写 |
| 地区、运营商、网络方式 | 自行填写 |
| 客户端、版本、节点 | 自行填写 |
| 测试目标与方法 | 自行填写 |
| 延迟、速度与异常 | 自行填写 |
| 常用应用体验 | 是否等待、卡顿、重连 |
测速会产生真实流量。如果测试经过计费节点，可能消耗套餐额度；下载大文件前，先确认剩余流量和计费规则。
晚高峰测试，应该比较什么
不要只截取晚上最快的一次。可以选择自己经常使用的晚间时段，在不同日期重复观察，并保留白天同条件下的记录。
优先比较三个现象：网页首次打开是否明显变慢；持续传输是否频繁中断；实际应用是否需要不断切换节点。这些信息通常比单个峰值更适合判断日常体验。
测试结果只覆盖当时的网络与目标。Cloudflare 也说明，其测速反映的是设备与对应测试服务之间的路径；不同测量项目各有范围。查看测速工作原理。因此，对测速站表现好，不能直接推导出所有目标网站都一样快。
怎样读一篇机场测评
优先看文章有没有交代测试环境、日期、节点选择和方法，再看是否保留异常与局限。只有“很稳”“很快”或一张大数字截图，信息还不够完整。
真正值得保留的，是能让你在自己环境下重复检查的方法。如果已经出现连接失败，可接着看节点连不上排查顺序；需要比较额度，则看机场套餐选择清单。
想讨论一份测速结果，可以通过 Telegram 联系我交流。 带上时间、运营商、客户端和测试目标，截图中请遮住订阅地址与账户信息。