Clash 策略组 url-test、fallback、load-balance 区别与选用场景

三种策略组：先按选路目标区分

日常浏览希望自动选低延迟节点，用 url-test；主线路稳定、备用线路只在故障时接替，用 fallback；希望把不同连接分配到多个节点，用 load-balance。它们都属于 proxy-groups，但选择依据不同，不能只看客户端里是否带有“自动”字样。

策略组负责决定使用哪个出站，不负责让应用流量自动进入 Clash。系统代理或 TUN 负责接管流量，规则模式下的 rules 再把连接交给具体策略组。如果规则最终指向 DIRECT，调整这些组的测速参数不会改变该连接的路径。

url-test：按延迟选路，用 tolerance 减少切换

url-test 会通过候选节点请求测试地址，根据测试结果自动选择节点。这里测到的是请求测试端点的耗时，不是下载速度，也不是访问所有网站的平均体验。节点到测试站点的路线很好，不代表它到视频服务或开发仓库的路线同样好。

参数起点：300 秒一次，50 毫秒容差

下面是组定义片段，不是完整订阅。示例中的“节点-A”“节点-B”“节点-C”必须已经在现有配置的 proxies 中定义，且名称完全一致。合并到现有 proxy-groups 列表即可，不要创建重复的顶层键。

proxy-groups:
  - name: 自动低延迟
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

• interval: 300：周期健康检查间隔为 300 秒，即 5 分钟；它不是应用请求的超时时间。
• tolerance: 50：切换容差为 50 毫秒，用于避免候选节点仅快一点就反复切换。它不是延迟上限，也不会把超过 50 毫秒的节点排除。
• lazy: false：即使组暂时未被使用，也按周期进行检查，便于观察结果；节点较多时会增加测试请求。
• url：选择响应轻、长期可达的测试端点。示例端点通常返回 HTTP 204；不要使用需要登录、频繁跳转或风控验证的页面。

例如，在其他选择条件相同的情况下，当前节点测得 120 毫秒，候选节点为 105 毫秒，15 毫秒的差距通常不足以触发 50 毫秒容差下的换路；候选降到 60 毫秒时，才更有切换意义。这是参数含义示例，不是本站实测结果，最终选择仍以当前内核状态和日志为准。

不适合仅凭延迟做决定的任务

大型下载、长时间视频传输和远程桌面还依赖带宽、丢包与抖动。可以先用自动组筛出可用节点，再在相同时间段、相同目标下比较传输速度。需要固定出口 IP 的登录会话，更适合手动选择节点或使用有明确主备顺序的组。

fallback：按列表顺序选择首个可用节点

fallback 的重点是优先级。只要列表前面的节点通过健康检查，就优先使用它；前面的节点不可用，才选择后面的可用节点。因此，主线必须排在第一项，备用线依次排在后面。

proxy-groups:
  - name: 主线故障切换
    type: fallback
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

假设节点-A 的测试延迟为 180 毫秒，节点-B 为 75 毫秒，只要 A 仍然健康，组仍会优先使用 A。把 tolerance 加到这里，并不能让它变成按延迟选路的组。若需求是“谁快用谁”，应直接改用 url-test。

恢复与故障边界

• 主线恢复健康后，后续选路会重新优先考虑主线。故障发现和恢复依赖检查及内核触发机制，不能承诺即时完成。
• 组切换主要影响后续连接。已经建立的 TCP 连接不会迁移到新节点；原连接断开后，应用通常需要重连。
• 测试端点可达，只代表这项检查通过。若业务网站单独不可达，主线可能仍被判定健康，此时需要检查目标站点或规则。

对会议、远程终端等持续会话，主备切换是恢复路径，不是无感迁移机制。部署前可以暂时停用测试主线，观察新连接是否转到备用，再恢复主线验证优先级。测试时避免同时修改 DNS 和 TUN 设置，否则难以判断变化来自哪一层。

load-balance：分配连接，不叠加单连接带宽

load-balance 会在可用成员之间分配流量，具体分配取决于 strategy。它不是把一个文件连接拆成多条线路同时传输的带宽聚合工具。单条 TCP 连接仍经由一个选定的出站；应用自己建立多个连接时，才可能让多个节点参与。

