Clash Verge 的代理组自动选择最低延迟功能如何设置？

一、先看结论：自动选择最低延迟靠的是 url-test 组

在 Clash Verge 的界面里，其实找不到一个叫「自动选择最低延迟」的开关。你真正要动的东西在配置文件里：一个 type 为 url-test 的代理组（proxy group）。客户端做的事情只是把这个 YAML 结构渲染成代理页上的一张卡片，卡片里每个节点后面的毫秒数字，来自内核发出的 HTTP 探测请求。把这一点想明白，就不会在 UI 里翻来翻去找一个并不存在的按钮——Clash Verge 代理组自动选择最低延迟，本质是配置写法问题，不是界面开关问题。

这个组的运行逻辑可以拆成三步。内核按 interval 指定的周期，对组内每个节点各发一次轻量探测请求，记录往返耗时；耗时最低的节点成为当前出口；只有当新节点的延迟比当前节点低出超过 tolerance 设定的差值时，才会真正切换。它解决的是节点质量随时间漂移的问题——你上午手动选的节点可能晚上就堵了，而人不会盯着面板一直换。换句话说，这套机制把「持续测量」和「谨慎切换」拆成了两件事，前者交给定时探测，后者交给死区判断，两者缺一，自动选择要么迟钝、要么抖得厉害。

边界最好在动手之前就划清。探测得到的延迟，是单次 HTTP 请求的耗时，它既不代表带宽，也不代表丢包率，更不代表 UDP 质量。一个延迟 60 毫秒但带宽只有几兆的节点，会稳定赢过延迟 90 毫秒却能跑满带宽的节点。所以这套机制天生适合网页浏览、即时通讯、API 调用这类对响应敏感的场景，而不适合大流量下载或长时间视频。理解了这条边界，后面的参数调整才有明确方向：你调的是「响应有多快」，而不是「线路有多好」。

二、版本演进：为什么老教程的参数对不上

Clash Verge 早期版本基于 Clash 内核，能用的代理组类型和参数字段都相对有限。原项目归档之后，社区分支 Clash Verge Rev 接过维护，并在后续版本中把内核切换为 mihomo（即 Clash.Meta 系）。这不是换个名字那么简单：内核决定了配置文件能认哪些字段。同一份 url-test 配置，在旧内核下可能只认 type、url、interval 三项，而在新内核下还能识别 tolerance、lazy、expected-status、max-failed-times，以及按正则批量筛选节点的 filter 系列字段。字段变多意味着可调空间变大，也意味着照抄旧模板的风险变高——多写一个旧内核不认识的键，轻则被忽略，重则在校验阶段直接失败。

判断自己手里是哪种，最直接的办法是打开设置页的版本信息区域，看内核一栏标的是 Clash 还是 mihomo。也可以做个小测试：在配置里给某个 url-test 组加一行 tolerance，保存并重载配置，如果配置校验没有报未知字段、组仍能正常显示延迟数字，就说明当前内核认这个字段；反之校验阶段就会提示字段不被识别。这个测试的好处是可逆、无副作用，验证完删掉那行即可恢复原状。

从旧版迁移过来的读者，如果配置里只有 type: url-test、url、interval 三行，不改也能跑，只是行为上少了一层约束。没有 tolerance 兜底时，延迟接近的两个节点可能在每轮探测后互相抢出口，表现出来就是出口 IP 频繁变化，某些需要会话保持的网站会反复要求重新验证。加一个几十毫秒量级的容忍值，通常能明显减少这类抖动——这是定性观察，具体幅度因节点质量分布而异，可以用第七节的验证方法自行复现。

三、参数逐项拆解：四个字段决定它稳不稳

下面四个字段各自负责一面，缺一个都会让行为偏掉：url 管「测得准不准」，interval 管「发现得早不早」，tolerance 管「切得稳不稳」，lazy 与容错字段管「资源省不省、失败怎么判」。分开看每一项都不复杂，组合起来才决定体感。

3.1 url：探测地址选什么

