本文回答什么：Clash Verge Rev 里单列 fallback 策略组一次配稳

如果你正在搜「Clash Verge Rev fallback 策略组怎么设」「健康检查 URL 与 超时 怎么一步步配」「proxy-groups 里 interval、lazy、以及模板里抄来的 tolerance 到底听谁的」——这篇就是给 GUI 与覆写场景写的落地稿：我们只做 type: fallback 这一列能力点，把主备顺序、探测目标、轮询节奏与单次等待上限串成一条可执行的调参链，让你不必在「概念文章」和「另一篇 url-test 专文」之间来回拼图。

《Clash 规则分流详解》在策略组层面点到过 fallback 与 url-test 的分工，但没有把「探测 URL、超时、切换逻辑」拆成可照做的步骤；本站另有一篇专讲自动测速组的 《Verge Rev 自动测速 interval 教程》，面向 url-test 的 interval、tolerance、lazy 与延迟滞回。两条线互补：url-test 关心「谁更快」，fallback 关心「谁先活着用谁、坏了再沿名单往下找」。界面总览仍可见 《Clash Verge Rev Windows 代理模式与日志》。

先分清：fallback 不是「慢半拍的 url-test」

在 mihomo（以及经典 Clash Premium 系）配置里，proxy-groups 下的 fallback 类型，语义是按 proxies 数组顺序做故障转移：从第一个成员开始跑健康检查，找到第一个判定为可用的节点并尽量停留；当该节点在后续周期里被判不可用，才继续向下尝试。它不会为了「另一台快五毫秒」就把你正在用的主线路踢掉——那是 url-test 在延迟维度上不断重算最优解时的典型行为。

因此，若你的痛点是「节点池里我希望永远跟延迟冠军走」，请改读 url-test 专文并调 tolerance 防抖；若你的痛点是「我有明确主备：平时永远用 A，只有 A 真挂才用 B，再挂才用 C」，才属于本篇的 fallback 主场。把两者混读时最常见的坑，是拿着 url-test 的心智去调 fallback，然后抱怨「为什么不自动选最快的备线」——那不是缺陷，是类型定义不同。

一句话选型：延迟优先、可接受偶发换节点 → url-test；业务优先、主备清晰、失败再逃生 → fallback。也可以把两者嵌套：外层手动 select 给人看，内层自动组承担不同职责。

proxies 顺序：写在纸面上的「一号位、二号位、三号位」

fallback 的所有「智能」里，最硬的一条就是顺序。订阅生成器往往按地域或负载均衡默认排序，但那未必是你的业务优先级：你可能希望「家宽出口→备用机场→最后直连」或「公司专线→个人备用→公益节点」——这些意图都必须反映到 proxies: 列表的先后上。调整顺序在 YAML 里就是几行剪切粘贴，在 Clash Verge Rev 里则建议通过覆写 Patch固定，避免每次更新订阅又被模板冲掉。

实务上建议把最不想轻易放弃的节点放最前，把仅作兜底的节点放最后；中间层按你对「可接受的中断时间」与「成本」排序。若同一策略组还会被别的组嵌套引用，改名或调序前务必全局搜索 proxy-groups 与 rules 中的引用，防止出现「以为改了 A 组，实际流量仍走旧名字」的幽灵问题。

url：健康检查去哪测，比「测速按钮」更决定 failover 是否抽风

url 字段告诉内核：用哪条 HTTP(S) 探针来认定「这个节点此刻是否健康」。它应当满足几件事：目标长期在线、对你所在网络与节点池而言可达性稳定、符合合规要求；并且最好能代表你真正关心的出口质量——至少不要与业务站点完全南辕北辙。若探测目标在你地区被污染、被中途劫持、或只对某些 ASN 友好，就会出现「主观上网还行，但自动组认定主线路已死」的错位。

与 url-test 一样，改 url 往往比盲目缩短 interval 更能治本；区别是 fallback 不会为了毫秒级差异频繁换桩，因此「探测偶发失败」更容易被放大成「误切备线」。如果你发现主节点在晚高峰偶尔被踢，第一怀疑对象应是 url 与下文 timeout 的组合，而不是急于把备线前移。

单次超时：超时先配稳，误判才会少

