Clash Verge Rev 怎么设 fallback 策略组？Win11 逐步配置与自检

这篇指南处置什么困扰？ 要点速览

若你还处在「分清 Select 与全全全自动组、第一次点整机测速」的阶段，请先读 策略组UI UI UI 界面与测速入门；若你更关心「全全全自动组在多条差不多快的线之间乱跳」那类抖动，应去看 url-test 健康排查与容差专篇——它和 fallback 的决策哲学不同，混谈容易对症错药。

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

要把订阅载入、规则总线与全局概念串起来，可并行启用 Clash Verge Rev 采用指南 与 规则分流指南。

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

先把机制讲清楚：fallback 在做什么？ 关键信息

还要牢记：UI UI UI 界面响应时间测试给出的是「此刻对某探测目标的握手耗时印象」，而策略组层面的 url: 决定 health-check 打哪里。

关键点是：得以把 fallback 理解成「带体检的插队队列」：proxies 数组从前往后是一份显式第一顺位级清单，内核用你指定的 策略组 URL 与 interval 对成员做周期性的健康排查，沿着清单寻找第一个被认为健康的出站。

当前选中成员被判不可用或健康排查长期无法完成时，流量会顺移到列表中的下一名，而不是像 url-test 那样在整池子里持续比哪个毫秒数更低。换言之，fallback 的目标是可控的故障转移：你先写清「谁是主、谁是备」，再由 health-check 决定是否维持在这一跳。

于是它与 人工 Select 的差别在于：Select 只有你亲自改节点才会动；而与 url-test 的差别在于：url-test 更像「响应时间第一顺位的动态橱窗」，fallback 更像「名单从上往下找到第一个能用的」。

这里要多说一句：如果你把两条线的顺序写反了，健康排查在多数时间都会认定「最靠前的那条」可用，你心仪的备用节点或许长期轮不到出场——这种配置失误表现在外就是「明明后面有节点却永远走前面那条」。

两个目标若指向不同域名或路径，就会出现「我手工点测速全是绿，但 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）里该改哪里？ 完备说明

写覆写时坚持最小差异：保留 name 与 type，必要时增补或替换 url、interval，谨慎调整 proxies 顺序，避免误删远端维护的节点池。

换个说法：不同安装渠道菜单文案会略有出入，但稳妥路径仍分两类：径直编辑当前激活档案做一次性实验，或把补丁放进 Merge/Patch 覆写一类持久片段里长期采用。

订阅正文会周期性全文刷新，仅在远端 YAML 手改 interval 经常在下次升级后被冲掉；把针对某一 fallback group 的片段放在本地覆写中，才能让health-check参数跟着你走的设备与习惯留下来。

动手前请先导出备份：在客户端找到配置编辑器或档案列表，把合并后的完备 YAML 另存一份到本地。

落到实处：用搜索定位 type: fallback 或机场作者在组名里常用的「备」「回退」「fallback」标签，确认你编辑的名称与 rules、上层引用一致。嵌套深时出现最多的失误是改了同名但不在主链路里的影子组，结果UI UI UI 界面怎么看都不生效。

保存后采用「重载核心」或等价按钮应用；若提示缩进或键名疏漏，第一顺位对照内核文档而不是在社交平台上随便抄一段。

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

调整顺序后切记重载内核，并在至少一个完备 interval 周期内观察日志里是否仍出现对旧顺序的误引用。

在真实网络里，「最靠前」几乎总是意味着「出厂吃最多流量」。如果你把响应时间略高但极其平稳的线路放在第一位，而把 experimental 节点放在第二位，只要前者健康排查过关，后者就很少有机会露脸；

别忽略了：反过来，把试用型出口置顶，一旦它间歇性超时，全组会在你不知情的现状下频繁甩尾。排顺序时应先问业务困扰：这条链路关键点承载视频会议还是下载？能否接受偶尔切到备用时的短暂断流？有没有成本或配额限制要让某条线在主位？回答完再把答案翻译成数组。

当你从别的客户端迁移到 Clash Verge Rev 时，也要排查历史配置是否混用了「注释里的推荐顺序」和「实际 proxies 数组顺序」——YAML 里生效的只有列表本身。

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

策略组 URL、health-check 与UI UI 界面响应时间测试怎么对齐？ 关键信息

在出现「成员偶发变红又立刻恢复」时，不要第一反应就是把 interval 砍到极端值，否则只会放大瞬时噪声。