做法是填一个稳定返回 HTTP 204 的轻量地址，社区模板里常见的是 generate_204 这一类。原因是探测只需要一个「通不通 + 耗时多少」的信号，页面越大、重定向越多，测出来的数字越偏离真实可用性。边界在于：这个地址必须能被你的节点正常访问，如果地址本身存在 DNS 解析问题，全组会一起显示超时，而节点其实是好的——这时候排查方向应该放在 DNS 和探测地址上，而不是急着换节点。

3.2 interval：多久测一次

多数模板给出的值在 300 秒上下，实际按你的节点波动规律调整，以所用内核版本的文档说明为准。间隔太短，探测请求本身会变成负担，节点数量多的时候尤其明显；间隔太长，等你发现节点劣化时已经用了一段时间。经验性观察是：日常办公场景保持默认量级即可，跨境会议、直播这类对连续性要求高的场景可以适当缩短，但要接受后台探测流量相应增加。也可以换个角度想：节点数乘以探测频率，大致就是后台请求量，节点池越大，缩短间隔的代价越高。

3.3 tolerance：切换的死区

这个字段最容易被忽略，却最影响体感。它的含义是「新节点要比当前节点快出多少，才值得切换」。设得太小，两个延迟只差几毫秒的节点会互相抢出口，已经在传输的连接被反复重建；设得太大，明明有更快的节点也不切，自动选择就退化成手动固定。建议先给一个中间值（几十毫秒量级），跑一天观察再微调。注意它是绝对值不是百分比，当整组延迟普遍偏高时，同样的死区带来的相对影响反而变小；反过来，整组延迟都很低时，几十毫秒的死区就显得相当保守。

3.4 lazy 与容错类字段

lazy 控制的是「没被选中就不测速」，好处是省资源，代价是你点开代理页之前看到的可能是上一轮的旧数字。timeout、max-failed-times、expected-status 属于容错字段，用来定义什么算失败——例如探测返回 200 而不是 204，是否判定为不健康。这些字段在不同内核版本上的支持程度并不一致，改之前先按第二节的方法确认内核，别把配置写成只有新版才认的样子，再拿旧客户端去加载。经验性观察是：容错字段宁少勿多，先把核心四项跑稳，再逐个加，出问题也更容易定位到是哪一行引起的。

四、四种代理组的边界：不是所有场景都该用 url-test

Clash 系内核常见的代理组类型有四种，它们在「谁来决定出口」这件事上完全不同。选错类型，后面参数调得再细也没用。

类型	决策方式	典型适用	主要代价
select	完全手动	需要固定出口 IP 的登录、支付、后台	节点劣化需人工发现
url-test	按探测延迟自动	日常浏览、IM、API	出口会变；延迟不等于带宽
fallback	按列表顺序取第一个可用	主备线路，优先用主线路	不看快慢，只看通不通
load-balance	按策略分发连接	多连接并发、单节点带宽吃紧	同一站点可能来自不同 IP

给一个具体判断：如果你要登录网银或公司后台，出口 IP 一变就可能触发风控，这类流量应该走 select 组而不是 url-test。反过来，如果你每天开几十个网页标签、挂着聊天工具，url-test 带来的收益最直接。fallback 和 load-balance 则更像「线路保障」和「带宽摊薄」两种不同思路，和本文主题是并列关系而非替代关系。

五、操作路径：桌面端三条可达路线

Clash Verge 目前主要面向桌面端（Windows、macOS、Linux），移动端并没有对应的官方客户端，这一点先说明，避免按错平台找入口。桌面端三条路线的差别，主要在于「订阅更新之后配置还在不在」——理解了这一点，选择哪条路就变成了持久性需求的问题，而不是操作难易的问题。

5.1 方式 A：直接编辑订阅配置文件

最短路径是进入「订阅」（Profiles）页面，在对应订阅卡片上使用编辑入口（右键菜单里通常也有「编辑文件」一类的选项），打开 YAML 后找到 proxy-groups 段，把目标组改成 url-test 并补齐参数，保存后重载配置。这条路径最直观，适合只想先跑通一次的人。缺点是订阅一旦更新，文件会被服务端下发的版本整体覆盖，你改的内容就没了。因此它更适合验证想法，而不是长期维护。

5.2 方式 B：全局扩展配置或脚本覆盖（推荐）