在许多 mihomo 配置范式里，策略组会为健康检查提供单次等待上限（常见字段名为 timeout，具体单位与默认值以你使用的内核文档与合并后的最终 YAML 为准——有的资料按毫秒陈述，也有的示例按秒；本文不替你拍死版本号，只给你调参顺序）。它的直观含义是：这一次探测，最多愿意等多久再宣告失败。过短会使得移动网络、跨海链路或忙时抖动下的「慢一点」被当成「死了」；过长则会让单次失败确认拖很久，体感上好像是客户端反应迟钝。

建议的工作流是：当你看到无理由跳备线，先把单次等待放宽一小档，再配合日志观察是否在 TLS 握手、DNS 解析或首个 HTTP 字节阶段耗时尖刺；当确认误判消失，再考虑是否有必要略微收回，以保持故障发现时间在可接受范围。对与实时音视频、远端桌面共存的环境，误判一次切换的直接成本往往高于「多等数百毫秒才把一次探测判失败」的成本。

interval：多久复测一次，决定「多快发现真死线」

interval 控制健康检查的大致周期。对 fallback 来说，它不像 url-test 那样驱动「为了更好延迟而持续重选」，而更多影响何时重新确认当前节点仍可用、何时给备线让路。间隔过短会增加节点与本地客户端的探测负担，也在出口质量波动时放大震荡；间隔过长则让「主线路已确实不可用但仍在尝试抱残守缺」的时间窗口变长。

若你处于「主线路长期稳定、备线仅作罕见灾难恢复」的格局，偏大一点的 interval 往往更顺眼；若你频繁遭遇提供商维护或区域性阻断，可以接受略短的周期，但仍建议与timeout一起看，避免出现「还没来得及判成功就超时失败」的参数打架。实战中常见做法是：先 timeout 再 interval，先把误判压下去，再谈发现速度。

lazy：没被规则点名的组，是否要抢着第一批测

在支持的版本与写法下，lazy: true 常与「延后首次探测」相关：对某些模板而言，可减少启动阶段大量策略组同时进行健康检查的突发开销，这与 姊妹篇里讨论的场景一致。fallback 若放在规则深处、仅小众域名会命中，开启惰性可以减轻「开机即用」的本机负载；若该组是全局出口的核心链，是否要 lazy 就应结合你希望多快完成首轮可用性认定来取舍。

仍然提醒：字段是否被当前内核识别，以合并覆写后的最终配置与日志为准；写过但静默忽略的情况在跨版本迁移时并不罕见。若你刚升级 mihomo 小版本，优先对比发行说明里对 proxy-groups 的变更。

tolerance：主要服务于 url-test，在 fallback 里别张冠李戴

tolerance 在「自动测速择优」语境里，承担的是滞回与防抖：避免两个延迟接近的节点在噪声驱动下来回横跳。这段机制与 url-test 的「谁延迟更低」目标强绑定，因此我们在专文里把它和 interval、lazy 放在一起讲。许多订阅仓库用同一套片段生成多种组类型，你可能在 fallback 段落里仍看到 tolerance 键名——此时务必打开你所使用版本的文档：若该字段对 fallback 不生效，它会变成心理安慰；若实现层另有解读，更要避免与 url-test 的语义混读。

实务建议：读配置时把「键名存在」与「行为改变」分开验证；最可靠的是观察切换是否仍严格沿 proxies 顺序推进，而不是开始表现类似延迟排序。若你确实需要「主线路恢复后尽快切回」这类高阶行为，往往要在文档中查找是否有专用字段或由上游模板实现的定时回切策略，而不要假设 tolerance 会自动帮你完成。

不同订阅生成器、不同 mihomo 小版本之间，策略组可选字段集合并不完全一致。以合并后的最终 YAML + 内核日志为最高裁判；对健康检查目标的访问须合规、低频、尊重服务条款，避免把探测写成对第三方站点的隐性压力。

在 Clash Verge Rev 里用覆写 Patch单列改 proxy-groups

你不想每次订阅刷新后手动合并几十个节点，又不想在远端明文里改动供应商默认——覆写 Patch就是为这种「本地补丁」而生的工作流：Clash Verge Rev 把远端配置与本地覆写合并成最终运行时 YAML。你要做的，是在覆写中精准对齐目标组的 name，然后增删改写 url、interval、timeout、lazy 与 proxies 顺序。

