Clash url-test 策略组怎么设置？测速 URL、间隔与健康检查逐步配置

url-test 在做什么：自动测速与健康检查是一件事的两面

可以把 url-test 理解成「对一组候选代理周期性做一次极小流量的连通与延迟采样」，然后根据结果Pick 一个当前更合适的出口。它既是用户口中的「自动选节点」，也是事实层面的健康检查：探测失败或异常慢的成员会被降权，合格者才有机会被选中。与手动 select 不同，url-test 会替你在后台维护这张「临时排行榜」；与 fallback 也不同，fallback 更像按固定优先级寻找第一个能用的节点，而不是在多个可用节点里找当下延迟更好的那个。

因此在路由里引用策略组时，规则的写法依然是把连接交给某个 proxy-groups.name，例如 MATCH,自动 或 GEOSITE,google,自动。真正决定「自动」二字如何工作的，是你在这个组里把 type 设成了 url-test，以及你为探测配置的 url 与 interval。若你对整条分流链路还不熟，建议先读《Clash YAML 规则分流完全指南》，再回到本文专注微调 url-test。

最小可用 YAML：proxies、url、interval 三角

下面是一段在多数 Meta（mihomo）系内核下可直接改名的模板：proxies 列表里必须出现你在 proxy-groups.proxies 中引用的每一个名字，它们通常来自订阅解析；url 是探针地址；interval 是探测周期间隔，单位秒。没有合理的 url，探测就无法对齐你的预期；没有合理的 interval，要么反应迟钝，要么过于吵闹。

proxy-groups:
  - name: "自动"
    type: url-test
    proxies:
      - "香港 A"
      - "新加坡 B"
      - "日本 C"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

把 name: "自动" 换成你自己在规则里习惯用的组名即可。注意不要写成与某个节点完全同名却忘了在顶层声明该节点，否则加载配置时会报引用错误。订阅若会改节点名，优先让这一组引用「稳定的别名策略组」或整理订阅覆写，否则 url-test 会在每次更新后失去目标。

url：测速地址怎么选才公平

好的探针应当满足：对你绝大多数候选节点都可访问、TLS 握手路径正常、响应体尽量小、尽量少的重定向与异形中间页。社区里最常用的 generate_204 一类地址，本质是「只要能快速返回预期状态码，就能代表链路大致可用」。若你用的是自建探针，请确保证书与 SNI 正常，避免部分节点因证书校验策略不同而被误判。

不建议拿「大型门户首页」或「需要复杂 Cookie 的页面」当探针：页面体积大、波动大，会让延迟统计失真，也会浪费你本就不富余的套餐流量。若运营商或目标站对探针域名的路由与真实业务域差异很大，也可能出现「探针很好看、业务站点却不理想」的错位——这时要回到分流日志看真实连接到底走了哪条规则与哪个策略组，而不是只信探针数字。

interval：多久测一次更合理

家用场景下，三分钟到十分钟（180–600 秒）是常见区间：足够感知节点阶段性拥塞，又不会把测速本身变成流量与电池消耗大户。若你设到几十秒一档，在节点多、订阅大的配置里，等效于是对整个列表做高频压测，有时还会触发对端限速或异常。若你设到数小时，又可能在短时间内遭遇「节点已坏但迟迟未切换」的体验落差。最终请以「你对故障恢复速度的容忍度」与「设备续航」折中。

tolerance 与 lazy：抑制乱跳、降低无效探测

tolerance 常被比作「切换滞回」：当新候选比当前在用节点快，但快的幅度没有超过容忍值时，可以继续保持现状，避免在两台差不多快的节点之间来回切。网络测速本身带有抖动，尤其在 Wi-Fi 与移动蜂窝之间切换时，一个没有 tolerance 的 url-test 很容易把抖动当成「实力变化」，于是你能在 GUI 里看到选中项不断闪动。

起步可以尝试数十毫秒量级，再根据主观感受上调或下调。若你发现「明明该切却不切」，可能是容忍过大；若「图标总在换」，优先增大容忍，其次再检查探针是否稳定。两者配合比单纯调 interval 更能治根。

lazy（懒加载）则解决另一个问题：当某个 url-test 组在当下根本没有被任何活跃连接使用时，是否仍需按周期探测。开启 lazy: true 通常意味着「用到了再勤快测，不用就别吵」，对笔记本与手机更友好。反过来，如果你希望即使闲置也维持一张最新的延迟表，以便用户一切过去就立即是绝对最优，可以把懒加载关掉，但这会以电量与后台流量为代价。

