Clash 策略组 url-test、fallback、load-balance 配置详解

先按需求选策略组

想自己选节点，用 select；想自动挑延迟较低的节点，用 url-test；想优先使用固定节点、故障时才换备用，用 fallback；想把不同连接分配到多个节点，用 load-balance。这四种方式解决的问题不同，不能只看名字里有没有“自动”。

策略组是节点或其他策略组的集合。规则先决定流量交给哪个组，组再决定实际出口。例如 MATCH,出口选择 表示：没有被前面规则命中的连接，交给“出口选择”。它不是测速命令，也不会让所有规则自动改走这个组。

类型	选择依据	适合的需求	需要注意
`select`	用户手动选择	固定地区、手动排错	普通手选节点故障后不会自行换节点
`url-test`	探测结果与延迟差	日常自动选择低延迟出口	探测延迟不等于下载带宽
`fallback`	列表顺序与可用状态	主线路加备用线路	备用更快也不一定被选中
`load-balance`	分配算法与可用状态	把不同连接分散到多个出口	不会把单个下载连接的带宽叠加

配置前先核对内核和节点名称

客户端负责界面，内核负责执行配置。不同客户端即使按钮相似，所带内核也可能不同。先在客户端的“关于”或内核信息页面确认使用的是 Clash 兼容内核还是 mihomo，再核对对应版本的配置说明。下面使用常见 Clash 策略组字段，其中负载均衡示例明确采用 mihomo 支持的 consistent-hashing 策略。

备份当前配置文件，以及客户端单独保存的覆写设置。覆写指在订阅原配置之上追加或修改字段的机制。
确认现有 proxies 中有可用节点，并复制完整名称；空格、大小写和符号都要一致。
如果节点来自 proxy-providers，应使用组内的 use 引用对应提供者，而不是把提供者名称当作节点写进 proxies。
找出客户端的本地配置或覆写入口。直接修改订阅下载文件，可能在下一次更新时被覆盖。

select：用一个入口手动切换策略

select 本身不负责比较延迟。它把候选项放在界面中，由用户决定选哪一个。候选项既可以是实际节点，也可以是自动测速组、故障转移组等其他组。因此，最实用的结构通常是外层手选，内层自动。

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - 自动测速
      - 故障转移
      - 连接分担
      - 香港主线
      - 日本备用
      - 新加坡备用

这段代码引用的三个子组会在后文定义。实际使用时，把四个组的列表条目合并到同一个顶层 proxy-groups 下。不要在一个 YAML 文件里反复添加同名顶层键；重复键可能造成解析报错，也可能让前一段配置被后一段覆盖。

首次加载时通常会使用列表首项，但客户端可能恢复上次保存的选择。修改列表顺序后，仍应进入策略组页面查看当前选中项。排错时可以临时选定一个实际节点，先排除子组嵌套带来的影响。

url-test：自动测速与 tolerance 的作用

url-test 通过候选节点访问指定测试地址，依据探测结果选择出口。它比较的是到该测试地址的请求耗时，不是到所有网站的综合表现。一个节点访问测试地址很快，仍可能在视频站点、游戏服务器或大文件下载上表现一般。

  - name: 自动测速
    type: url-test
    proxies:
      - 香港主线
      - 日本备用
      - 新加坡备用
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

interval 用秒，tolerance 用毫秒

interval: 300：周期探测间隔设为 300 秒，也就是 5 分钟。它不是每 300 毫秒切换一次节点。
tolerance: 50：为自动选择增加 50 毫秒的切换容差，避免节点只有微小延迟差时频繁切换。
lazy: false：不依赖组近期是否被使用来省略周期探测，会增加空闲时的网络活动；手机端可按需改成 true。

用一组假设数据理解容差：当前节点延迟 120 毫秒，另一个节点 100 毫秒，只快了 20 毫秒，设置 50 毫秒容差时通常会保留当前节点；如果另一个节点降到 60 毫秒，优势达到 60 毫秒，就可能切换。这里是机制示例，不是线路实测或性能承诺；实际选择还取决于探测是否成功、历史状态和内核实现。

容差不是超时时间。当前节点探测失败后，不能理解为“还要等慢满 50 毫秒才换”。手机使用中可以先从 300 秒间隔、50 毫秒容差开始观察。把间隔压到 5 秒，会显著增加探测次数，却不能保证业务连接更稳定。

fallback：按优先级故障转移

fallback 按列表顺序寻找可用节点。它的目标是保住首选线路，而不是始终选最快线路。下面的配置先尝试“香港主线”，只有它被判定不可用时，才考虑“日本备用”，再往后才是“新加坡备用”。

  - name: 故障转移
    type: fallback
    proxies:
      - 香港主线
      - 日本备用
      - 新加坡备用
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

