这篇教程解决什么问题？

你已经在 Windows 11 上把 Clash Verge Rev 跑起来，也看得懂代理页里一堆 策略组名字，却在遇到「主节点偶发掉线、希望自动换到备用」时卡住：订阅里写的 fallback 究竟按什么规则跳过不健康成员？health-check 用的策略组 URL和你在界面里点的延迟测试是不是一回事？子节点顺序要不要调？这些问题拆开看都不大，合在一起却能让排障变成玄学。本篇只钉 fallback 策略组这一类：把它在 YAML 里写完整，再在客户端侧按顺序自检，确认延迟测试与内核判定对齐。

若你还处在「分清 Select 与自动组、第一次点整机测速」的阶段，请先读 策略组界面与测速入门；若你更关心「自动组在多条差不多快的线之间乱跳」那类抖动，应去看 url-test 健康检查与容差专篇——它和 fallback 的决策哲学不同，混谈容易对症错药。要把订阅导入、规则总线与全局概念串起来，可并行打开 Clash Verge Rev 使用教程 与 规则分流教程。

术语对齐：下文以 Mihomo（Meta）系内核常见的 proxy-groups 写法为准；字段是否支持 lazy 等附加键随版本略有差异。保存后若 Verge Rev 报错，应以内核校验信息为准，勿盲目堆叠从网上复制的旧片段。

先把机制讲清楚：fallback 在做什么？

可以把 fallback 理解成「带体检的插队队列」：proxies 数组从前往后是一份显式优先级清单，内核用你指定的 策略组 URL 与 interval 对成员做周期性的健康检查，沿着清单寻找第一个被认为健康的出站。当前选中成员被判不可用或健康检查长期失败时，流量会顺移到列表中的下一名，而不是像 url-test 那样在整池子里持续比哪个毫秒数更低。换言之，fallback 的目标是可控的故障转移：你先写清「谁是主、谁是备」，再由 health-check 决定是否维持在这一跳。

因此它与 手动 Select 的差别在于：Select 只有你亲自改节点才会动；而与 url-test 的差别在于：url-test 更像「延迟优先的动态橱窗」，fallback 更像「名单从上往下找到第一个能用的」。如果你把两条线的顺序写反了，健康检查在多数时间都会认定「最靠前的那条」可用，你心仪的备用节点可能长期轮不到出场——这种配置失误表现在外就是「明明后面有节点却永远走前面那条」。

还要牢记：界面延迟测试给出的是「此刻对某探测目标的握手耗时印象」，而策略组层面的 url: 决定 health-check 打哪里。两个目标若指向不同域名或路径，就会出现「我手工点测速全是绿，但 fallback 里某一个成员仍被内核标红」的错位。后文自检一节会专门把这两条线对齐。

YAML 里 fallback「必填心智模型」

在合并后的完整配置中找到或新增一段结构（示意，勿照搬域名与节点名）：

proxy-groups:
  - name: "FB-OUT"
    type: fallback
    proxies:
      - 主线路
      - 备线路
      - 兜底线路
    url: https://example.com/generate_204
    interval: 300

type: fallback：声明这是一个按顺序容错、依赖健康检查输出的策略组。

proxies：既参与排队的子代理名称列表，也是故障切换路径的物理顺序。放置时把自己最想常驻、或丢包代价最低的成员放在最前；仅当健康检查判定靠前成员不适合继续承担流量时，才轮到后面的名字。

url：health-check 使用的策略组 URL，通常是对小体积响应友好的 HTTPS 地址，语义上应能反映「这段出站此刻能不能正常完成握手」。它不是随意挑的新闻首页，更不宜指向会被地域或风控反复拦截的页面，否则你会看到成员被误杀、整组频繁顺移。

interval：探测间隔（秒）。过短会让笔记本在 Wi‑Fi 节能、路由器瞬时负载等场景下看到噪声型失败；过长则拉长故障发现时间。实践中多从订阅模板默认值出发，只在「切换太慢」或「误判太多」这两类反馈出现时再做单变量调整。

与 url-test 对照记忆：需要「主备清晰、尽量少折腾」用 fallback；需要「在多条活线里持续选延迟较低」用 url-test。二者都依赖健康检查时，务必分别核对各自的 url，不要假设「我改了 A 组的探测，B 组自动跟着变」。本站 url-test 专篇 中的 tolerance 思路主要服务「比快」场景，不要强行套到 fallback 的顺序语义上。

在 Clash Verge Rev（Windows 11）里该改哪里？

