1 为什么需要 URL-Test 与 Fallback
很多用户习惯在客户端里用手动选择（select）固定一个节点：简单直观，但机场线路质量会随时间波动，昨天快的节点今天未必仍快；一旦当前节点被墙、宕机或握手超时，你还要自己切到下一个，打断使用节奏。URL-Test 与 Fallback 正是为解决这两类痛点设计的策略组类型：前者在一组候选里周期性做延迟测试，选出相对更优；后者按固定顺序做健康检查，当前项不可用时自动后移。
二者常配合使用：例如先用 url-test 把「香港若干节点」收敛成一个名为 HK-AUTO 的组，再把 HK-AUTO 作为 fallback 列表的第一项，后面接新加坡备用、最后接 DIRECT 或 REJECT，形成「同区域内自动择优 + 跨区域/直连兜底」的结构。若你尚未把机场订阅转成 Clash 可读的 proxies 列表，可先阅读《订阅转换完全指南：把 SS/V2Ray/Trojan 机场链接转成 Clash YAML》，确保节点名称与下文策略组引用一致。
2 策略组类型速览：别和 DNS 的 fallback 搞混
在 proxy-groups 里，常见类型包括 select（手动）、url-test（按延迟自动选）、fallback（按顺序故障转移）、load-balance（负载均衡）等。本文主角是前两者。另有一处极易混淆：dns 配置里也有名为 fallback 的DNS 服务器列表，用于解析失败或污染检测后的域名解析回退，与代理策略组的 type: fallback 完全不是一回事。若你同时在调 DNS，请 mentally 把「DNS fallback」和「代理 Fallback 组」分开记，避免改错段落。
url-test 关心的是谁延迟更低（多选一）；fallback 关心的是当前这个还活着吗，不活就按列表往后换（顺序敏感）。
3 URL-Test：延迟测试、tolerance 与可复制模板
URL-Test 会按 interval 周期对 proxies 列表中的每一项发起探测（通常为 HTTP 请求到 url），根据往返延迟选择当前最优节点。为避免延迟在临界值附近来回跳动，可用 tolerance：仅当新候选比当前选中项好出超过 tolerance（毫秒）时才切换，从而减少「频繁换节点」导致的连接抖动。社区常用的测速地址包括 http://www.gstatic.com/generate_204、http://cp.cloudflare.com/ 等；若你所在网络对某域名访问不稳定，应换成对你本地可达、且返回轻量响应的 URL，否则会出现「全员超时」误判。
最小可用示例
下面示例中的 HK-1、HK-2 必须与你 proxies: 段里定义的 name 完全一致；若订阅里节点名带特殊字符，建议先在客户端里确认实际名称再写进组内。
proxy-groups:
- name: HK-AUTO
type: url-test
proxies:
- HK-1
- HK-2
- HK-3
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
interval 不宜过小：过于频繁的探测会增加耗电与日志噪音，也可能触发部分机场对高频检测的限制。一般三百秒量级是常见起点；若你追求更快响应，可酌情调低，但建议观察客户端 CPU 与机场侧表现再定。lazy: true（若内核支持）可让策略组在未被规则引用时减少主动测速，适合节点很多的列表。具体字段以你所用的 Clash / Mihomo（Clash.Meta）内核版本文档为准。
4 Fallback：顺序即优先级，健康检查决定何时后移
Fallback 类型策略组维护一个有序的 proxies 列表：内核会对当前选中项做连通性检测（同样依赖 url 与 interval 等配置）；若判定失败，则切换到下一个成员。它不会在同一轮里比较「谁延迟最低」，而是「只要当前能用就尽量别动」，因此特别适合主备线路：主节点在第一位，备节点依次后排。列表里也可以放入另一个策略组（例如前面的 HK-AUTO），从而实现「先在香港自动择优，不行再试新加坡自动择优」。
proxy-groups:
- name: PROXY-MAIN
type: fallback
proxies:
- HK-AUTO
- SG-BACKUP
- DIRECT
url: http://www.gstatic.com/generate_204
interval: 300
是否把 DIRECT 放进 fallback 末尾取决于你的安全与可用性取舍：对「必须走代理」的流量，末尾放 DIRECT 可能导致意外直连；对「宁可直连也要打开页面」的场景，则可作为最后兜底。请结合 rules 里把哪些域名指向该策略组来整体设计，而不是孤立地抄一段 YAML。关于流媒体分流与规则提供器，可对照《ACL4SSR 规则订阅配置详解》中的策略组命名习惯，保持全配置文件引用一致。
5 嵌套组合与在 rules 中引用
实际配置里，url-test 与 fallback 往往成链出现：底层是具体节点，中层是按地区或用途划分的 url-test 组，顶层是 fallback 或 select 供用户在客户端切换「办公 / 游戏 / 视频」等场景。规则层只需把流量指向最外层策略组名即可，例如 - MATCH,PROXY-CHAIN 或更细分的 GEOSITE / DOMAIN-SUFFIX 规则指向不同组名。
若你使用 rule-providers 外链规则，注意策略组名称要与规则里写的 policy 一致；改名后若未同步更新规则，会出现「规则命中了但走向默认组」的错觉。建议在改完 proxy-groups 后，用客户端内置的配置校验或内核的 -t 测试（命令行部署见《Linux 安装 Mihomo 并开机自启》）做一次语法检查，再在日志里观察策略组切换是否符合预期。
6 常见坑与排错思路
- 测速 URL 不可用：若所有节点在日志里显示延迟异常或超时，优先更换
url或检查本机到该探测域名的路径是否被拦截，而不是先怀疑机场全员故障。 - tolerance 设为零或过小：容易导致 url-test 在两名相近节点间来回切；适当增大 tolerance 往往比盲目缩短 interval 更有效。
- 节点改名未同步：订阅更新后节点
name变化，策略组里仍写旧名会导致启动失败或该成员被跳过；更新订阅后复查策略组列表。 - 把 fallback 当成「自动选最快」：它是顺序故障转移，不是全局比延迟；要自动择优请用 url-test 或把 url-test 嵌在 fallback 的某一项里。
- 健康检查与真实业务路径不一致：探测走通不代表长连接大流量一定稳定；若游戏或视频仍卡顿，应结合具体目标域名的规则与 UDP 支持情况继续排查。
proxy-groups；若你同时优化解析，请阅读 DNS 专题中 dns.fallback 段落，不要把两套配置混在一个区块里修改。
7 总结
Clash URL-Test 策略组解决的是「在同一批候选里谁更合适」——用周期性延迟测试与 tolerance 抑制抖动；Fallback 策略组解决的是「当前这条线还能不能用」——用顺序与健康检查完成故障转移。二者与 select、load-balance 等类型互补，配合清晰的 rules 命名，才能把订阅里几十个节点整理成可维护、可预期的几条策略链。牢记 dns 里的 fallback 与 proxy-groups 的 type: fallback 同名不同义，是排错时的第一道 mental checkpoint。
图形化客户端通常会在策略组页展示当前测速结果与选中节点，比纯手写 YAML 更易验证；相比需要反复手动对齐系统代理与配置文件路径的方式，一体化客户端在导入订阅、切换内核、查看日志上往往更省心。若你希望从下载安装到分流一站完成，可从站内下载页选择适合自己系统的 Clash 系客户端，再套用本文策略组模板按需裁剪。
最后建议：为线上使用的配置保留一份最小可启动备份，再在副本上叠加 url-test 与 fallback 嵌套；一旦异常，可快速二分回退到「仅 select + 基础规则」的稳定态，避免在大量改动中难以定位问题。
