梯子测速的延迟数字怎么来的，它能说明什么

背景：这个问题从哪来

在代理客户端的节点列表里点一次测速，每个节点后面会跳出一个毫秒数，连不上的显示超时。很多人照着这个数字挑节点，挑完发现视频仍然在缓冲。也有人把同一份订阅导进两款客户端，同一个节点的读数对不上。

这两件事都和数字的测法有关。本文以 mihomo 内核为例拆开它，Clash Verge Rev 客户端用的就是这个内核。依据是 mihomo 的官方文档和源码，核验日期 2026 年 9 月 25 日；sing-box 只核对了文档里的默认值。

节点测速的数字里包含哪几次往返

mihomo 的延迟测试写在源码 adapter/adapter.go 的 URLTest 函数里。计时在连接节点之前开始，收到测试地址的响应头时停止，中间依次经过下表几步。

步骤	发生在哪两端	统一延迟关闭	统一延迟打开
与节点建立 TCP 连接	本机与节点	计入	不计入
协议握手（Trojan、带 TLS 的 VLESS 等）	本机与节点	计入	不计入
节点连上测试地址	节点与测试地址	计入	不计入
与测试地址做 TLS 握手（https 地址）	本机经节点到测试地址	计入	不计入
发出 HEAD 请求，收到响应头	本机经节点到测试地址	计入	计入

按 RFC 9110 的定义，HEAD 请求只取响应头，服务器不回正文。常用的测试地址 generate_204 返回 204 状态码，意思同样是没有内容。所以一次测试几乎不传数据，量到的是几次往返时间加在一起的总数。

统一延迟对应 mihomo 配置里的 unified-delay。文档对它的解释是，开启后计算 RTT，用来抹平不同类型节点在连接握手上的差别。源码里的做法是在同一条连接上再发一次 HEAD，只算第二次的耗时。Clash Verge Rev 设置页里有“统一延迟”开关，中文界面的提示也写着会测两次。开关状态不同，同一个节点的两个读数没法直接比较；两款客户端对不上时，先看这个开关。

测试地址、超时和测试时机也会改变读数，两种内核的相关设置列在下表。

设置	mihomo 代理组	sing-box urltest
测试地址	url，文档示例用 gstatic 的 generate_204	url，留空时用 gstatic 的 generate_204
测试间隔	interval，单位秒，不为 0 才定时测	interval，留空为 3 分钟
超时	timeout，单位毫秒	文档未列此项
自动切换容差	tolerance，单位毫秒	tolerance，留空为 50 ms

mihomo 代理组的 lazy 默认开启，没被选用的策略组不会按间隔重测，所以界面上看到的数字可能是较早一次的结果。另外，mihomo 源码里有一条警告，触发条件是统一延迟打开、测试地址以 http 开头、第二次请求失败，内容提到有的代理服务商会劫持测试地址，建议改用 HTTPS。我们的判断是，测试地址以 http 开头时，回应有可能来自半路的某一方，这时读数偏低也证明不了节点通畅。

梯子延迟低、速度慢，差在哪

延迟测试只收一个响应头，下载却要连续传输大量数据。下载速度取决于这条路径每秒能传多少，节点服务器的出口带宽、同时在用的人数、机场设的限速、本机宽带都在其中，这些在一次 HEAD 请求里几乎体现不出来。我们的判断是，读数低的节点下载可能很慢，读数高的节点下载也可能正常，两件事要分开测。本站尚未实测节点下载速度，这一节只讲测量原理，没有对照数据。

梯子测速网站给出的是另外几种数字。以 Cloudflare 测速页为例，它的方法说明写明，下载和上传速度用逐步变大的文件来测，取第 90 百分位；ping 是浏览器发出请求到开始收到数据的时间，也就是首字节时间；抖动是相邻两次 ping 差值的平均。

数字	怎么测	回答什么	说明不了什么
客户端延迟	经节点发一次 HEAD，计到响应头	节点此刻通不通，往返大约多久	带宽、其他时段
测速页 ping	请求发出到收到首字节	本机经当前路径到测速服务器的往返	到其他网站的往返
测速页下载速度	文件逐步变大，取第 90 百分位	这条路径此刻每秒能传多少	其他时段、其他服务器
抖动	相邻两次 ping 差值的平均	延迟稳不稳	丢包多少

测速页的速度单位是 Mbps，换成下载软件常用的 MB/s 要除以 8（1 MB/s ≈ 8 Mbps）。

