Clash Verge 中如何配置自动测速并选择延迟最低的节点？

一、先搞清楚：Clash Verge 的自动测速到底在哪一层工作

在 Clash Verge 里做自动测速，本质上不是「打开一个开关」，而是把某个代理组声明成 url-test 类型，让内核按照固定间隔去请求一个轻量探测地址，再把延迟最低的那一个设为当前出口。理解这一句，后面所有参数——探测地址、检查间隔、容差——就都有了明确的归处。

这里有两个名词需要先对齐。代理组（Proxy Group）是配置文件里的一组节点集合，它会作为一个整体出现在代理页面上，你选中的其实是这个组，而不是组里的某一个节点。测速在 Clash 生态里通常指两件事：一是界面上的「一次性延迟测试」，点一下把组内所有节点挨个探一遍、显示数字；二是内核的「周期性健康检查」，它会按 interval 自动重跑，并据此决定切换。前者只是给你看的，后者才会真正改变出口。

很多人的困惑就出在这个分界线上——点了测速按钮，看到某个香港节点数字最低，但实际流量并没有走它。原因是那个组如果是 select 类型，测速结果就只是展示，选择权仍然在你手上；只有 url-test 类型的组，才会把测速结果直接转成切换动作。

版本前提：原 Clash Verge 项目已经归档停止更新，目前社区里仍在维护的延续版本是 Clash Verge Rev，两者界面高度相似。本文描述以你当前实际安装的版本为准，如果某个菜单名称对不上，说明你的版本与示例存在差异，不影响配置逻辑本身。

二、三类节点选择方式：先选对类型，再谈参数

在动手改配置之前，值得先花两分钟确认自己到底需要哪一种策略。Clash 家族里最常见的代理组类型有三种，它们解决的是完全不同的问题，混用往往带来不必要的麻烦。

select：确定性强，但需要人来维护

手动选择的组不会自动切换，你点谁就是谁。它的价值在于可预期——今天走香港，明天还是香港，出口 IP 相对稳定。适合有固定落地需求的场景，比如某些服务对登录地区敏感，或者你正在做需要稳定出口的调试工作。代价也很直接：延迟劣化时它不会自救，节点挂了你得自己发现。

url-test：自动测速的标准答案

这是本文的主角。内核按 interval 周期性地向 url 指定的地址发起探测，记录每个节点完成请求所需的时间，然后把最快的一个设为组内出口。当你把这个组设成主策略组的成员时，实际流量就会跟着它走。

需要注意它的行为特征是「趋低」而非「最优」——它优化的是到探测地址的往返延迟，不直接等于带宽或稳定性。一个延迟很低的节点可能刚好在探测瞬间网络空闲，下载大文件时未必表现最好。这属于方法论上的固有局限，不是配置错误。

fallback 与 load-balance：容易被误用的两个选项

fallback 是按列表顺序做可用性判断，第一个能通的就用，它关心的是「有没有」，不是「快不快」。适合主备结构，比如一条专线加一条备用线路。load-balance 则把请求分散到多个节点上，追求总吞吐或分摊压力，不会盯着单个节点的延迟看。

经验上，把 load-balance 当成「自动测速」来用是一个常见误区：它会让出口 IP 在多个节点之间跳变，对需要会话连续性的服务并不友好。

三、决策树：你的场景该不该开自动测速

与其照抄一份配置，不如先回答三个问题，答案会直接指向结论。

1. 你的节点之间是同质的吗？如果都是同一地区、同一条线路的多个入口，自动测速收益明显；如果一个是香港、一个是美西、一个是日本，那你需要的是按用途分组，而不是让延迟替你做业务决策。
2. 你介意出口 IP 变化吗？如果某个服务的登录态会因为 IP 变动而失效，自动切换反而制造问题，这种情况下 select 更合适。
3. 你的节点按流量计费吗？探测本身流量极小，但间隔设得过短会持续产生连接，按量计费时应当把 interval 拉长一些。

三个问题都指向「节点同质、不介意切换、不按量计费」，那么 url-test 就是你的默认选择。只要其中一条相反，就应该往下再想一层——是把它降级为备用组，还是干脆用手动组加定期自检。

四、桌面端操作路径：Clash Verge 没有手机版

