规则已会了，为什么还需要 url-test 与故障转移？
很多用户已经能按教程写好 规则分流：国内直连、海外走某个名叫 PROXY 或「🚀 节点选择」的策略组。但若该组是手动选节点，一旦当前节点晚高峰变差或临时被封，就要自己点开客户端换别条线路，使用成本高。
Clash 系列内核（含 Mihomo / Clash Meta）在 proxy-groups 里除 select（手动）外，还提供 url-test、fallback 等类型：前者偏向「多节点里选延迟低的那一个」，后者偏向「按列表顺序，当前面的不可用再往后试」，正好对应「省心得快」与「主备与故障转移」两类诉求。把这类组当作规则里指向的「代理出口」，就能在规则不变的前提下，让出口行为自动化。
url-test 与 fallback 各解决什么问题？
url-test：对组内每个代理周期性做健康检查（向指定 url 发请求并看延迟），在可达节点里选出满足条件、延迟较优的一个作为当前使用。它适合「一批同类节点、谁快用谁」的场景，不强调固定主备关系。
fallback：按你在配置里写的列表顺序，从上到下优先使用；当前面的代理失败或超出判定条件时，再切到后面。它更贴近「主备节点」与故障转移：把最稳的线路放最前，备线依次后排。
两者都依赖「怎样的线路算坏掉」和「多久测一次」等参数。具体字段名与默认值请以你所用 Mihomo 版本文档为准，下表是常见心智模型。
若你的订阅里还没有稳定可用的节点，请先从订阅导入与节点拉取开始；策略组再聪明，也只是在「已有节点池」里做选择，无法凭空造线路。
健康检查与关键参数在说什么？
无论是 url-test 还是 fallback，都绕不开健康检查。内核会按 interval 周期去请求你指定的 url，根据响应延迟或是否成功来更新各代理的测量结果。你常会见到类似下面的字段（名称以你本地内核文档为准）：
- url：测速目标地址。社区常见示例包括返回体很小的 HTTP 地址；关键是在代理出网上能稳定返回、且你允许用于探测，避免用过于敏感或区域性过强的站点。
- interval：测量间隔。间隔太短会放大请求、耗电与日志；太长则切换可能滞后。可按「能接受多久才发现节点坏了」来折中。
- tolerance：常与 url-test 搭配，表示在已有「当前选择」时，新测得的延迟要优于旧选择多少才值得切换，避免在相近延迟之间来回跳。
- lazy：若为 true，有时仅在有实际流量经该组时才更积极测量，能减轻空闲时的探测负担；具体行为以版本说明为准。
故障转移与主备：fallback 的列表顺序
把 fallback 想成「有序候选队列」：第一个代理健康则一直用它；当它被判为不可用，才试第二个、第三个。因此主备节点的语义完全由你写的顺序决定。通常会把套餐里标注为主出口、最稳定的节点名放在最上，将备用、落地或低优先级线路依次向下排列。
与「主备」相关的使用习惯是：不要期待 fallback 在两条都健康时「负载均衡到两条」；它本质是先占住第一条的故障转移，而不是多路同时分摊（那是另一路策略，例如 load-balance 类，与本文主备重点不同）。
按延迟与自动选节点：url-test 怎么用？
若你有一大堆地区相近、你对其「谁当下最快」没有执念，而只希望自动选到当前延迟较低者，url-test 更贴切。它会在各节点测量结果中按规则选优，并可用 tolerance 抑制轻微波动导致的频繁切换。适合流媒体、大流量下载、日常浏览等「体验优先、谁快用谁」的池子。
注意：自动切换不等于永远最快。若所有节点对探测 URL 都慢，但某条对真实业务反更快，这属于目标站点路径差异，可尝试换测速 URL 或把业务敏感域名在规则中指向单独的手动/专用组。策略组是工具，业务规则仍要你自己对齐。
在配置里长什么样？（结构示意）
下面是一段仅用于理解结构的 YAML 示意。代理名、附加字段、是否支持 use 引用 provider 等，均以你实际运行时内核版本为准，请勿不经核对整段套入生产环境。
# Example only — align with your Mihomo / Meta version
proxies:
- name: "node-primary"
type: ss
# ...
- name: "node-backup"
type: ss
# ...
proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO-BEST
- FALLBACK-MAIN
- node-primary
- DIRECT
- name: AUTO-BEST
type: url-test
url: "http://cp.cloudflare.com/generate_204"
interval: 300
tolerance: 50
lazy: true
proxies:
- node-a
- node-b
- node-c
- name: FALLBACK-MAIN
type: fallback
url: "http://cp.cloudflare.com/generate_204"
interval: 300
proxies:
- node-primary
- node-backup
rules:
- MATCH,PROXY可见：规则里只写 PROXY 等组名；PROXY 本身用 select 让你仍能手选「自动组」与「主备组」；而 AUTO-BEST、FALLBACK-MAIN 内部才是 url-test 与 fallback。这样分层，既保留手动兜底，又能在同一套规则上切换自动化策略。若你用图形客户端，对应界面里「策略组 / 代理组」的嵌套与命名需与此一致，否则规则会指向不存在的组名而启动失败或回退到意外策略。
实测步骤：如何验证主备与自动切换？
配置写完后，建议按下面顺序做可控验证，避免「感觉换了节点」但其实是 DNS 或规则命中错误。
1. 看当前选中的出口。在支持连接日志的客户端中，找到目标策略组，确认当前高亮或标记的代理名称，与你在 url-test 或 fallback 下预期的「当前使用」一致。
2. 对 fallback 做主备实验。在仅影响你自己的前提下，临时让主节点不可达（例如该节点在商详里本就有开关、或在测试环境用防火墙模拟）。观察是否在若干次探测后切到备节点；再恢复主节点，观察是否按策略回到主用（与内核「返回主用」的判定有关，各版本可查阅文档是否需额外选项）。
3. 对 url-test 做波动观察。在间隔时间前后对比组内各节点延迟示数，并人为制造一条线明显更差，确认当前选用的是测量结果中符合规则的那条。若切换过频，可调大 tolerance 或 interval；若切换过慢，则反向微调（注意对探测目标与资源的占用）。
4. 用真实业务打一手。测速只是探测，可再打开你常去的站点或应用，看是否存在「测速好但业务差」的反差，必要时为该类域名在规则中走单独策略组或调整 DNS。更多规则思路仍建议与整站分流文一起阅读，避免只改组、不改规则却期望奇迹。
常见误区与排错顺序
误区一：把 url-test 当负载均衡。它是「在测量意义下选优或按版本逻辑切换」，不是把流量平均分到所有节点。若你有多机分担需求，要另查你内核是否提供相应策略类型及是否适合自己的合规场景。
误区二：fallback 顺序反了却以为是内核 bug。主备与故障转移的优先级全由你的列表上下顺序决定，和节点在订阅里的原始顺序无关。更新订阅后若节点名变化，要重新核对组内引用名是否仍有效。
误区三：健康检查全绿但网页打不开。先查规则命中、DNS 与 SNI，再改策略组。否则你会在 url-test 与手动之间来回折腾，而问题实际在 rules 或 dns 段。
写在最后
会配规则、会分域名，只是让流量「进哪扇门」；Clash 策略组里的 url-test 与故障转移，则决定这扇门后用哪一条具体线路。把 fallback 当作主备与自动容灾的骨架，把 url-test 当作低延迟与少折腾的选路器，并与规则里统一的 PROXY 出口衔接，就能在少动手的前提下保持相对稳定的上站体验。若你希望从安装到文档一站补齐，也可翻阅全平台安装与配置教程建立整体语境。
相比在多个项目仓库之间翻零散片段，使用维护良好、与 Mihomo 版本节奏匹配的客户端，往往能在「策略组嵌套、健康检查、界面编辑」上少踩坑。若你尚未安装或准备换机，建议从我们的客户端下载页获取当前系统对应版本，再按本文步骤在图形界面里对照 YAML 做一版可回滚的配置。→ 立即免费下载 Clash，开启流畅上网新体验。