不同安装渠道菜单文案会略有出入，但稳妥路径仍分两类：直接编辑当前激活档案做一次性实验，或把补丁放进 Merge/Patch 覆写一类持久片段里长期使用。订阅正文会周期性全文刷新，仅在远端 YAML 手改 interval 往往在下次更新后被冲掉；把针对某一 fallback group 的片段放在本地覆写中，才能让health-check参数跟着你走的设备与习惯留下来。

动手前请先导出备份：在客户端找到配置编辑器或档案列表，把合并后的完整 YAML 另存一份到本地。用搜索定位 type: fallback 或机场作者在组名里常用的「备」「回退」「fallback」标签，确认你编辑的名称与 rules、上层引用一致。嵌套深时最常见的失误是改了同名但不在主链路里的影子组，结果界面怎么看都不生效。

写覆写时坚持最小差异：保留 name 与 type，必要时增补或替换 url、interval，谨慎调整 proxies 顺序，避免误删远端维护的节点池。保存后使用「重载核心」或等价按钮应用；若提示缩进或键名错误，优先对照内核文档而不是在社交平台上随便抄一段。

顺序不是摆设：主备链怎么排才合理？

在真实网络里，「最靠前」几乎总是意味着「默认吃最多流量」。如果你把延迟略高但极其稳定的线路放在第一位，而把 experimental 节点放在第二位，只要前者健康检查过关，后者就很少有机会露脸；反过来，把试用型出口置顶，一旦它间歇性超时，全组会在你不知情的情况下频繁甩尾。排顺序时应先问业务问题：这条链路主要承载视频会议还是下载？能否接受偶尔切到备用时的短暂断流？有没有成本或配额限制需要让某条线在主位？回答完再把答案翻译成数组。

当你从别的客户端迁移到 Clash Verge Rev 时，也要检查历史配置是否混用了「注释里的推荐顺序」和「实际 proxies 数组顺序」——YAML 里生效的只有列表本身。调整顺序后务必重载内核，并在至少一个完整 interval 周期内观察日志里是否仍出现对旧顺序的误引用。

若订阅提供的是自动生成的巨大节点池，而你只想拿其中一小撮做 fallback，可以在不破坏远端命名约定的前提下，在覆写里收窄 proxies 列表为三到四个代表性成员，先验证 health-check 与顺序的心智模型正确，再逐步放开。面对「全家桶」式模板，切忌在没读懂规则引用前盲目删组名。

策略组 URL、health-check 与界面延迟测试怎么对齐？

很多人把「代理页一键测速」当成唯一真理，却忽略内核正在为 fallback 成员发起另一套周期探测。对齐方式并不难：先在 YAML 记下该组的 url，再在排障窗口核对日志里 health-check 的目标域名是否与之吻合。若客户端允许单独指定全局延迟测试地址，也要区分它是「用户界面便捷功能」还是「改写所有组的探测」——多数情况下两者仍可能分叉。

当你怀疑探测目标本身带来误判时，可以临时把 url 换成体量更小、地域策略更中性的 HTTPS 端点作为对照实验，保持 interval 与其它网络条件不变，仅观察是否仍然大规模标红。DNS、TUN 与 fake-ip 的细节可能交叉影响探测路径，深入请参阅 Verge Rev DNS 专篇；此处只强调「探测走哪条隧道」要与真实业务流量一致。

在出现「成员偶发变红又立刻恢复」时，不要第一反应就是把 interval 砍到极端值，否则只会放大瞬时噪声。更稳妥的是先确认 Windows 侧防火墙是否拦了核心请求、Wi‑Fi 省电是否导致首次握手失败，再结合 节点延迟通用排障分流 DNS 与 UDP 因素。

自检流程：如何确认「不健康节点会被跳过」？

与写完规则就完事不同，fallback 的价值要在「故障被制造出来时」才看得见。推荐的轻量验证是：先在备份里锁定你要测试的三节点顺序，重载后在代理页对整组执行延迟测试，确认每位成员在健康状态下都能拿到合理数字；随后暂时下线或屏蔽列表第一名（可用机场控制台停用、或在实验环境阻断其域名），等待至少一个 interval，观察选中项是否自动落在第二名。恢复第一名后，再在日志中核对 health-check 是否重新认可其可用性。

如果你在实验窗口同时改动了系统代理与 TUN、或新开第二条 VPN，结论会被污染，表现为「跳过行为有时生效有时不生效」。因此自检阶段应固定出站形态，遵守一次只动一个变量：要么只改 proxies 顺序，要么只改 url，否则复盘几乎不可能。