Clash Verge 是桌面客户端，官方发布的安装包覆盖 Windows、macOS 与 Linux 三个平台，没有官方的 Android 或 iOS 版本。如果你在手机上看到同名应用，那通常是第三方套壳或名称相近的另一个项目，不建议按本文步骤对照。

最短路径：先做一次性测速，确认节点是活的

打开 Clash Verge 后，左侧导航栏进入「代理」页面。页面上方通常有一排工具栏图标，其中包含延迟测试入口；部分版本也会在代理组卡片上直接提供测速按钮。点它，内核会对当前组内的节点依次发起探测，稍等片刻就会出现延迟数字或超时标记。

这一步的目的不是选节点，而是排除最基础的问题：如果整列都是超时，那么后面配置得再漂亮也不会生效，应该先去查订阅是否过期、内核是否启动、系统代理是否开启。不同版本的图标位置和样式有差异，请以你实际界面上鼠标悬停后出现的提示文字为准。

进阶路径：改配置文件而不是改界面

Clash Verge 的图形界面主要面向日常切换，真正的代理组定义写在配置文件里。稳妥的做法是在「配置」页面找到当前订阅卡片，通过其上的编辑入口打开配置文件，或者在文件管理器中定位到配置目录手工编辑，具体路径因版本与安装方式而异，请以界面提示的目录为准。

修改订阅文件有一个绕不开的问题：订阅更新会覆盖你的改动。多数维护版本提供覆写或合并机制，允许你把自定义的代理组写在一个独立的片段里，由客户端在生成最终配置时合并进去。不同版本对这套机制的叫法不同，请以「配置」页面中实际出现的条目名称为准。如果找不到类似入口，也可以退而求其次，使用本地配置文件（Local 配置）而非远程订阅，代价是需要手动同步节点。

五、一份可复现的 url-test 代理组写法

下面这段配置展示了自动测速组的最小结构。请把它放进配置文件的 proxy-groups 段落中，并把 proxies 里的名字换成你自己订阅中真实存在的节点名。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 新加坡-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

逐行解读一下。name 是这个组对外显示的名字，也是你在规则里引用它时用的标识；type 决定行为类型；proxies 是候选池，顺序在 url-test 里不重要，因为它只按延迟排序；url 是探测目标；后面三项控制检查节奏与切换灵敏度。

最容易出错的地方是节点名。它必须与 proxies 顶层列表中定义的名字逐字符一致，包括空格、连字符和中文。少一个字符，客户端在启动时就可能报「proxy not found」类的错误，或者该组显示为空。排查方式很直接：在代理页面上确认这些名字确实存在，再回配置文件里逐个比对。

另一个常见问题是引用关系。如果某条分流规则指向的是策略组 A，而 A 里又套了自动选择组，那么真正的出口由最内层决定。改动后建议在「连接」页面观察一条实际连接经过的策略链，确认它确实落到了自动选择组上。

六、四个关键参数：每一项都在做取舍

url：探测地址决定了测出来的是「哪条路的延迟」

探测请求是经由节点发出的，所以你测到的其实是「本机 → 节点 → 探测地址」这条完整链路的往返时间。选择探测地址的原则有三条：返回体尽可能小、支持快速返回、可长期访问。社区里长期被广泛使用的两个地址是 http://www.gstatic.com/generate_204 和 http://cp.cloudflare.com/generate_204，它们都会返回一个空响应，开销极低。

这里有个容易被忽略的边界：探测地址本身的可用性会影响测速结果。如果某个地址在某些地区被干扰，你会看到大量超时，而这并不代表节点有问题。验证方法很简单——把 url 换成上面另一个地址，重新测一次，如果超时大幅减少，那就是探测目标的问题，不是节点的问题。

interval：检查频率与资源开销的平衡点

内核文档中 interval 的默认取值是 300 秒，也就是五分钟检查一轮。这个量级在绝大多数场景下是合适的：既能感知到节点质量的变化，又不会因为过于频繁的探测产生额外负担。

把它调小会带来什么？切换更及时，但节点数量多的时候会有更多并发探测连接，低性能路由器或老旧设备上可能出现可感知的瞬时卡顿。把它调大呢？节点劣化后你要忍更久才自动换掉。经验性观察是，明显短于一分钟的间隔在常规使用中很少带来可感知的收益，反而让探测流量和连接数上升。到底设多少，取决于你的节点是否按量计费、设备性能如何、以及你对延迟波动有多敏感。

