为什么自动选路要落在策略组，而不是只靠规则
分流规则回答的是「这条连接该进哪个策略组」；而策略组内部的 select、url-test、fallback 等类型，回答的是「在这个组里最终用哪条节点」。如果你把所有域名都指向一个手动 select，那么节点劣化时只能依赖人工切换。把出口改成 url-test 或 fallback，本质是给内核一个可重复的决策算法：周期性用 HTTP 探测衡量「谁还活着、谁更省延迟」，再在延迟阈值与探测间隔约束下完成自动切换。这与写不写 GEOIP 规则是正交的：规则决定进组，组类型决定组内如何健康检查与选路。
若你尚未完成本机客户端与订阅导入，建议先走一遍 Windows 下 Clash Verge Rev 安装与导入，确保能打开「连接日志 / 策略组面板」，再改 YAML 或覆写，否则很难对照验证。
一句话分清：url-test 与 fallback 各自解决什么问题
url-test：对列表里多个候选节点做探测，通常选出延迟测速结果较好的一条（在 tolerance 容差内还会避免无意义来回切）。适合「一组里谁快用谁」的自动优选场景，例如同一机场多入口、或你想把若干备用节点放在同一池子里跑分。
fallback：按 proxies 数组从上到下尝试，当前节点探测失败或超时才切换到下一个。语义更接近主备容灾：上面是主力，下面是备胎，而不是在备胎之间比谁延迟更低。若你的诉求是「主力挂了再换，平时不要乱跳」，应优先理解这种顺序语义。
不要和 DNS 里的 fallback 搞混
配置里常出现两个「fallback」字样：dns 段里可能有 fallback 服务器组，用于解析失败时的备用 DNS；而本文讲的是 proxy-groups 里 type: fallback 的代理策略组。前者影响「域名解析走谁」，后者影响「解析完成后 TCP 流量从哪个节点出去」。排查问题时务必先看连接日志里命中的是哪个策略组，再看 DNS 日志是否分叉；系统梳理见 Meta 内核 DNS 防泄漏指南。
1健康检查 URL 怎么选：要能稳定返回预期状态
url-test 与 fallback 都依赖对 url 发起 HTTP 探测。实务上常见写法是使用体积很小、全球可达的「204 探测页」，例如 Google 或 Cloudflare 提供的 generate_204 类地址。要点是：① 从你的节点出口访问该 URL 不应被中间设备劫持到奇怪页面；② 返回的 HTTP 状态应与内核预期一致（常见为 204）；③ 若你所在网络对某探测域名不稳定，应换成对你所有候选节点都相对可达的地址，否则会出现「节点其实可用，但探测全失败」的误判。
探测失败并不总是节点坏了：DNS 解析失败、TLS 握手被重置、机场出口对探测域名黑洞，都会在面板上表现为延迟「超时」或不可用。此时应先对照单节点手动连接能否正常上网，再判断要不要换 url 或换上游。
2关键参数：interval、tolerance、lazy、timeout
interval：两次全量或轮询探测之间的时间间隔。间隔越短，对自动切换越敏感，但也更容易放大瞬时抖动；间隔越长，故障发现越慢。长连接业务（协作、语音）若配合过短的间隔与过窄的容差，可能主观感觉「总在换线」，需要与业务场景折中。
tolerance（常用于 url-test）：延迟差异在容差范围内时，倾向维持当前节点而不是切换到略快几毫秒的另一条，用来抑制「无意义切来切去」。容差设得过小，会表现为策略组在多个节点间高频跳动；过大则可能在明显劣化时仍迟迟不换。
lazy：为 true 时，常见行为是直到该策略组被实际使用才开始探测，适合大量备用节点、平时不走的池子，避免无差别打探测流量。入门排错阶段可先关懒加载，确认探测正常，再按需打开。
timeout：单次探测允许等待的上限；过短会在高抖动网络误杀，过长则故障切换偏慢。建议结合机场线路质量逐步调整，而不是复制网上「万能模板」后从不回看日志。
3写法 A：url-test「测速选最快」骨架
下面示意将多个已存在节点名放入同一池，由内核按探测结果自动选择。请把 NODE_A 等替换为你 proxies: 段真实名称，把 AUTO-BEST 换成你想要的策略组名，并在 rules 里把需要优选的流量指向该组。
# Example — replace NODE_* with real proxy names; tune url/interval/tolerance for your network
proxy-groups:
- name: AUTO-BEST
type: url-test
proxies:
- NODE_A
- NODE_B
- NODE_C
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: false
rules:
- MATCH,AUTO-BEST
与 GEOIP / GEOSITE 分流配合时，常见结构是「国内直连 + 国外进 AUTO-BEST」：请保证更具体的域名规则在过于宽泛的 GEOIP,CN,DIRECT 或 MATCH 之前，否则规则层已经把流量截走，策略组再智能也不会被用到。
4写法 B：fallback「主备容灾」骨架
下面示意主备顺序：PRIMARY 探测失败或超时后，才会尝试 BACKUP1，依此类推。适合「平时只用一条贵价专线，挂了再落到普通池」或「先走自有节点再走订阅」这类需求。
# Example — ordered failover; replace proxy names with yours
proxy-groups:
- name: AUTO-FAILOVER
type: fallback
proxies:
- PRIMARY
- BACKUP1
- BACKUP2
url: http://www.gstatic.com/generate_204
interval: 300
lazy: false
rules:
- MATCH,AUTO-FAILOVER
若你还希望「主备链内部再测速」，可以把 BACKUP1 位置换成另一个 url-test 子组名（策略组嵌套），但嵌套越深，排错越难；入门阶段建议扁平结构，确认探测与切换正确后再合并复杂度。链式双跳本身见 relay 双跳教程，不要与 fallback 主备语义混谈。
5如何验证真的生效：面板、日志与故障注入
改完配置并热加载后，先做三步基线检查：① 策略组面板是否显示当前选中节点，且延迟数字随 interval 周期刷新；② 在连接日志中发起一条新连接，确认命中规则指向的组名与面板一致；③ 临时停用主力节点或人为制造超时（例如错误 hosts 仅对探测域名），观察 fallback 是否按顺序下移，url-test 是否在容差允许范围内切换到次优节点。
若面板始终全红，优先怀疑「探测 URL 对你的所有出口都不可达」或「节点名引用错误导致组未加载」，而不是先怀疑内核 bug。名称大小写、空格、emoji 必须与 proxies 完全一致。
常见坑：抖动、长连接与「测速好但上网差」
测速好不代表业务好：探测走的是对特定 URL 的短请求，而视频、下载、游戏可能走不同 POP 与路由；若业务体验与延迟数字长期背离，应回到规则与 DNS，而不是无限缩小 tolerance。
长连接与切换：已建立的 TCP 连接不会在切换节点瞬间自动「搬家」；新连接才会用新选中节点。某些客户端显示切换了，但旧应用会话仍卡在原路径上，需要重连应用或重启长连接。
订阅覆盖：远程订阅若自带同名策略组，可能与本地覆写冲突；使用图形客户端的「覆写 / Prepend」时注意合并顺序与最终生成的完整配置，避免你以为改了 interval、实际仍被远程段覆盖。
调参思路：先稳定，再敏感
建议从「较长 interval + 适中 tolerance + 关闭 lazy 做验证」开始，确认没有大面积误判后，再缩短间隔或打开 lazy 以节省探测。对自动切换敏感的业务（实时协作、交易终端）可单独走手动 select 或更保守的 fallback，把 url-test 留给浏览器、下载等大流量池，减少会话被策略抖动打断的概率。
合规提醒：请仅在法律与网络使用政策允许的范围内使用代理；勿将自动切换用于规避监管或违反服务条款的场景。
关于下载：开源内核与客户端源码可在 GitHub 查阅；日常获取安装包请优先使用 本站下载页，与发行页区分使用。
小结
在 Clash Meta / Mihomo 中做好 健康检查 与自动切换，核心是选对 proxy-groups 类型：url-test 适合「多候选里按延迟优选」，靠 interval 与 tolerance 控制探测节奏与抖动；fallback 适合「按顺序主备容灾」，靠列表顺序表达优先级。二者都依赖可达的探测 url，并要与 分流规则、DNS 决策栈分开理解。把参数调顺、用面板与日志验证后，再与 GEOIP、relay、TUN 等能力叠加，整条链路的可维护性会好得多。
相比手动盯着延迟数字换节点，把「探测与切换」交给内核算法，长期更容易复盘故障：你知道是规则没进组，还是组内探测误判，还是 DNS 与连接不同向。