Clash Verge Rev 提供了对全部订阅生效的扩展配置入口（不同版本的位置略有差异，可能在订阅页右上角，也可能在设置页的相关区域，请以实际界面为准）。在这里写一段只描述代理组的片段，客户端会在每次加载订阅后把它合并进去。好处很明确：订阅更新不影响你的定制，配置只维护一份。代价是需要理解合并的覆盖关系——同名组会被替换，新组会被追加，写错组名的结果通常是多出一个没人用的组，而不是报错。所以改完最好回代理页确认一次组的数量与名字，这比事后排查要省事得多。

5.3 方式 C：Provider 层覆盖

如果节点来自 provider（节点集合），代理组可以用 include-all-proxies、filter、exclude-filter 这类字段按规则批量纳入，而不必手写节点名。这条路适合节点数量多、且经常增删的情况。边界是：正则写得越宽，越容易把测试节点、过期节点一起纳进来，反而拉低整组表现。示例：如果订阅里混有名称带「剩余流量」「到期」字样的信息型条目，用 exclude-filter 把它们排除，往往比事后手动清理更可靠，具体表达式需按你的实际命名核对。

六、完整示例：把自动选择接进一条真实链路

假设一个常见场景：订阅里有几十个节点，既有亚太低延迟线路，也有远端大带宽线路。用户希望日常网页走最快的，流媒体固定走某条带宽线路，工作后台固定走一条干净出口。可以把 url-test 只用在「日常」这一层，其余用 select 固定下来。

proxy-groups:
  - name: 日常加速
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false
    proxies:
      - 香港-01
      - 新加坡-02
      - 日本-03

  - name: 流媒体
    type: select
    proxies:
      - 远端大带宽-01
      - 远端大带宽-02

  - name: 工作后台
    type: select
    proxies:
      - 固定出口-01

这段配置里，只有「日常加速」是自动的，另外两个组保持手动。规则部分再把对应域名分流到三个组，链路就成型了。这里刻意没有把全部节点塞进 url-test，原因是节点池越大，探测频率越高，后台开销越明显；而且真正需要「自动」的往往只是日常流量那一层。把业务按「能否容忍出口变化」切成几块，比把所有节点交给一个组要清晰得多。

需要提醒的是，上面示例里的探测地址与参数取值属于常见写法，具体以你所用内核版本的文档为准。如果你的网络环境访问该地址本身不稳定，换一个能稳定返回 204 的地址，比反复调 interval 更有效——因为前者影响的是测量准确性，后者只是改变测量频率。

七、验证与观测：三处可看的地方

配置写完不算结束，得能证明它按预期工作。Clash Verge 里至少有三个可观测点：代理页的组卡片会显示每个节点的延迟数字和当前选中标记；连接页能逐条看到每条连接实际命中的是哪个节点；日志页会记录健康检查相关的输出。三者结合，基本能还原出「什么时候切了、切到哪、为什么切」。单看其中任何一个都容易误判，比如卡片上的数字只是测量结果，真正走了哪个节点还得回头看连接记录。

一个可复现的验证步骤：先把 tolerance 设为较大的值，保存重载，观察代理页上当前节点是否长期不变；再把 tolerance 调到很小的值，同样观察一段时间。如果前者稳定、后者出现切换，说明参数确实生效了。这个过程不需要特殊工具，只需要一点耐心，建议在两类场景各测一次（例如白天和晚间高峰），因为节点质量分布在不同时段差别很大。记录下两轮观察的时间与现象，再回头调参时就有据可依，而不是凭印象反复试。

八、故障排查：按现象倒推原因

现象一：组内所有节点都显示超时。可能原因是探测地址不可达、节点本身失效，或者 DNS 解析异常。验证办法是手动切到其中一个节点，用它打开一个普通网页，看是否真的不通；如果网页能开而测速全红，问题更可能在探测地址或 DNS 上。处置方式依次是换探测地址、检查 DNS 设置、最后才考虑换节点——顺序反了，就容易把好节点白白换掉。