tolerance：防抖的核心，也是很多人配错的参数

容差的意思是：只有当新节点的延迟比当前节点低出超过这个阈值时，才发生切换。内核文档里给出的默认量级是 50 毫秒。它的作用是抑制来回抖动——如果两个节点延迟只差几毫秒，网络波动就会让内核反复切换，每次切换都会重建连接，你感受到的是下载中断、页面重载。

所以 tolerance 不是越小越灵敏就越好。设得太小，切换会变得神经质；设得太大，明明有更快的节点却迟迟不换。合理的取值应当与你的节点池延迟离散程度匹配：如果组内节点延迟普遍接近，容差就该设小一点，否则一个都换不动；如果节点跨度很大，容差可以放宽，因为真正的最优解往往一测就领先很多。

lazy：空闲时不折腾

lazy 开关控制的是「没有流量经过时要不要继续测速」。开启后，只有该组被实际使用时才会触发探测，空闲状态下不做无用功。对笔记本用户来说，这个设置能减少后台活动，对电池和按量计费都更友好。代价是首次使用时会多一次探测延迟，通常不易察觉。

七、场景推演：40 个节点该怎么组织

假设你有一份订阅，包含 40 个节点，分布在香港、日本、新加坡、美国几个地区，平时主要用来看视频和查资料。直接把 40 个节点塞进一个 url-test 组，功能上没问题，但有两个实际影响：一是每次测速要跑 40 次探测，界面上的数字刷新会慢一些；二是这个组的延迟离散度很大，容差很难设得恰到好处。

更清晰的做法是做两层结构。底层按地区分成三到四个 url-test 组，比如「香港自动」「日本自动」「新加坡自动」，每组只管同地区的十几个节点，容差可以设得比较小，因为同地区节点延迟本来就接近，小容差能选出真正的优等生。顶层再放一个组，成员是这三个自动组的名字——注意，代理组的成员可以引用另一个代理组，这是 Clash 配置里一个很实用的特性。

顶层这个组该用什么类型？如果你希望它也在地区之间自动择优，那就继续用 url-test，此时候选只有三个，探测开销很小，切换决策也更稳。如果你有明确的地区偏好，比如希望优先日本、日本不行再退到新加坡，那就用 fallback 按顺序排列，把「优先级」这件事显式表达出来，而不是交给延迟去猜。

反过来说，如果你只是临时用几天，节点也不多，那么单层 url-test 完全够用，为了分层而分层反而增加维护成本。配置的复杂度应当与使用周期和节点规模匹配。

八、故障排查：五种现象与对应的验证动作

排查的原则是「先确认现象属于哪一层」。下面按现象组织，每条都给出可复现的验证步骤，避免凭感觉改配置。

现象一：整列节点都显示超时。可能原因包括订阅已过期、内核未正常运行、探测地址在当前网络下不可达。验证方式：先把 url 换成另一个公共探测地址重测；如果仍然全红，打开「日志」页面看内核是否有报错输出。处置上，优先解决连接层面问题，不要急着调参数。

现象二：配了 url-test 但出口从不变化。常见原因是这个组没有被上层策略引用，规则命中的是另一个组。验证方式：在「连接」页面查看一条活跃连接的策略链，看它最终落在哪个组。如果链路上游是个 select，而它被固定在某一个具体节点上，那么下层再智能也用不上。

现象三：节点延迟数字频繁跳动。在多数情况下这是正常的，因为 TCP 握手和 TLS 建立的时间受瞬时网络状况影响。真正值得关注的是趋势而非单次读数。如果想减少误判，可以适当提高 tolerance，让切换决策更保守。

现象四：切换瞬间连接中断。这是切换行为的固有代价，不是故障。正在进行的长连接（比如大文件下载或实时会话）会因为出口变化而重建。如果你的工作负载对连接连续性要求高，应当考虑用 select 固定出口，或者把关键业务单独走一个不参与自动切换的组。