操作顺序建议是：先预览合并结果，确认没有其他同名策略组遮蔽你的 patch；再重载内核，用连接或日志观察是否在「健康失败」语义下切换到下一候选。Windows 环境下若多套配置共存，核对当前启用档案与覆写绑定的文件名，避免出现「补丁写在 A、运行的是 B」的经典失误。

下面是一段仅用于对齐字段位置的示例（字段名是否全部适配你的版本请自行裁剪，注释使用英文以利 diff 复核）：

proxy-groups:
  - name: "FALLBACK-WAN"
    type: fallback
    proxies:
      - HK-PRIMARY
      - SG-BACKUP
      - JP-LAST-RESORT
    url: https://www.gstatic.com/generate_204
    interval: 240
    timeout: 5000
    lazy: true

嵌套与其它组类型：别把「链路」写成「死循环」

fallback 的成员不仅可以是单个节点，也可以嵌套指向其它 proxy-groups，从而在 UI 呈现树状结构——这很强大，但维护成本也高。建议是：让读者一眼能读的层级不要超过两三跳；并把「兜底直连」写成显式的 DIRECT 或可理解的最后一跳，而不要留一个空指向。与 relay 链式转发相比，fallback 不改变数据路径拓扑，它只是帮你挑一个当下可用的末端或子组。

若你与 TUN、系统代理并存，要记住：接管方式改变的是「流量怎样进内核」，不会让 fallback 摇身一变获得 url-test 的延迟排序。TUN下长连接路径更裸露，误判切换的体感更明显，可参考本站 《TUN 指南》并行排查 DNS 环路等问题。

分步自检清单（建议按顺序勾选）

  1. 在合并 YAML 中找到目标组的 type: fallback，抄写当前 proxies 序列与三项探测参数：url、interval、单次 timeout（若存在）。
  2. 用语言描述你最想要的优先级故事，对照序列是否需要重排——这是零成本的第一步。
  3. 若存在「主线路偶发误判死亡」，先行放宽单次超时或更换更可及的 url，再动 interval。
  4. 检视启动负载：若大批量组同时探测，尝试对长尾组启用 lazy（在版本支持前提下）。
  5. 单独核验 tolerance：若它不服务于你的目标类型，把注意力放回 url-test 专文或直接移除无效键以降低认知噪音。
  6. 把变更固化进覆写，订阅更新三遍仍成立，再在日志里做一次故意断主线的演习，确认 failover 与时间参数符合期望。

常见问题（正文速览）

问：fallback 会像 url-test 一样让我「越用越快」吗？ 不一定。它只是沿着名单找第一个可用的成员；「快」除非你把它定义为主线路本身更快，或通过外层结构间接实现。问：可以同时写很短的 interval 和很短的 timeout 吗？ 技术上常能写，但这组组合最容易制造误判与日志风暴。问：移动端与桌面共用一套 fallback 行不行？ 可行，但要注意蜂窝网络对探测超时的敏感度更高，往往需要分别覆写或通过不同 profile 分拆。

小结

Clash Verge Rev 下要把 fallback 策略组单独配稳，核心不是背概念，而是把四条线拧在一起：顺序表达主备，url表达「什么叫活着」，timeout与interval一起在时间与误判之间找平衡，lazy按需减轻启动暴风；tolerance则应交还给 url-test 的语义主场或按文档精确核实。把它们写进覆写 Patch并与合并后的运行时 YAML 对照，就能把 GUI 场景的「单列功能点」从玄学拉回工程。

不少闭源或黑盒加速器把故障转移隐藏在界面背后，既不能查看 url 与单次探测上限，也难以在订阅更新与个人补丁之间保持稳定差异；另一类老旧图形壳还停留在旧内核词汇表上，写出来的字段静默失效却无人告知。Clash 与活跃的 mihomo 生态则把策略组可读、可补丁、可追责当作默认范式——这让「主备 failover」这种问题可以像改防火墙规则一样拆开验证，而不是在社交平台上试错。想了解各平台的官方分发与版本脉络，可参考本站整理的下载聚合页。

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