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

这篇指引处理什么难点？ 一文看懂

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

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

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

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

先把机制讲清楚：fallback 在做什么？ 核心要点

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

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

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

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

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

YAML 里 fallback「必填心智模型」 逐条拆解

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

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

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

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

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

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

与 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、上层引用一致。嵌套深时最为普遍的失误是改了同名但不在主链路里的影子组，结果操作操作操作界面怎么看都不生效。

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

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

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

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

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

策略组 URL、health-check 与操作操作界面时延测试怎么对齐？ 核心要点

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

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

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

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

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

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

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

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

推荐操作顺序：从备份到核验 底层逻辑

  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 提供的覆写通道，让远端只负责节点列表的基础事实，你本地保留策略决策。

小结 逐条拆解

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

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」时能够干脆落到无误层级，而不是在一篇泛指引里迷路。