图形客户端里怎么配：对着 YAML 逐项找

并不是所有人都想直接编辑原文。以常见的 Clash Verge 系为例，策略组详情页往往能看到类型（url-test）、成员列表、探针 URL、间隔与懒加载等开关。操作原则是：先在脑里对应到 YAML 字段，再在 GUI 里改同名项，最后「重新加载配置」或让客户端自动热更新，观察日志是否开始按新周期打印探测相关记录。

如果你使用配置文件分包、合并或远端覆写，注意 GUI 有时编辑的是其中一层，而运行时又被另一层覆盖。排查方式是导出最终配置或在日志中搜索该策略组块，确认 interval 与 url 是否真的变成你期望的值。对内核版本的差异，可参考Meta 内核升级一文，避免旧内核不支持某些字段却静默忽略。

与「健康检查」相关的用户感知，除了 url-test，还可能涉及 DNS 与健康探测交互：例如 Fake-IP 模式下，域名规则与探测域名若解析路径不一致，可能放大「看起来延迟不错、业务站点却偶发失败」的错觉。此类问题不在本文穷举，但记住一条：先确认规则命中，再争论节点好坏。

组合用法：嵌套策略组与和 fallback 的搭配

实务中常见模式是：底层多个 url-test 组按地区拆分，上层再用 select 把「港区自动」「新港区自动」收成一张手选菜单。也可以把 fallback 放在 url-test 之后做兜底：当优选路径集体失效时，退回一条固定备用线路。关键是不要让多个自动组同时对完全相同的候选列表做高频探测，否则你会得到翻倍的探针流量。

另一种误区是把 url-test 与「订阅里的原生测速」混为一谈：订阅刷新时的节点延迟测试，与运行期 url-test 是两套节奏。前者帮助你初次筛选名称，后者决定你日常真实跑业务时的出口。若你发现「订阅里快、用起来慢」，往往要独立检查业务域名规则、UDP 需求、TLS 指纹与握手路径，而不是继续缩短 interval。

不稳定时怎么查：从探针、容忍与规则三线并行

第一步，确认策略组成员名与订阅一致且节点本身在线；第二步，临时把 tolerance 提高、把 interval 适度拉长，观察是否只是统计抖动；第三步，换一个更中立的探针域名或你自建的可控探针，排除「探针域对你部分出口不公平」的情况；第四步，回到日志核对 matched 规则，确保你以为走「自动」的连接，没有在中途被更靠前的规则送去别的组。

若仅有某一类业务不行（例如游戏 UDP、视频会议），而探针 HTTP 永远好看，十有八九不是 url-test 单一参数能解决的，而要检查协议支持、端口、TUN 模式、以及是否需要为特定进程单独分组。此类「专项分流」仍建议与规则总览教程一起阅读，避免头痛医脚。

• 现象：选中节点每秒都在变 → 优先增大 tolerance，其次放缓 interval，最后换探针。
• 现象：很久不切死节点 → 检查 lazy 是否让你「未使用时几乎不测」，以及失败判定是否过于宽松。
• 现象：电量掉得快 → 多层 url-test 叠加短间隔是常见祸首，合并探测目标或提高间隔。

写在最后

写得再好的 url-test，也只对你提供的探针负责；它不能替你了悟整条规则表。把 interval、tolerance、lazy 调成一组顺眼的数据后，最值得投资时间的仍是：规则是否有漏网、DNS 是否可信、以及节点协议是否与业务匹配。把这三件理顺，你反而可以把自动选路调得更「迟钝」一点，换整体稳定。

市面上不少「轻量化」代理工具要么压根不提供可编程的策略组与健康检查，要么把自动选路藏在封闭逻辑里，出了问题只能重装或等更新，很难像 Clash 系这样把参数摊在 YAML 里逐条审计；另一些工具虽然支持订阅，但对合并、覆写、日志与版本升级的工程化支持不足，长期使用会在多设备同步与排错成本上吃亏。ClashNote 更推荐围绕 Meta 生态选择维护积极、能把配置权还给用户的客户端——自动选节点这件事，**可控**往往比「傻瓜一键」更省力。

更多路由与分流基础见《Clash YAML 规则分流完全指南》；需要按日志反查命中规则时，可对照分流调试一文。全部文章目录在技术专栏。