Clash 节点延迟测试怎么看?别只挑数字最小的

「延迟」是 Clash 界面上最显眼的数字,也是被误读最多的一个。点一下测速,节点列表从上到下刷出 78ms、143ms、361ms,很多人顺手点了最小的那个,然后发现看视频照样卡成幻灯片。这不是节点在骗人,是这个数字本来就没承诺过带宽。

它测的是一次 HTTP 握手的往返耗时:客户端通过某个节点去请求一个固定的测试地址,记录从发出到收到响应之间过了多久。整个过程传输的数据量小到可以忽略,几乎不占带宽。所以它能说明「这条路通不通、响应快不快」,完全说明不了「这条路有多宽、能不能一直宽下去」。

真正该问的问题是:你打算拿它干什么。看 4K 视频要的是持续吞吐,和 AI 工具对话要的是一条挂十几分钟不断的长连接,打游戏才是那个真正对往返延迟敏感的场景。三种需求对应三套标准,用同一个毫秒数去套,必然有两种是错的。

客户端里的那个毫秒数,到底测的是什么?#

延迟测试的完整动作是:客户端把一个探测请求塞进代理链路,发往配置里写死的测试地址,等待返回一个极小的响应。计时器从请求发出开始,到响应到达结束。

# 结构示例:策略组里的测试地址与自动测试间隔,地址已替换为占位域名
proxy-groups:
  - name: 自动选择
    type: url-test
    url: 'http://probe.example.invalid/generate_204'
    interval: 300 # 每 300 秒自动重测一次
    tolerance: 50 # 新节点要比当前节点快 50ms 以上才切换
    proxies:
      - 香港-A
      - 日本-B
      - 新加坡-C

这段配置里有两个容易被忽略的细节。url 决定了你测的是「到哪里」的延迟,换个地址整列数字会集体位移;tolerance 决定了自动切换的迟钝程度,数值太小会让节点在几个候选间来回横跳。

因为测试地址不同,同一个节点在两个客户端里显示 90ms 和 160ms 是完全正常的。跨客户端比较毫秒数,比较的其实是两个测试地址的距离。

延迟最低的节点为什么不一定最好用?#

三种情形最常见,而且它们在界面上长得一模一样。

第一种是入口近但落地拥挤。节点部署在离你很近的入口机上,握手当然快,但从入口到落地那一段被大量用户共享,一旦开始跑真实流量,带宽立刻被摊薄。第二种是采样运气。延迟测试通常只发一次探测,恰好赶上链路空闲的瞬间,数字就漂亮;连着测五次,你会看到它在 60ms 到 400ms 之间乱跳。第三种是低延迟伴随高丢包。数据包能到,只是十个里丢三个,TCP 不断重传的结果是网页打开慢得离谱,但那个握手数字依然很小。

判断一个节点是否稳定,至少要连续测五次以上并观察数字的波动幅度。单次采样的最小值,信息量接近于零。

看视频、用 AI 工具、打游戏该分别看哪个指标?#

同一批节点,换个用途排名就会重排。下面这张表是选节点时真正该照着看的东西。

需要注意的是,流媒体和 AI 工具还额外受出口 IP 类型影响,这一层和延迟完全无关。想弄清为什么同一个日本节点有人能看有人被拦,可以读一下原生 IP 与广播 IP 的判定逻辑。

自动选择、故障转移、负载均衡怎么挑?#

Clash 的策略组是一层调度逻辑,它决定「当规则说这个请求要走代理时,具体交给哪个节点」。四种常见类型的行为差别很大。

自动化带来的最大问题不是切错,而是遮蔽。故障转移把一个长期不可用的节点默默跳过,你可能几个月都不知道自己的套餐里有三分之一节点早就废了;负载均衡把连接打散,登录某些平台时会被判定为异地访问。所以策略组不是配完就不管的,建议每隔一两周手动点一次全量测速,看看有多少节点长期红着。

需要长时间保持同一身份的操作——AI 对话、网银、以及任何有风控的登录——都应该用手动选择锁定单一节点,而不是交给自动组。

节点倍率会怎样影响你的实际成本?#

倍率是机场对不同成本线路的计价方式:标 2 倍率的节点,你传 1GB 数据会从套餐里扣 2GB。专线和高质量中转的倍率通常更高,因为它的每 GB 成本本来就更高。

上表只是按倍率做的直接除法示例,用来说明换算关系。各家机场的倍率设置、是否对上行单独计费都不一样,以你所用机场的后台说明为准。

这意味着「选最快的节点」和「选最划算的节点」经常不是同一个答案。用 3 倍率的专线刷短视频是明显的浪费,而把 AI 长对话放在 0.5 倍率的直连节点上,又可能天天断线。专线到底贵在哪里,可以看IEPL 与 IPLC 的真实定义。

怎么自己做一次更接近真实体验的测试?#

这套流程大概二十分钟,结论比点一百次测速按钮都可靠。

1. 固定测试条件。 记下客户端用的测试地址,并把测试安排在你实际使用的时段,通常是工作日晚上八点到十一点。条件不固定,前后两次结果就没法对比。
2. 用延迟做粗筛,留下三到五个候选。 把红色超时和明显绕路的排除掉即可,不要在这一步排序。
3. 对每个候选跑一次真实负载。 放一段高码率视频或下载一个大文件,记录能稳定维持的速度,这才是带宽数据。
4. 做一次长连接存活测试。 挂一个十五分钟以上的连接,记录中途是否断开。这一项测的是稳定性,和前两项完全独立。
5. 把倍率折进去。 用实测带宽除以倍率,得到单位流量的实际收益,再决定谁当主力。
6. 把结论写进策略组。 胜出的两三个节点单独建一个组,其余的不要放在主用组里,减少手滑误选。

这一步做完,你手上就有一份属于自己网络环境的节点排序,而不是别人截图里的数字。测完之后顺手把订阅更新策略也调一下,节点列表变动后测试结果才不会立刻过期。

测速正常但网页打不开,问题出在哪一层?#

这是选节点环节最容易走岔的一个岔路口。延迟测试走的是客户端自己发起的探测请求,它证明客户端能从节点拿到响应;而浏览器打开网页要多经过两道关卡——分流规则得把这个域名判给节点,域名还得被正确解析成可用的地址。

任何一道断掉,现象都是「节点是绿的,网页转圈」。这时候继续换节点是纯粹的浪费时间,应该转去检查规则分流的走向和 DNS 解析与泄漏自查,或者直接按已连接却打不开网页的三条线索逐条验证。

小结#

延迟数字只回答一个问题:这条路现在通不通、响应快不快。带宽、丢包、长连接存活时长,它一概不管。选节点前先确定用途,再用二十分钟的真实负载测试替代反复点测速按钮,结论会稳定得多。策略组能省掉日常切换的麻烦,但也会掩盖节点长期失效的事实,定期手动全量测一次是必要的。最后别忘了把倍率折进账里——最快的节点和最划算的节点,往往不是同一个。