proxy-groups:
  - name: 多连接分配
    type: load-balance
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing 与 round-robin

使用轮询时，同一网站的多个新连接也可能来自不同出口 IP。对登录风控严格的服务、支付页面或要求 IP 一致的接口，不宜直接采用这种分配方式。一致性哈希能减少变化，但当成员健康状态改变、节点列表调整时，也不能保证出口永远固定。

如果三个节点共享同一个上游瓶颈，分配连接也不会凭空增加可用带宽。验证效果时，应同时看连接面板中的实际节点、目标站点吞吐和失败率，而不是仅看三个成员是否都有测试延迟。

把自动组接入规则：保留手动选择入口

三个自动组可以同时存在，再由一个 select 组决定当前使用哪种策略。这样切换日常浏览、主备和多连接场景时，不必反复编辑规则。以下片段要与前文的三个组定义合并，不能单独作为完整配置加载。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自动低延迟
      - 主线故障切换
      - 多连接分配
      - 节点-A
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,代理出口
  - MATCH,代理出口

这里的 MATCH 只是展示兜底规则如何引用策略组，不是一套完整的境内外分流方案。已有订阅通常还包含局域网、境内站点和规则集规则，应保留原有分流逻辑，仅把需要代理的规则目标改为“代理出口”。规则按从上到下的顺序匹配，宽泛规则放得过早，会让后续规则没有命中机会。

1. 备份当前可用配置，先确认三个自动组与成员名称都能被内核识别。
2. 在客户端的代理或策略组页面，把“代理出口”选为“自动低延迟”等目标组；名称和菜单位置以实际客户端为准。
3. 使用规则模式，访问测试网站，在连接详情核对命中的规则、策略链和最终节点。
4. 改选另一个策略组后建立新连接验证；旧连接可能继续使用原节点，不能仅靠刷新一次页面下结论。

如需先确认应用是否经过代理，可按系统代理设置步骤检查接管方式，再按延迟测试步骤观察组内状态。不要用切换全局模式替代规则命中检查。

常见误配：间隔、成员来源与订阅覆盖

把 interval 写成毫秒

interval: 300000 表示 300000 秒，不是 5 分钟。需要每 5 分钟检查就写 300。也不建议为了“反应快”直接改成 1：节点越多，请求开销越明显，而且频繁检测无法修复节点本身的拥堵。

只写节点名，配置里却没有对应成员

proxies 引用的是已有节点或策略组的名称，不是订阅链接。大小写、空格和符号都要一致。组之间也不能互相循环引用，例如“代理出口”包含“自动低延迟”，而“自动低延迟”又包含“代理出口”。

如果节点来自 proxy-providers，可用 use 引用已经定义的提供器，例如 use: [订阅节点]。“订阅节点”必须是现有提供器键名。提供器的 health-check 与组内检查涉及不同配置层，不要假设改了组的检测间隔，所有提供器检测也会同步变化。

更新订阅后，自定义策略组消失

直接编辑远程订阅生成的文件，常会在下次更新时被覆盖。优先使用客户端支持的覆写、合并或扩展配置机制；这些入口并不跨客户端统一。保存后先执行配置检查，再更新一次订阅，确认组定义、规则引用和手动节点入口仍然存在。

选型结论：按业务稳定性决定自动程度

• 日常网页与通用代理：从 url-test、300 秒间隔和 50 毫秒容差开始，观察是否存在频繁切换。
• 固定主线与备用线路：选择 fallback，把主节点放在列表第一位，实际演练断线和恢复。
• 多目标、多连接任务：考虑 load-balance，先使用一致性哈希，再判断业务是否允许轮询。
• 账号会话与固定出口：在 select 中保留具体节点入口；必要时把相关域名单独指向固定策略。

策略组的目标是让选路逻辑符合业务，不是让所有场景都追求最低的测速数字。先保留一份可回退配置，每次只修改一个参数，并用新连接核对最终出口，才能把配置变化与体验变化对应起来。