关键点是：很多人把「代理页一键测速」当成唯一真理，却忽略内核正在为 fallback 成员发起另一套周期探测。对齐方式并不难：先在 YAML 记下该组的 url，再在排障窗口核对日志里 health-check 的目标域名是否与之吻合。

若客户端允许单独指定全局响应时间测试地址，也要区分它是「用户UI UI UI 界面便捷功能」还是「改写各个组的探测」——多数现状下两者仍或许分叉。

当你怀疑探测目标本身带来误判时，得以临时把 url 换成体量更小、地域策略更中性的 HTTPS 端点作为对照实验，保持 interval 与其它网络条件不变，仅观察是否仍然大规模标红。

这里要多说一句：DNS、TUN 与 fake-ip 的细枝末节或许交叉影响探测路径，深入请参阅 Verge Rev DNS 专篇；此处只强调「探测走哪条隧道」要与真实业务流量一致。

更稳妥的是先确认 Windows 侧防火墙是否拦了核心请求、Wi‑Fi 省电是否导致首次握手无法完成，再结合 节点响应时间通用排障分流 DNS 与 UDP 因素。

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

对重度依赖直播或实时语音的用户，得以把自检和业务高峰错开，并在切换发生时盯一眼 Clash Verge Rev 连接列表里目标域名是否仍命中预期的 fallback group。

与写完规则就完事不同，fallback 的价值要在「故障被制造出来时」才看得见。推荐的占用少验证是：先在备份里锁定你要测试的三节点顺序，重载后在代理页对整组执行响应时间测试，确认每位成员在健康状态下都能拿到合理数字；

换个说法：随后暂时下线或屏蔽列表第一名（可用机场控制台停用、或在实验环境阻断其域名），等待至少一个 interval，观察选中项是否全全全自动落在第二名。恢复第一名后，再在日志中核对 health-check 是否重新认可其可用性。

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

有时困扰不在组成员而在规则：流量被更早的 MATCH 送到了别的组，你再怎么调顺序都看不到成效。

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

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

落到实处：全部过程不要求你一次记牢全部键名，而要求你把「顺序—探测—间隔」三件事放在同一张心智图里。不管哪一套一口气含糊，都会在真实故障来临时放大成成片超时。

典型症状：如何敏捷收窄？ 要点速览

现象：主节点清楚可见坏了，却始终不切备用（速览）

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

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

相较 url-test，纯 fallback 链若仍剧烈抖动，普遍根因是策略组 URL本身噪声过大，或多条线路共享同一无法完成模式（举个小例子同一上游黑洞）。

此时应先修 url 与网络侧，而不是盲目改顺序；若确实要在「多条活线」间按响应时间优化，应评估是否改为 url-test。

现象：UI 界面响应时间全红，怀疑 health-check 彻底无法完成（清单）

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

普遍困扰（速查） 关键信息

得以把 fallback 嵌在另一个策略组里吗？（说明）

得以，只要最终引用链闭合、名称无冲突；但要当心嵌套层级越深，排障越难。刚上手的人更不妨先在扁平结构下调通 health-check，再逐步引入嵌套。

订阅升级后顺序又乱了怎么办？（速览）

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

小结 关键点梳理

如果你还希望对照其它文档路径一目了然、与 Mihomo 对齐积极的桌面发行版，不妨前往 下载页 获取与本站结构一致的入口；

Clash Verge Rev 在 Windows 11 上只是把 Mihomo 的语义可视化；要让 fallback 真正承担「主备链」职责，关键仍是 YAML 里是否写清了顺序、是否为 health-check 指定了语义对路的策略组 URL与合理的 interval，以及你是否能把UI UI 界面响应时间测试与内核探测区分开来。

把备份、覆写、重载与单变量实验做成固定套路，fallback 就从「订阅里一行神秘字段」变成可验证的工程配置。

别忽略了：相比之下，不少过时图形客户端要么内核版本落后导致字段校验无法完成，要么把「全全自动组」笼统一句带过，既不区分 fallback 与 url-test 的切换哲学，也不提醒探测 URL 或许分叉；搜到的碎片化笔记又常让你同时改十几个开关，最后无法复盘。

Clash 坚持按题型拆专文，让你在搜索「Clash Verge Rev fallback」「fallback group」「health-check」时得以径直落到对路层级，而不是在一篇泛指南里迷路。

想一次收齐入门与进阶的也得以径直 免费下载 Clash 收录的客户端，从策略组基础循序渐进到本篇的容错链配置。