Clash 节点测速原理详解:为什么延迟低的节点实际体验却很卡

一、延迟数字是怎么测出来的

在 Clash 客户端的节点列表里点一下测速按钮,几百毫秒后每个节点后面出现一个毫秒数。这个数字的产生过程是:内核以该节点为出口,向一个测试地址发起一次 HTTP 请求。常用测试地址是 https://www.gstatic.com/generate_204,它只返回一个 204 空响应,响应体为零字节。从请求发出到响应头返回,这一段耗时就是页面上显示的「延迟」。

把这一次请求拆开看,耗时由三段组成:本机到节点服务器建立连接(TCP 握手,TLS 类协议还要再加一轮 TLS 握手)、节点服务器到测试地址的连接与转发、测试地址生成响应并沿路返回。所以它本质上是一次「小请求全链路往返耗时」,而不是下载速度,更不是视频码率。

url-test 策略组的自动测速与手动点按是同一套机制,只是按周期自动执行。一份典型的自动选择配置如下:

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 节点A
      - 节点B
      - 节点C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

其中 interval 是测速周期,默认 300 秒一轮;tolerance 是容差,只有当某个节点比当前节点快出这个毫秒数时才切换,默认 50 毫秒,用来避免两个延迟接近的节点之间来回横跳。理解这两个参数,后面挑节点时还会用到。

二、为什么延迟低不等于快

一次 204 请求的全部数据量只有几百字节,它测的是链路的「反应速度」,完全测不出管道的「粗细」。以下几个决定实际体验的因素,延迟数字一个都反映不出来。

带宽与单连接吞吐

实际下载速度取决于链路剩余带宽与 TCP 拥塞控制。粗略地说,单条 TCP 连接的吞吐上限约等于「在途窗口大小 ÷ 往返延迟」:延迟低确实有先天优势,但前提是带宽够、不丢包。一条 30 毫秒但只剩 5 Mbps 空闲带宽的线路,下载必然输给 200 毫秒但有 300 Mbps 空闲带宽的线路。毫秒数漂亮,不代表搬数据快。

丢包:隐形杀手

TCP 一旦丢包就要重传,拥塞窗口还会回退。1% 的丢包率就足以让吞吐腰斩再腰斩,而测速那个小小的 204 请求很可能恰好一次都没碰上丢包,于是结果显示一切正常。在晚高峰的国际链路上,丢包往往比延迟更早恶化,也更要命。

抖动:稳定性的另一面

延迟忽高忽低叫抖动。测速只取一次样本,看不出抖动。看视频时的突然卡顿、游戏里的跳 ping、语音通话的断续,大多是抖动和突发丢包造成的,与平均延迟关系不大。一个平均 60 毫秒但偶尔冲到 400 毫秒的节点,体验远不如稳定在 150 毫秒的节点。

晚高峰拥塞与运营商标尺

很多线路白天空闲、晚上 20 点到 23 点挤满。如果习惯在下午测速挑节点,挑出来的「最快节点」未必扛得住晚高峰。此外,一些运营商会对特定端口或协议做限速(QoS),小请求测速感觉不到,持续大流量立刻现形。

节点服务器自身负载

节点是共享资源。同一台服务器上的用户越多,CPU 加解密排队、网卡带宽被摊薄的情况越严重。TLS、混淆等协议开销在服务端繁忙时会进一步放大响应时间——这时延迟数字也会变差,但它变差的速度往往落后于实际体验的恶化,等你看到毫秒数上涨,卡顿已经持续一阵了。

三、测速结果里还能读出什么

延迟数字不是一无是处,关键是读对。

timeout 与「慢」是两回事。测速显示 timeout,表示在超时时间(默认约 5 秒)内没有拿到响应,常见原因是节点宕机、入口被封锁或协议握手失败。这种节点应直接视为不可用,而不是「很慢的节点」。

连续多点几次,看波动而不是看单次。50、55、52 毫秒是稳定;80、300、150 毫秒是抖动大。后者即使最低值很漂亮,实际体验也往往糟糕。

用仪表盘看历史曲线。metacubexd、Yacd 这类仪表盘里可以看到每个节点的历史延迟记录,曲线平缓比数值低更值得信任。

记住测试地址的线路偏好。到 gstatic 快,不代表到常看的视频网站、游戏服务器同样快——它们走的可能是完全不同的国际出口。测速通过只说明「到测试地址这一段通」。

四、更可靠的挑节点方法

用真实流量复测。候选节点缩小到两三个之后,各挂十分钟:看一段高码率视频(播放器统计信息里的连接速度是直观指标),跑一次多线程测速,再观察单线程大文件下载是否平稳。三项都过,才算合格。
晚高峰再测一轮。20 点到 23 点之间重复上面的实测。闲时快、忙时垮的节点直接降级为备用,不要放在自动选择组的前列。
看抖动,不看单次。连续测速五到十次,记录最高值与最低值的差距,差距越小越稳。稳定性优先的场景,宁选稳定的中等延迟,不选飘忽的低延迟。
让策略组替你值班。日常浏览交给 url-test,配上合理容差;对稳定性要求高的场景(远程桌面、在线会议)用 fallback,主节点故障才切换:

proxy-groups:
  - name: 稳定优先
    type: fallback
    proxies:
      - 主力节点
      - 备用节点
    url: https://www.gstatic.com/generate_204
    interval: 120

按场景分流,而不是找一个「全能节点」。下载任务走带宽大的节点,游戏与通话走低延迟低抖动的节点,用不同策略组分开承接,谁也不耽误谁。

注意

别把测速间隔调太短。interval 改到几十秒看似「盯得紧」,实际收益很小:每次测速都会给节点和测试地址制造额外请求,过于频繁反而可能触发目标服务器的限流。300 秒上下是稳妥取值。

五、常见疑问

延迟 30 毫秒的节点,看 4K 为什么还缓冲?

因为 4K 视频要的是持续 25 Mbps 以上的吞吐,而不是低延迟。延迟合格但带宽不足或丢包偏高时,缓冲照样转圈。按第四节的方法测吞吐,而不是盯着毫秒数。

同一节点,手机快、电脑慢,是测速不准吗?

不一定是节点问题。两端到节点的链路相同,瓶颈可能在电脑这一侧:Wi-Fi 信号弱、本机防火墙拦截,或者 TUN 模式的开销。TUN 模式要多走一层虚拟网卡转发,性能弱的设备上吞吐会打折扣,这与延迟测试无关。

测速全绿,为什么还是打不开网页?

测速只验证「到测试地址」这一段通不通,规则匹配错误、DNS 解析异常都不在它的检查范围内。这类问题可以对照常见问题页逐项排查,方向是系统代理开关、规则模式与 DNS 设置。