现象五：测速时短暂卡顿。节点数量多、间隔短的情况下，并发探测会产生一批短连接。在性能有限的软路由或老旧设备上，这可能表现为短暂的响应迟滞。验证方式是临时把 interval 调长一个量级再观察，如果迟滞消失，说明问题出在探测频率上。缓解办法是分组降低单组节点数量，或开启 lazy 让空闲时不探测。

九、验证与观测：怎么证明自动测速真的在工作

配置完不看效果，等于没配。有三处信息值得定期查看，它们分别对应不同的验证目标。

第一处是「代理」页面本身。自动选择组当前选中的节点通常会有高亮或标记，你可以对照它和测速结果是否一致。如果组内明显有一个节点延迟低很多，但选中的却是另一个，那就要检查容差是不是设得太大了。

第二处是「连接」页面。它展示当前所有活跃连接经过了哪些策略、最终落到哪个节点，这是判断分流规则是否按预期生效的最直接依据。当你怀疑「自动测速没起作用」时，先看这里，多数疑问当场就能解答。

第三处是「日志」页面。内核在切换节点、探测失败、配置解析出错时都会留下记录。日志的详细程度通常可以在设置中调整，排查期间可以临时调高，事后调回，避免长期占用磁盘。

如果你想知道实际出口落在哪个地区，一个不依赖客户端的验证方式是用浏览器访问任意一个显示访客 IP 与归属地的公开查询服务，看返回结果是否与预期节点所在地区一致。这个动作简单、可重复，适合在切换策略后做一次确认。需要提醒的是，这类查询结果本身受限于服务商的数据库准确度，只作参考。

十、适用与不适用：清晰的准入条件

把边界写清楚，比多讲十种技巧更有用。以下判断标准可以直接对照你的情况。

适合开启自动测速的情况：节点数量在十个以上且地区相对集中；节点延迟会随时间波动，手动挑选成本高；使用场景以网页浏览、视频观看这类对连接连续性要求不高的活动为主；订阅节点会不定期变动，你不想每次都手工调整。

不适合、或者应当谨慎的情况：业务依赖固定出口 IP，比如某些服务会因登录地变化而要求二次验证；节点按流量严格计费，且你对任何额外请求都敏感；你正在做需要长时间保持连接的传输；节点之间并非同质，而是对应不同用途，此时按用途分组比按延迟择优更合理。

还有一条容易被忽视的边界：自动测速优化的是到探测地址的延迟，不承诺带宽或丢包表现。如果你的主要痛点是看视频缓冲慢，那可能是带宽问题而非延迟问题，换节点未必能解决，先确认瓶颈在哪一层再动手。

十一、最佳实践检查表

• 动手前备份当前配置文件，改动后出现异常可以快速回退。
• 先做一次手动测速，确认节点池整体可用，再谈自动策略。
• 节点超过十个就考虑按地区分组，避免单组过于臃肿。
• interval 不要为了追求「实时」而设得过短，明显短于一分钟通常没有必要。
• tolerance 要与节点延迟的离散程度匹配，没有万能值。
• 笔记本用户可以开启 lazy，减少空闲时的后台探测。
• 探测地址准备两个备选，遇到大面积超时时先换地址验证。
• 配好后到「连接」页面确认一次实际策略链，别只看代理页面的显示。
• 定期翻一下日志，早期发现订阅或节点层面的异常。

十二、常见问题解答

十三、小结：把决策留给规则，把选择留给内核

回到最初的问题，Clash Verge 里的自动测速其实是一个「声明式」的配置动作：你不需要每次手工挑节点，只需要在配置文件里把某个代理组声明为 url-test，再为它设定合理的探测目标、检查间隔和容差，剩下的交给内核周期性地完成。真正决定体验好坏的，往往不是有没有开这个功能，而是参数是否匹配你的节点分布和使用习惯。

下一步建议按这个顺序推进：先做一次手动测速确认节点池可用；再用单层 url-test 跑通流程，验证切换确实生效；等节点数量增加、延迟跨度变大之后，再考虑按地区拆分并引入上层策略组。每改一次配置，都回到「连接」页面确认一次实际策略链，这个习惯能帮你省下大量猜测时间。

最后提醒一句：不同维护版本在界面文案和配置覆写机制上存在差异，本文涉及的所有界面路径都应以你当前安装版本的实际情况为准。功能逻辑是稳定的，界面是会变的。