这篇只管「自动测速」，不管代理模式怎么走流量

「Clash Verge Rev 自动测速怎么配稳」是导入订阅后很常见的一类问题：Clash Verge Rev界面里明明是规则分流，却仍感觉节点在「自顾自乱跳」——游戏 ping 抖动、直播平台隔几分钟卡一下，甚至视频会议中途重连。排除了 DNS、TUN、系统代理等大头之后，值得你单独盯一页配置：mihomo内核里proxy-groups中url-test这一类自动测速组的interval、tolerance与lazy，以及看不见的测速 URL是否合理。

本站已经有一篇从界面出发的总览：《Clash Verge Rev Windows 代理模式与日志》，讲的是规则与全局如何切换、日志怎么读——本文不把那些按钮再讲一遍。《Clash 规则详解稿》里虽然也点到策略组类型，但并没有把url-test这一组旋钮拆成可分步落地的短文。本篇只做这一件事：在 YAML 或通过 Clash Verge Rev 的覆写 Patch把url-test调成「稳」，并让你知道何时该换测速地址，何时干脆改成手动 select。

先对齐概念：什么是 url-test

订阅模板里常在 proxy-groups 下放多种类型：select（手动）、url-test（延迟择优）、fallback（容错链）、load-balance（哈希分摊）等。你看到的「节点列表 + 每隔一会儿当前选项会变」，多半就是有组的 type 写成了 URL-TEST——内核会对组名单中的若干节点，按配置的interval周期向url所指的健康检查地址发包，比较延迟并选出当前最优。

这套机制的前提是「对测速目标的最优近似于对你真实站点最优」。CDN 多出口、 QUIC、区域调度都会打破这个近似：于是你会遇到「延迟数字好看，油管仍转圈」或「一局游戏半程突然换跳板」。这不是界面坏了，而是优化目标与你的业务链路不一致。所以从工程角度，我们应同时调时间维度（多久测一次）、决策维度（差多少毫秒才值得换）、启动维度（是否要惰性延后首批探测）、以及空间维度（探测 URL 与真实访问是否同源同路径）。

interval：测得越勤，并不等于越聪明

interval控制两轮健康检查之间的最小间隔（具体单位以你当前mihomo版本的文档为准，常见写法为秒级整数）。过小会让客户端与节点两侧都忙于握手与探测，且在延迟本身抖动的蜂窝或跨洲链路上更容易出现「分数噪声」驱动的频繁换位；体感上就像是有人在后台每隔几秒替你按一次一键测速并把当前节点改成另一个「看起来快一点点」的出口。

务实调参可以从放大 interval起步：先在可接受的重选延迟下放慢轮询，观察策略组抖动是否明显缓解。比如你主要跑长会话（直播拉流、实时对战、远端桌面），更希望「十几分钟里出口不变」，那就不要把 interval 压得比你的心理容忍区间还激进。等与路径相关的其它因素（Wi-Fi 漫游、家宽晚高峰）叠加时，偏小 interval 会将环境噪声成倍放大。

反过来，如果你在「节点大批量阵亡」的出口环境工作，过大的 interval 又会让切换滞后：坏线挂了半天才发现。折中做法是对不同策略组区别对待：给「兜底自动组」略短的 interval，对你手动盯盘的主力「媒体手动组」用 select；对大范围池子的 url-test，用更佛系节奏配合下面的 tolerance。

优先级建议：先 interval（先把「测得太勤」这一关掐住），再tolerance（再给「差一点也要换」加门槛），最后再考虑lazy是否与你的规则命中模式匹配——否则容易一上来就误判为「节点质量问题」。

tolerance：给「相差无几」套上滞回，专治来回横跳

仅有interval放慢，有时仍挡不住「A 一百零八毫秒、B 一百一十毫秒」这种交替占优。tolerance字段正是为此设计的滞回带：可把「新节点要好过当前节点足够多的余量」作为换桩条件（具体阈值语义以实现版本为准——要点是存在一个不为零的比较缓冲）。当你把tolerance从过小调到合理偏大，往往能立刻看到面板里当前节点的文字不再闪烁式切换，长连接的体感稳定度会好很多。

但要注意tolerance不是越大越好：放得过大时，真的会挂在一条「其实只是勉强还行」的出口上迟迟不换，适合你已确认池内延迟分布扁平方可；若在「一条彻底堵死、另一条明显空旷」的环境里又过大，会放大切换迟钝。实战中常见的节奏是：把抖动止住以后，再根据晚高峰抽样微调，宁可略迟钝也不要对直播链路频繁换跳板。

lazy：减少「没人用我也在测」的负担

lazy（在支持该字段的版本中）常与「策略组是否真的被rules用到」相关联：对某些模板来说，惰性选项意味着在该组未被实际命中前，延后或跳过激进的探测，从而削减启动后与大规模规则集并行时的探测风暴——这对低配笔记本、虚拟机或同时要跑虚拟机桥接场景的Windows用户尤其友好。

lazy 并不等于「不测速」，而是把一个「全局合唱」调成「需要的时候再独唱」。如果你在启动瞬间看到 CPU 瞬时飙高或大量并发握手，而它恰好与大批量 url-test 同步出现，就可以把 lazy 视作诊断线索之一。与 interval、tolerance联动时，体感改善往往来自三方面叠加：慢一点、别太敏感、没被点到就别抢着测。