假设主线探测延迟为 180 毫秒，备用只有 80 毫秒，只要主线仍被判定可用，通常仍使用主线。主线恢复并被后续探测识别后，组会重新优先考虑它。因此，对固定出口地区、账号登录环境比较敏感的场景，故障转移往往比一味追求最低延迟更容易管理。

另外，“测试地址可达”只说明这项探测成功。若节点能访问测试地址，却不能访问目标业务，组仍可能把它视为可用。此时应核对目标服务的地区限制、DNS 解析和规则命中情况，而不是只缩短探测间隔。

load-balance：分配连接，不是合并带宽

load-balance 会按算法把不同连接分配到候选节点。下面采用 consistent-hashing，即一致性哈希策略：依据目标信息，让同一类目标尽量使用稳定出口。在 mihomo 中通常按目标域名的可注册主域等信息进行映射，具体细节以实际内核版本为准。

  - name: 连接分担
    type: load-balance
    proxies:
      - 香港主线
      - 日本备用
      - 新加坡备用
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

另一个常见选项是 round-robin，即轮询分配。它按轮转方式为新连接选择出口，不是让一个已建立的连接每传一段数据就换节点。对需要稳定登录状态的网站，多个连接从不同地区出口发出，可能触发额外验证，因此不宜不加区分地用于全部流量。

单个文件只建立一个 TCP 下载连接时，不会因为组里有三个节点就自动获得三倍速度。
多个独立下载或不同目标的连接，可能被分到不同节点，但分配结果不保证字节数均匀。
多个节点如果最终共用同一条受限上游线路，分担连接也无法突破那条线路的瓶颈。
UDP 能否正常使用还取决于实际节点协议、服务端能力及流量接管方式，不能仅凭组类型判断。

让规则真正使用这些策略组

策略组定义好后，还需要规则把连接送过来。下面只展示两条规则，方便在已有规则体系中理解位置。域名示例 example.com 用于演示精确分流，不代表任何实际业务要求。

rules:
  - DOMAIN-SUFFIX,example.com,故障转移
  - MATCH,出口选择

规则从上往下匹配，命中后通常不再继续查找。具体域名规则要放在最终的 MATCH 之前；如果既有配置已经包含规则集、局域网直连和地区分流，应保留它们，只调整确实需要变更的策略目标。不要为了测试一组策略，把整份规则缩减成上面两行。

同时确认客户端运行在规则模式。全局模式使用全局策略，直连模式则不会按上述规则选择代理出口。Android 上通过 VpnService 接管流量、桌面上启用 TUN，都不会改变这四种组的基本选路逻辑；TUN 是流量接管方式，不是第五种测速算法。

加载、验证与常见故障排查

先检查语法。 YAML 使用空格缩进，不用制表符。四个组都应处在同一个 proxy-groups 列表下，且组名不能重复。
重新加载配置。 在客户端配置页面启用修改后的配置，查看是否出现节点不存在、组引用无效或字段不支持等错误。
手动测试一次。 在策略组页面触发延迟测试，确认三个节点分别有结果。留意界面显示的是组的测试结果，还是订阅提供者的另一套健康检查结果。
确认规则命中。 打开连接记录，检查目标域名、命中的规则和最终节点。仅看到“出口选择”被选中，还不能确定最终用了哪个子组成员。
做可恢复的故障测试。 在测试配置中临时移除主线，再重新加载并新建连接，观察备用是否工作。完成后恢复原配置，不要修改线上服务端来模拟故障。

配置更新后，策略组又变回去了

优先检查订阅更新是否覆盖了本地修改。把自定义策略放在客户端支持的覆写或合并机制中，并确认合并方式是追加、替换还是脚本处理。不同客户端对同名策略组的处理不同，不能只凭“保存成功”判断最终配置正确；应查看实际运行配置。

延迟都正常，但网页仍打不开

先用 select 固定到一个已知可用节点，再查看连接日志。若目标域名被错误分配到直连，改策略组的测速参数没有作用。若测试地址正常而业务失败，应检查 DNS、服务地区限制和协议支持。切换 Wi-Fi 与移动网络后也应重新测试，旧结果不能代表新网络的情况。

多个组都在测速，手机耗电增加

三个自动组各含三个节点、各按 300 秒探测时，如果分别执行，每轮就可能产生九次探测；提供者自己的健康检查还可能额外运行。这只是请求次数的简化计算，内核可能存在调度或复用，不能据此直接推算耗电量。手机端通常保留一种主要自动策略就够了，空闲组可考虑使用 lazy: true，并避免同时设置过密的提供者健康检查。

日常使用的起点可以很简单：外层 select 保留手动控制，内层只放一个 url-test 或 fallback。需要跨多个节点分配业务连接时，再单独增加负载均衡组。先确认规则和节点可用，再调探测参数，比一次叠加多层策略更容易定位问题。