对重度依赖直播或实时语音的用户，可以把自检和业务高峰错开，并在切换发生时盯一眼 Clash Verge Rev 连接列表里目标域名是否仍命中预期的 fallback group。有时问题不在组成员而在规则：流量被更早的 MATCH 送到了别的组，你再怎么调顺序都看不到效果。

推荐操作顺序：从备份到核验

  1. 导出备份：保存合并后完整 YAML，记录目标 fallback 组的原始 proxies、url、interval，便于单行回滚。
  2. 冻结实验环境：暂时关闭第二款全局 VPN，固定系统代理或 TUN 其一，避免中途切换网络形态。
  3. 核对引用名：在 rules 与上层策略组中确认流量确实会命中你要改的这一组。
  4. 重排 proxies：按主备语义调整顺序，避免「优质备用永远轮不到」的低级倒置。
  5. 校准策略组 URL：选择体量小、可达性稳定、与成员出口语义一致的 HTTPS 探测地址。
  6. 理性设置 interval：从模板默认出发，仅在「发现太慢」或「噪声太多」时分步微调。
  7. 写入覆写并重载：把片段放在本地持久区而非订阅正文，应用后等待至少两倍 interval 再下结论。
  8. 对照界面与日志：用延迟测试与自检脚本验证跳过行为，异常时逐项回退并比对备份差异。

整个过程不要求你一次记牢全部键名，而要求你把「顺序—探测—间隔」三件事放在同一张心智图里。任何一步含糊，都会在真实故障来临时放大成成片超时。

典型症状：如何快速收窄？

现象：主节点明显坏了，却始终不切备用

先确认健康检查是否判定主节点仍可用：有可能探测 URL 对它过于宽松，或与你真实访问的目标域名不是一条路径。其次查规则：流量是否根本没进这个 fallback 组。最后再审视 interval 是否过长导致你发现故障的时间与内核不同步。

现象：组成员频繁在相邻条目间来回跳

相较 url-test，纯 fallback 链若仍剧烈抖动，常见根因是策略组 URL本身噪声过大，或多条线路共享同一失败模式（例如同一上游黑洞）。此时应先修 url 与网络侧，而不是盲目改顺序；若确实需要在「多条活线」间按延迟优化，应评估是否改为 url-test。

现象：界面延迟全红，怀疑 health-check 彻底失败

对照 测速入门 检查核心是否启动、防火墙弹窗是否放行；再验证探测域名是否遭劫持。不要在未读日志的情况下把 interval 调到极端，否则只会刷出更多失败样本。

常见问题（速查）

可以把 fallback 嵌在另一个策略组里吗？

可以，只要最终引用链闭合、名称无冲突；但要注意嵌套层级越深，排障越难。新手更建议先在扁平结构下调通 health-check，再逐步引入嵌套。

订阅更新后顺序又乱了怎么办？

说明你的改动写在远端可覆盖区域。把与顺序、url、interval 相关的片段迁移到 Verge Rev 提供的覆写通道，让远端只负责节点列表的基础事实，你本地保留策略决策。

小结

Clash Verge Rev 在 Windows 11 上只是把 Mihomo 的语义可视化；要让 fallback 真正承担「主备链」职责，关键仍是 YAML 里是否写清了顺序、是否为 health-check 指定了语义正确的策略组 URL与合理的 interval，以及你是否能把界面延迟测试与内核探测区分开来。把备份、覆写、重载与单变量实验做成固定套路，fallback 就从「订阅里一行神秘字段」变成可验证的工程配置。

相比之下，不少过时图形客户端要么内核版本落后导致字段校验失败，要么把「自动组」笼统一句带过，既不区分 fallback 与 url-test 的切换哲学，也不提醒探测 URL 可能分叉；搜到的碎片化笔记又常让你同时改十几个开关，最后无法复盘。Clash 官网 坚持按题型拆专文，让你在搜索「Clash Verge Rev fallback」「fallback group」「health-check」时可以直接落到正确层级，而不是在一篇泛教程里迷路。

如果你还希望对照其它文档路径清晰、与 Mihomo 对齐积极的桌面发行版，不妨前往 下载页 获取与本站结构一致的入口；想一次收齐入门与进阶的也可以直接 免费下载 Clash 官网 收录的客户端，从策略组基础循序渐进到本篇的容错链配置。