不同订阅生成器、mihomo 小版本之间，字段支持与默认值可能存在差异。以你合并覆写之后的最终 YAML与当前内核兼容矩阵为准；若某项不被识别，优先查内核日志中是否有静默忽略或 YAML 告警，而不要假设「写过就等于生效」。另：修改健康检查对某些敏感网址可能触发频次限制——请自备合规、可被探测的url或由服务商明示的测速 URL。

url：测去哪里，比你看的数字更决定命运

url-test 的url常被模板随意设成一个通用站点或云服务小对象。问题在于：你只验证了「与该 URL 的对话」顺滑，并不等于「你与目标视频网站、游戏中继、办公软件 CDN」的对话走同一跳板、同一拥塞段位。遇到这种情况，第一性修正不是继续拧数值，而是换更接近真实链路或更可代表出口质量的探测对象。

同时留意 HTTPS 连通性之外的细节：过大的探测包、糟糕的地理分布、与你的账号区域不匹配的目标，都会产生「误判最优」。有经验的用户会为不同策略组拆分不同url或在自动组上使用更稳定的官方推荐地址——核心原则是别把测速写成对敏感站点的爬虫式高压访问，这既不合规也不容易稳定。

在 Clash Verge Rev 里用覆写 Patch 改掉订阅默认值

Clash Verge Rev的长处之一，是让我在不手改远端订阅明文的前提下，对本地的proxy-groups片段做补丁式合并：覆写 Patch编辑器里增补或对齐目标组的interval、tolerance、lazy与url，保存后预览「合并后的最终配置」，再重载内核。这样下次订阅例行更新时，少一层手工合并的恐惧。

操作时请牢记name 对齐：你只应修改与界面里显示的策略组名称一致的那一节，而不要复制出一组同名或近似拼错的影子组，轻则 patch 没落上，重则引发合并歧义。Windows用户若同时使用多配置文件，确认当前激活的那份正是你做覆写的那份；否则会陷入「我到底改到哪去了」的典型误区。

YAML 小段示例仅供你在本地校对字段位置（请以你的内核版本为准裁剪字段名与必填项）：

proxy-groups:
  - name: "AUTO"
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
    url: https://your-chosen-healthcheck.example.com/endpoint
    interval: 180
    tolerance: 36
    lazy: true

什么时候别跟 url-test 较劲，改用 select

如果你已经：interval放慢、tolerance加大、换了更贴近业务的url，但长连接仍偶有「被换掉」的毛刺感，这就是该考虑把这一组降级为select并由你手动锁住节点的信号。流媒体账号地区、对战游戏回程、远端桌面恒定 IP 对白名单——这些场景的共性是：可预测的出口比理论上「更快一丁点」的出口更有价值。

另一种典型信号是：测速与实际业务链路严重错位，以至于你在连接日志里看到频繁换出口，却总找不到「哪条延时数字解释得通」。把那一路改成手动并不等于放弃自动化：你可以在外层再放一个低频 url-test，仅做「离线池粗筛」，而对用户展示的那一组 select 永远由你最终决定。

分步自检清单（从快到慢）

  1. 在合并后的 YAML 中找到目标url-test组，记下当前url、interval、tolerance、lazy初值。
  2. 先放大interval到一个让你「体感上不过分吵闹」的值，重载后用一段时间观察抖动。
  3. 再调tolerance止住「相差无几仍要换」的震荡，留意是否出现换线迟钝的新问题。
  4. 若启动或规则预热期资源占用尖刺明显，检视lazy与你的版本、模板是否合拍。
  5. 若数字与体验长期背离，优先替换url为更稳妥或更贴合业务的探测。
  6. 仍不稳：对该业务链路改select锁定节点，并把自动筛迁到外层低频组。

常见问题

问：为什么我一点击别的策略组，自动组就跟着变？ 有时是上游配置的嵌套引用或 UI 刷新了延迟列；核心是观察mihomo在长连接会话中是否仍周期性换出站。若确有周期，回到interval 与 tolerance。

问：proxy-groups 很多，逐个改太累了怎么办？ 先做分组优先级：只对「承载了直播、游戏出口」的那两三个组精调，其它保持订阅默认或通过模板统一补丁。

问：和 TUN／系统代理有关吗？ TUN只是接管路径不会改变 url-test 的择优逻辑本身；但在TUN下长连接更明显暴露换桩毛刺。《TUN 指南》仍建议并联阅读。

小结

Clash Verge Rev上的「自动乱跳」往往不是玄学，而是url-test在时间轴与决策阈值上对健康检查噪声过于敏感，再配上与业务链路脱节的url，共同制造出策略组抖动。把interval、tolerance、lazy按「先放慢、再加滞回、再谈惰性」的顺序收敛，并结合覆写 Patch固定在本地proxy-groups上，就能把mihomo的自动择优从「一惊一乍」调回稳中求进；实在不行，就请大胆把关键链路换回select，用可预测胜过毫厘必争。

一些闭源加速软件把自动测速与节点切换封装成黑盒：你看不到interval阈值，更无法在不健康检查 URL与抖动参数之间做逐项对照——一旦直播卡了，你只能反复「换节点玄学」。另有一些年代久远的图形外壳仍停留在旧内核语义上，与新版本mihomo在proxy-groups字段上的兼容性参差不齐，轻则忽略字段，重则默默回退默认值。Clash路线的优势在于：配置可读、补丁可叠加、内核开源节奏清楚；配合活跃的mihomo 客户端诸如Clash Verge Rev，你能把本篇这类「单点旋钮」真正落到YAML 与 Patch上，而不是停留在界面迷信。想了解各平台官方分发与版本说明的用户，可参考本站聚合的下载指引页面。

→ 立即免费下载 Clash，开启流畅上网新体验