现象二：始终停在同一个节点，明显有更快的也不切。先看 tolerance 是不是设得过大，再看 interval 是不是过长，最后确认 lazy 的取值是否让你看到的是旧数据。还有一种容易被忽略的情况：当前节点的延迟确实只比别的低一点点，没超过死区，所以内核判定「不值得切」——这是设计意图，不是故障。

现象三：出口频繁横跳，登录状态老掉。这通常说明 tolerance 太小、interval 太短，或者组内节点延迟高度接近。处置思路是加大死区、拉长间隔，把对会话敏感的服务单独拆到一个 select 组里去，而不是继续在 url-test 上调参。持续高频率切换消耗的是你的使用体验，而不是某个可以靠改数字消除的 bug。

现象四：改完的配置在订阅更新后消失。这是方式 A 的固有问题，不是客户端缺陷，换用第五节的方式 B 即可。现象五：某个组点节点没反应。多半因为它是 url-test 或 fallback 组，本身不允许手动指定出口；需要手选的话，把它改成 select 或另建一个 select 组。这两类现象都不涉及内核 bug，属于「组类型决定交互」的正常表现。

九、不适用清单：这些情况下别开自动选择

• 需要固定出口 IP 的场景：网银、企业后台、有白名单的远程办公。出口一变，风控几乎立刻响应。
• 大文件下载与长时间同步：延迟最低的节点往往不是带宽最高的，自动选择会把流量导向「响应快但吞吐一般」的线路。
• 对 UDP 质量敏感的应用：探测走的是 HTTP 请求，测不出 UDP 的丢包与抖动。
• 有审计或合规要求的环境：出口节点应当可预期、可记录，随机切换会让事后追溯变难。
• 节点数量很少且质量接近时：自动选择的收益很小，反而增加了不必要的探测开销。

这个清单并不是否定 url-test，而是提醒它有一个明确的能力半径。把不适用的流量拆到 select 组，是比调参更省事的做法。判断标准也很朴素：只要某条业务对「出口是否稳定」的敏感度高于「响应是否最快」，它就不该放进自动组。

十、最佳实践清单

1. 先确认内核类型，再决定能写哪些字段，不要照抄旧教程的完整配置。
2. 只让日常流量走 url-test，其余按业务拆成 select 组，减少互相干扰。
3. 探测地址选稳定的轻量返回，别用首页或大页面。
4. interval 保持默认量级起步，观察一天再决定是否缩短。
5. tolerance 从几十毫秒量级开始，宁可先大后小，避免一开始就抖动。
6. 用扩展配置而非直接改订阅文件，保证订阅更新后定制不丢。
7. 改完至少验证一次切换行为，白天和晚间各看一轮。
8. 出现登录掉线时，先怀疑出口变化，再去怀疑节点质量。

这八条并不要求一次全部落地。实际推进时，前两条决定了配置骨架，中间几条属于参数打磨，最后两条是长期的排查习惯——先搭好骨架，再逐个微调，比一上来就追求「最优参数」更容易得到稳定结果。

十一、常见问题（FAQ）

十二、小结与下一步

回到最初的问题：Clash Verge 的自动选择最低延迟，答案不在某个按钮里，而在 url-test 这个组类型和它背后的几个参数上。url 决定测得准不准，interval 决定发现得早不早，tolerance 决定切得稳不稳，lazy 决定资源省不省。四者配合，才有「该快的时候快、该稳的时候稳」的效果。

下一步建议按这个顺序推进：先用扩展配置把组写进去并重载，再观察一天的实际切换行为，最后根据观察结果微调 tolerance。如果发现某些业务因为出口变化出了问题，不要继续在自动组上打补丁，而是把那条业务单独拆成 select 组——边界划清楚，比参数调到极致更有效。这样处理还有一个附带好处：每次出问题都能归因到具体的组，而不是在一个大组里反复试参数。

至于未来趋势，经验性观察是：随着内核版本迭代，代理组可用的字段与筛选能力会继续增加，旧教程与新版参数的差异也会更常见。应对方式并不复杂——升级后先按第二节的方法确认内核类型，再对照官方文档核对字段是否仍被支持，然后用第七节的验证步骤复测一遍切换行为。可复现的验证，永远比记住某一版参数更可靠。