开着梯子测速之前，先确认测速页的请求走了节点。规则模式下，测速网站的域名可能被分到直连，测出来的只是本机宽带。在客户端的连接列表里能看到这条请求用了哪个节点，分流的原理见全局模式和规则模式的区别。

本站免费节点用的是同一种测量

免费节点页的检测程序每 6 小时运行一次，页面会标明这一轮用的检测方式。采用 mihomo 方式的轮次，延迟由海外检测点调用 mihomo 的 /proxies/{节点名}/delay 接口测得。测试配置里统一延迟是关闭的，所以读数包含前面表里的全部握手。参数如下，完整说明在测试方法页。

• 测试地址两个，www.gstatic.com 和 cp.cloudflare.com 的 generate_204。
• 测两轮，第 1 轮测完等 60 秒再测第 2 轮，每次超时 5 秒。
• 4 次里至少 3 次成功才算通过，延迟取成功那几次的中位数。
• 中位数不超过 800 ms 的节点才进入收录候选。

2026 年 9 月 25 日，这套程序做过一次样本运行，从候选里抽了 300 个节点进 mihomo 测试，检测点在海外。下表是这次运行的结果（本站检测，单次运行）。

项目	结果
进入测试的节点	300 个
4 次全部成功	243 个
4 次成功 3 次	22 个
全部成功的 243 个里，最大读数不超过最小读数 1.2 倍	122 个（50.2%）
同上，最大读数达到最小读数 2 倍以上	74 个（30.5%）
按第 1 次读数排出的前 20 名，改按 4 次中位数重排后仍在前 20	13 个

同一次运行里，全部成功的节点约有三成，自己的 4 次读数最大值达到最小值的 2 倍以上；只凭一次测速排名次，前 20 名里有 7 个会换掉。

我们还对比了 149 个不走 CDN、4 次全部成功的节点（走 CDN 的节点，TCP 连的是就近的 CDN 入口，握手时间偏短，所以不算在内）。程序预筛时测到的 TCP 握手时间，中位数 220 ms；延迟读数（4 次中位数）的中位数 746 ms。逐个节点相除，延迟读数约为 TCP 握手时间的 2.8 倍，四分位范围在 2.4 到 3.9 倍之间。我们的判断是，这和第一张表“读数里含三到四次往返”的拆法对得上。TCP 预筛和延迟测试不在同一时刻，并发也不同，这个倍数只能当粗略对照。

这组数据只来自一个海外检测点的一次运行，300 个节点也是抽样。它代表不了中国大陆网络里的延迟，也代表不了其他时段。

自己怎么验证

下面几步只用客户端和浏览器，不需要本站的数据。每次梯子测速，先把条件记下来。

条件	记什么
时间	日期和时刻，注明北京时间
本机网络	运营商，有线、Wi-Fi 还是移动数据
客户端与内核	名称和版本号
统一延迟	开还是关
测试地址与超时	完整地址、超时毫秒数
次数	同一节点测了几次，中位数多少

1. 同一个节点连测 5 次，记下最小值、最大值和中位数，挑节点时按中位数排。
2. 在客户端设置里把测试地址换成另一个 generate_204 地址，同一节点再测 5 次，看中位数变了多少。
3. 统一延迟开、关各测一组。两款客户端对不上时，把两边的开关和测试地址调成一致再比。
4. 下载速度单独测。开着节点打开 Cloudflare 测速页，在连接列表里确认请求走了节点，记下下载速度、ping 和抖动三项。
5. 用 mihomo 内核的客户端，可以绕过界面直接调接口复核读数。控制地址和密钥在客户端设置或配置文件里，节点名含中文或空格时先做 URL 编码。成功时返回的 delay 字段就是毫秒数。

curl -H "Authorization: Bearer <密钥>" \
  "http://<控制地址>/proxies/<节点名>/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000"

如果所有节点同时超时，单个节点的读数就没有参考意义了，排查顺序见全部节点超时的对照测试。

这篇没有覆盖的

• sing-box、Xray 内核的计时细节没有核对源码，只查了 sing-box 文档里 urltest 的默认值；Shadowrocket 等闭源客户端的测法无从核对。
• 本站没有测过节点下载速度，也没有在中国大陆网络里测过延迟。有站长实测的机场，截图的时间、线路和工具写在各自的测评页里，入口在 28 家机场测评排行。
• 游戏里显示的 ping、UDP 连接的延迟，测法和本文的 HTTP 测试不同，本文没有涉及。
• 客户端的界面文字和默认设置会随版本变化，本文以 2026 年 9 月 25 日查阅的文档和源码为准。