外观
故障转移策略组：fallback 与 url-test 的配置
故障转移策略组的核心是“检查成员是否可用，再按规则选一个”。主力加备用的场景通常选 fallback：按成员顺序取第一个通过健康检查的成员；url-test 则在通过检查的成员里取延迟最低者。
两者的参数含义、适用边界和常见陷阱，是本文要拆开讲清楚的内容。
本文只写通用原理与配置思路，不写软件版本、菜单位置、默认值，也不给任何速度或延迟数值。品牌信息来自站内资料（Vendor Data），不构成可用性承诺。
核心结论与适用条件
第一，策略组类型决定的是“谁来做选择”。select 是你自己选，fallback 是按顺序选，url-test 是按延迟选，load-balance 是按算法分配。备用订阅的目的是冗余，因此多数情况下用 fallback，而不是 url-test。
第二，所有自动类策略组都依赖健康检查。检查地址、检查周期、超时判断三者共同决定了策略组“看到”的世界。检查本身出错，策略组就会做出错误的选择，这比没有自动化更难排查。
第三，自动化不能替代验证。策略组类型显示为 fallback，并不证明它会在你需要的时候切换。只有人为制造过一次故障并观察到切换，才算配置完成。
第四，对低流量或流量包类备用订阅，策略组的选择逻辑直接决定额度消耗。这与流量包做备用的成本分析是同一件事的两面。
适用条件：你的客户端基于 Clash 系内核或支持类似的策略组概念；两份订阅已经能在同一客户端中共存（见多订阅合并的配置方法）；你接受通过编辑配置或使用客户端的配置覆盖来实现。如果你只用厂商自研客户端且它没有策略组功能，则无法实现，只能手动切换订阅。
四种策略组类型的行为差异
先把行为差异讲清楚，再谈参数。
select：手动选择
成员列表由你手动点选，客户端不自动改变选择。它适合当作最外层入口：让你能够在“自动”“主力”“备用”之间人工切换。它的优点是行为完全可预测，缺点是故障时需要人工介入。
fallback：按顺序选第一个可用成员
内核周期性地对成员做健康检查，选择排在最前面且通过检查的成员。主力排第一、备用排第二，主力可用时永远用主力，主力不可用时自动用备用，主力恢复后重新回到主力。它的特点是行为可解释：你只需要看顺序和检查结果就能推断它的选择。
url-test：选延迟最低的成员
内核周期性地对成员探测，选延迟最低者。它适合成员之间相当、你希望自动挑一个快的场景，比如同一订阅内部的多个节点。用于“主力加备用”则要小心：只要备用的某次探测延迟更低，它就会被选中，这违背了备用只在故障时使用的初衷。
load-balance：按算法分配连接
把连接分散到多个成员，常见的分配方式有按目标地址固定到同一成员、按轮询等。它适合希望分摊额度或避免单点压力的场景，但行为更难预测，且部分连接的出口 IP 会变化，对依赖固定出口的网站可能带来登录异常。备用方案很少使用它，了解即可。
| 类型 | 选择依据 | 主力恢复后 | 对备用额度的影响 | 典型位置 |
|---|---|---|---|---|
| select | 用户手动 | 不自动变化 | 取决于你的选择 | 最外层入口 |
| fallback | 成员顺序加可用性 | 自动回到靠前成员 | 主力可用时备用基本不消耗 | 主力加备用的组合层 |
| url-test | 延迟高低 | 取决于延迟 | 可能被持续选中而消耗 | 同一订阅内部节点选择 |
| load-balance | 分配算法 | 按算法 | 两边都会消耗 | 需要分摊的特殊场景 |
技术参数对比大表
下表列出与故障转移相关的主要参数。所有参数为通用概念，不含默认值与具体数值；“待核实”表示需要你查所用内核文档确认。
| 指标 | 单位 | 统计口径 | 作用与影响 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|
| 策略组类型 | 枚举 | select / fallback / url-test / load-balance | 决定谁做选择 | 通用技术资料 | 2026-10-18 |
| 成员列表 | 列表 | 节点或其他策略组 | fallback 的顺序即优先级 | 通用技术资料 | 2026-10-18 |
| 检查地址 | URL | 用于探测连通性的地址 | 地址不可达会让所有成员被判为不可用 | 通用技术资料 | 2026-10-18 |
| 检查间隔 | 秒 | 两次健康检查之间的时间 | 越短发现故障越快、消耗越多 | 待核实（以内核文档为准） | 2026-10-18 |
| 超时判定 | 毫秒 | 超过多久未响应视为失败 | 过严会误判，过宽会延迟发现 | 待核实（以内核文档为准） | 2026-10-18 |
| 容差 | 毫秒 | url-test 切换所需的延迟差 | 抑制在相近成员间来回切换 | 待核实（以内核文档为准） | 2026-10-18 |
| 惰性检查 | 布尔 | 无流量时是否暂停检查 | 减少空闲时的探测消耗 | 待核实（以内核文档为准） | 2026-10-18 |
| 成员过滤 | 表达式 | 按名称筛选订阅源节点 | 配合节点前缀拆分主力与备用 | 通用技术资料 | 2026-10-18 |
| 订阅源引用 | 列表 | 策略组直接引用订阅源 | 订阅更新后成员自动变化 | 通用技术资料 | 2026-10-18 |
| 实测切换耗时 | 秒 | 主力故障到流量改走备用 | Not Tested | 待核实（用户自测） | 2026-10-18 |
| 实测检查消耗流量 | MB / 月 | 全部检查累计 | Not Tested | 待核实（用户自测） | 2026-10-18 |
表中凡是需要数值的位置，本站一律不给，因为不同网络环境下最合适的数值差别很大，且内核的取值范围和默认行为可能随版本变化。你需要做的是读所用内核的文档，并在自己的环境里测试。关于内核差异可以阅读内核相关说明。
决策树：该用哪种类型
Decision Path
故障转移策略组类型选择
text
你希望故障时自动切换吗？
├─ 否 → select，手动选择；定期手动演练即可
└─ 是 → 继续
├─ 成员之间有明确的主次吗？
│ ├─ 是（主力加备用）
│ │ ├─ 备用是低流量或流量包吗？ → fallback，备用排后
│ │ └─ 备用额度充足，且接受备用被使用？ → fallback 仍是合适的基础结构
│ │ └─ 想在主力内部再选快节点？ → 主力小组用 url-test，外层 fallback
│ └─ 否（成员对等，同一订阅内多个节点）
│ ├─ 想自动挑延迟低的？ → url-test，并设置容差
│ └─ 想分摊连接？ → load-balance，注意出口 IP 变化
└─ 无论哪种：
├─ 检查地址是否稳定且能代表真实用途？
├─ 是否人为制造故障验证过？
└─ 是否保留了最小配置以便回退？决策树里有一个值得强调的结构：外层 fallback，内层 url-test。主力订阅内部有多个节点，用 url-test 让主力小组自己挑一个较快的节点；外层 fallback 只在主力小组整体失效时才切到备用。这个两层结构既能保留自动选优，又能让备用只在真正需要时才被使用。
配置思路：从小组到入口，分层构建
下面以通用的配置结构描述，不给具体语法，写法以所用内核文档为准。
第一层：主力小组
主力小组的成员来自主力订阅源，通常通过订阅源引用加名称过滤得到。类型一般选 url-test，让它在主力的多个节点中挑一个延迟较低的。设置检查地址、检查间隔和容差。容差的意义在于：若不设置，延迟的微小波动会引发频繁切换，对于需要保持连接的应用（例如长连接的聊天、远程会话）会造成断连。
第二层：备用小组
备用小组的成员来自备用订阅源。类型可以是 url-test 或者 select。如果备用订阅的节点数量很少，甚至就一两个，用 select 或直接把节点放进外层组也可以。这里的关键是检查设置：备用小组的检查不要太频繁，因为它平时不承担流量，检查的消耗全是额外开销。惰性检查如果可用，也值得开启，让没有流量时不做探测。
第三层：入口 fallback 组
入口组的类型是 fallback，成员是主力小组和备用小组，顺序是主力在前、备用在后。入口组也需要设置检查参数，这里检查的对象是小组本身，而不是节点。内核通常会把小组选中的节点作为检查对象。理解这一点很重要：入口组判断“主力小组可用”，实际上是判断主力小组当前选中的那个节点能否通过检查。
第四层：规则指向入口
规则部分只指向入口组，不出现具体订阅或节点。规则的组织方式见规则与全局直连的区别。配置文件整体结构、缩进与常见语法错误见配置文件说明，缩进错误是手写配置最常见的失败原因，编辑后务必让客户端先校验再应用。
可选层：最外层 select
在入口组之上再放一个 select，成员包括“自动”（即入口 fallback 组）、“仅主力”“仅备用”“直连”。它给了你一个人工覆盖的开关：自动逻辑出问题时，你可以一键锁定到主力或备用，不用改配置。这是整个结构里性价比最高的一层，建议保留。
健康检查：自动化的眼睛
策略组的所有自动选择都建立在健康检查的结果之上，所以检查本身的设计值得单独讨论。
检查地址的选择原则
检查地址应当满足四点：稳定，不会因为地址本身下线导致全体误判；体积小，请求和响应都很小，以免消耗流量；与你的真实用途相关，如果你主要访问某类服务，检查地址应当能反映到这类服务的可达性；全配置一致，不要在不同策略组里使用不同的检查地址，否则同一节点在不同组里的状态不一致，排错时会很混乱。本站不指定具体检查地址，请自行选定并记录。
检查结果的局限
健康检查只回答“通过这个节点，探测地址能不能访问”。它不回答：目标站点对该出口地址是否有限制；DNS 解析是否经过了正确的路径；规则是否真的把流量送进了这个策略组；节点此刻的带宽是否足够。所以“检查通过”只是必要条件。尤其是 AI 工具和流媒体这类对出口地址敏感的场景，品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准，而不是以健康检查结果为准。
检查频率与流量消耗
每次检查都会产生很小的流量，频率越高、成员越多，累计越多。对于大流量主力套餐，这一点可以忽略；对于低流量备用和流量包，检查消耗应当进入你的预算。降低消耗的办法是：备用小组减少检查对象，只检查入口层需要的成员；延长备用的检查周期；启用惰性检查。同时要在“发现故障的速度”与“消耗”之间取舍，这个平衡点因人而异。
超时与误判
超时过严，网络短时波动就会被判为故障，导致不必要的切换；超时过宽，真正的故障要很久才被发现。更稳妥的做法是在自己的网络上观察一段时间，了解正常波动的范围，再设定。移动网络与无线网络的波动通常比有线网络大，如果你在手机上使用，可以阅读移动端客户端的差异了解网络切换带来的影响，桌面端则参考桌面客户端专题。
三个场景的配置推演
场景一：年付主力加按月备用
主力是年付订阅，流量充足；备用是低价小流量。结构：主力小组 url-test，备用小组 select 或少量节点，入口 fallback，主力在前。预期行为：平时全部走主力，备用不消耗；主力整体失效时自动切备用；主力恢复后自动回主力。需要注意的是，主力“恢复”的判断也来自健康检查，若恢复后流量立刻回切，而备用正承载着重要的长连接，这些连接会被打断。如果这对你是问题，可以在外层放 select，故障期间人工锁定备用，等任务完成再切回。
场景二：主力备用均为年付折算低价套餐
站内资料中年付折算品牌（光速云、微风网络、飞猫云、星岛梦）的价格均为年付折算价，月付价待核实，入门流量在 50GB 到 60GB 之间（品牌资料标注）。两份都是小流量时，额度紧张，建议 fallback 把其中一份固定为主力，并留意备用的额度。是否应该两份都年付，请回到选型清单按价格口径核对，并先用较短周期验证。
场景三：主力加不限时流量包
不限时流量包没有月度重置，适合作为备用。站内资料中星岛梦的场景标签提及不限时套餐，具体规则、有效期、价格均待核实。作为备用放在 fallback 末位时，流量包只在故障时消耗，闲置浪费最小，这正是不限时套餐在轻度场景中的意义。但要核对流量包的有效期，避免备用悄悄过期而你不知道，此时需要配合备用订阅的定期检查。
切换发生时，已有连接会怎样
很多人以为故障转移是“无感”的，实际并非如此，理解它能避免错误预期。策略组切换成员只影响之后新建的连接；已经建立在旧节点上的连接，是否保留取决于内核与客户端的设置：有的会保持旧连接直到自然结束，有的会在切换时主动断开。保持旧连接意味着正在使用失效节点的连接会一直卡住直到超时；主动断开则意味着所有长连接重来一次。两种行为各有代价，你需要在文档中找到相关选项并按自己的场景选择。
对于网页浏览，这几乎无感；对于远程会话、实时通话、大文件传输，重连是不可避免的。如果你的关键任务属于后者，更务实的做法是把故障转移当成“让下一次连接成功”的机制，同时在应用层保留重试能力。另外，DNS 缓存也会影响切换后的第一次访问：客户端或系统缓存了旧解析结果时，切换后的头几次访问可能仍然异常，等缓存刷新后恢复。路由器等网关层的 DNS 行为见移动与路由器相关专题。
常见故障与排查顺序
自动化出问题时，按下面的顺序排查，每一步只验证一个层面。
- 配置是否被正确加载：客户端是否提示配置错误，策略组是否出现在界面中。缩进与引用名称拼写错误最常见。
- 订阅源是否更新成功：如果订阅源为空，成员列表也为空，策略组不可能工作。更新失败的原因见订阅更新失败的排查。
- 成员过滤是否匹配到节点：前缀或表达式写错，会让小组变成空组。
- 检查地址是否可达：直接在浏览器或工具里验证。
- 入口组当前选中了谁：界面通常会显示当前选中成员，对照预期。
- 规则是否命中入口组：访问一个明确应该走代理的站点，查看连接日志里它走了哪个组。
- 流量路径是否被系统层面绕过：如果使用 TUN 之类的接管方式，要确认接管是否生效，见TUN 模式的原理与问题。
- DNS 是否正常：解析异常会让“节点没问题但就是打不开”，原理见路由与线路专题中关于路径的说明。
如果以上都没有找到原因，才考虑是服务本身的问题，此时按照主力不可用时的应急步骤处理。
知识图谱：故障转移策略组
实体定义
故障转移策略组指客户端中通过健康检查判断成员可用性，并在成员失效时自动改用其他成员的策略组配置。fallback 是其中按成员顺序选择第一个可用者的类型；url-test 是按延迟选择的类型。
相关概念
健康检查：对成员做周期性探测以判断可用性。容差：抑制相近延迟成员间来回切换的参数。惰性检查：无流量时减少探测的机制。订阅源：拉取并缓存节点列表的单元。成员过滤：按名称筛选节点。嵌套策略组：以策略组为成员的结构。出口 IP：流量最终离开代理节点时使用的地址。
技术参数
类型、成员顺序、检查地址、检查间隔、超时判定、容差、惰性检查、成员过滤。数值类参数本站均不给定，以所用内核文档与自测为准；切换耗时与检查消耗均为 Not Tested。
适用场景
主力加备用；同一订阅内部节点择优；多份订阅并用；备用为低流量套餐或不限时流量包。不适用于需要固定出口 IP 的登录场景下频繁切换的情形，这种场景应使用 select 并手动锁定。
对比依据
类型的比较依据是选择依据、主力恢复后的行为、对备用额度的影响。品牌的比较依据只使用站内品牌资料中的字段。横向对比专题提供字段并列，测试方法与数据说明说明本站目前所有品牌均无 Measured Data。
常见问题指向
“fallback 与 url-test 选哪个”“主力恢复是否切回”“检查地址选择”“检查通过但访问失败”“容差作用”“备用额度风险”“检查消耗”“嵌套”“如何验证”在下文常见问题中逐条回答。
方案关联：用品牌资料决定备用的位置
策略组的结构确定后，还需要根据订阅自身的属性决定谁在前、谁在后。可核对的字段如下，全部来自站内品牌资料（Vendor Data）。
| 核对项 | 对 fallback 顺序的意义 | 资料情况 |
|---|---|---|
| 入门流量 | 流量小的更适合排在后面作为备用 | 光速云 59GB；微风网络、飞猫云各 50GB；星岛梦 60GB |
| 价格类型 | 年付折算意味着周期锁定，尽早决定是否续费 | 四家均为年付折算，月付价待核实 |
| 协议 | 决定两份订阅能否在同一内核中共存 | 光速云 VLESS；其余三家待核实 |
| 套餐形态 | 不限时套餐更适合排末位 | 星岛梦场景标签提及不限时套餐，规则待核实 |
| 线路标注 | 互补维度之一，不代表实际路径 | 以品牌资料为准，实测 Not Tested |
下面以星岛梦的资料快照展示字段形式，仅作示例，不构成倾向性判断：
Infrastructure Service Snapshot
星岛梦 /xingdaomeng
本站排名第一本站推荐排名，非测速或可用性测试结果
- 入门价格
- 8 元/月
- 价格类型
- 年付折算 年付折算价
- 入门流量
- 60GB
- 线路
- 企业级内网专线
- 协议
- 待核实
- 运营年份
- 2020
- 客户端
- 支持第三方客户端订阅导入
- 支付方式
- 支付宝 / 微信 / USDT
星岛梦的价格“年付折合约 8 元/月”是年付折算价，月付价待核实，需一次性支付整年费用；入门流量 60GB；线路标注企业级内网专线；客户端方式为支持第三方客户端订阅导入。你可以查看品牌库中的完整资料与同价格带品牌再决定备用来源。
优点、限制与风险
优点
故障时无需人工介入，对不能随时看手机或电脑的人尤其有价值。主力优先的顺序让备用额度得到保护。分层结构让每一层可以单独测试和替换。外层 select 保留了人工覆盖的能力。检查结果可以在界面中观察，行为可解释。
限制
自动切换不等于自动恢复业务：正在进行的长连接在切换时会中断，需要应用层重连。健康检查只能证明探测地址可达，不能证明目标服务可用。参数取值依赖你的网络环境，本站不给数值，需要自行测试。部分功能与参数名称因内核而异，需要读所用内核的文档。切换耗时、检查消耗均为 Not Tested。
风险提示
- url-test 用于主力加备用时，可能让备用在主力可用时被选中而快速消耗额度。
- 检查地址选择不当会引发全体误判，让策略组做出与现实相反的选择。
- 在需要固定出口 IP 的账号场景，频繁切换可能触发平台的风控提示，此类场景应锁定节点。
- 编辑配置前备份并保留最小配置，避免手写配置错误导致无法联网。
- 年付折算价订阅需一次性支付整年费用，先用较短周期或较小套餐验证再长期付费。
- 机场服务的线路、节点、价格和套餐可能随时调整，下单前请以官网实时信息为准。
- 使用代理服务应遵守所在地法律法规与平台服务条款，更多注意事项见风险与注意事项专题。
常见问题
fallback 和 url-test 到底该选哪个做备用？
想要主力优先、主力失效才用备用，选 fallback，它按成员顺序选择第一个可用者。想要在若干成员中选延迟最低者，选 url-test。以备用为目的的订阅，通常 fallback 更符合预期，因为它不会在主力可用时去消耗备用额度。
fallback 会不会在主力恢复后自动切回来？
通常会。fallback 每个检查周期都重新按顺序判断，只要排在前面的成员恢复可用，就会重新被选中。如果你希望故障后固定留在备用，需要用手动选择类型或配合其他机制，而不是 fallback。
健康检查的地址应该怎么选？
选一个稳定、体积很小、能代表你实际用途的探测地址，并且在整个配置中保持一致。检查地址本身不可达，会让所有成员被判为不可用。具体地址由你根据自己的使用环境确定，本站不指定。
为什么检查显示节点可用，实际访问却失败？
健康检查只证明探测地址能通过该节点访问，不证明你要访问的目标站点可达。目标站点对出口地址的限制、DNS 解析异常或规则没有命中，都会出现检查通过而访问失败。需要用实际访问去验证。
url-test 的容差参数是做什么用的？
容差用来避免在延迟相近的成员之间频繁切换。只有新的最低延迟成员比当前成员好出一定幅度才会切换，否则保持不动。具体数值由你根据网络波动自行设定，本文不给固定值。
备用订阅是低流量套餐，用 url-test 会有什么风险？
url-test 会把连接分给延迟最低的成员，不关心额度。备用订阅一旦在某段时间延迟更低，就会被持续选中并快速消耗流量。对低流量备用，应当用 fallback 把它排在主力之后。
健康检查本身会消耗流量吗？
会，但单次探测体积很小。检查周期越短、成员越多，累计消耗越多。对低流量套餐，不要把检查周期设得过短，也不要对不需要的成员做检查。具体消耗取决于配置，本文不给估算数值。
fallback 里可以嵌套另一个策略组吗？
可以。成员既可以是节点，也可以是其他策略组。常见做法是主力小组和备用小组各自是一个组，再由 fallback 把它们按顺序组合。嵌套层数不宜过多，否则排错困难。
配置好之后如何验证故障转移真的生效？
在不赶时间时人为制造主力故障，例如临时禁用主力订阅源，观察入口组当前选中的成员是否变为备用，并用实际访问验证。只在配置界面看到类型是 fallback 并不能证明它会按预期工作。
同专题文章
Cluster · backup
备用方案
- 备用机场怎么选：与主力服务形成互补选择备用机场时应该考虑哪些互补维度？
- 用流量包做备用：成本较低的冗余方案用不限时流量包做备用是否划算？
- 在客户端中同时使用两份订阅的配置方法如何在一个客户端里同时使用两份订阅？
- 故障转移策略组：fallback 与 url-test 的配置如何配置自动故障转移的策略组？
- 定期检查备用订阅：避免关键时刻失效备用订阅应该多久检查一次，检查什么？
- 主力服务突然不可用时的应急步骤主力服务突然无法使用时应该按什么顺序处理？
下一步
配置完成后，建议建立备用订阅的定期检查流程，并回到轻度与备用总览确认整体思路。如果两份订阅尚未放进同一客户端，先阅读多订阅合并的配置方法。
信息来源与更新日期
信息来源：通用技术资料（Clash 系内核策略组与健康检查的通用概念）；品牌公开资料/用户提供清单（data/brands.json，Vendor Data）。本文品牌数据均为 Vendor Data，测速状态为 Not Tested，不含任何实测数值。
数据核实日期：2026-10-18。最近更新时间：2026-10-18。