Clash 策略组怎么选:url-test、fallback、load-balance 三种类型详解

策略组在配置文件里的位置

Clash 的节点分流依赖 proxy-groups 这一段配置。它把 proxies 里罗列的具体节点打包成一个个"逻辑出口",规则段 rules 引用的正是策略组的名字,而不是某个具体节点。这样做的好处是:换机场、换节点都只需要改 proxies 和 proxy-groups,规则本身不用动一行。

每个策略组必须声明一个 type,这决定了客户端在这个组里"怎么选节点"。常见的四种类型是 select(手动选择)、url-test(自动测速)、fallback(故障转移)、load-balance(负载均衡)。select 最简单,完全靠人手切换,不在本文讨论范围;后三种都带"自动决策"逻辑,也是最容易被误用的三类,下面逐一拆开讲。

url-test:延迟驱动的自动测速

url-test 是三种自动类型里最常见的一种。它的工作方式可以概括为:客户端按固定周期向组内每个节点发起一次 HTTP 请求(目标地址由 url 字段指定),记录往返延迟,然后始终把流量导向当前测得延迟最低的节点。

关键字段说明:

url:测速目标地址,通常填一个国外可达、响应快的地址,例如连通性检测常用的轻量接口;
interval:测速周期,单位秒,常见取值 300(5 分钟)左右,过短会增加节点侧压力,过长则延迟变化响应不及时;
tolerance:切换容差,单位毫秒。只有当新节点的延迟比当前节点低出这个容差值,客户端才会真正切换,避免延迟在两个节点之间来回抖动导致连接频繁重建;
lazy(Clash Meta/mihomo 支持):开启后,只有在实际发起请求时才会触发测速,而不是无论有没有流量都按周期空跑,适合长期挂机、连接数不高的场景。

适用场景很明确:机场提供的是同质化的中转节点(比如都是同一线路的多个出口),你不关心具体走哪条线,只要延迟最低即可。缺点也在于此——url-test 只看延迟,不看丢包率和真实吞吐,某些节点延迟低但限速严重,测速阶段完全看不出来。

fallback:按顺序探测的故障转移

fallback 的逻辑和 url-test 完全不同。它不比较延迟高低,而是严格按照 proxies 列表里节点的先后顺序逐一探测可用性:第一个节点只要能连通(探测请求成功),就一直用它;只有当前使用的节点探测失败,才会顺位切换到下一个还能连通的节点。

这意味着 fallback 天生带"主备"语义——你需要提前规划好节点顺序,把最想用的主节点放在最前面,备用节点依次排在后面。它的关键字段和 url-test 基本一致(url、interval、tolerance),但 tolerance 在 fallback 里的作用较弱,因为切换判断依据是"能不能连通"而不是"延迟差多少"。

典型使用场景:你有一个稳定的自建节点作为主力,同时保留一两个机场节点作为兜底,平时希望流量优先走自建节点,只有自建节点出问题(断线、被限速到无法访问)时才自动转移到备用线路。这种"有主有备、按需接管"的诉求,fallback 比 url-test 更贴切——url-test 会因为备用节点某一次测速延迟更低就切过去,而 fallback 不会,只要主节点还通,它就不动。

注意:fallback 组里节点的书写顺序就是优先级顺序,调整顺序需要直接编辑 proxies 引用列表,客户端界面上通常没有"设为主节点"这类操作入口。

load-balance:分摊连接的负载均衡

load-balance 解决的是另一类问题:当组内多个节点性能相近、都可用,你希望把并发连接分摊到多个节点上,而不是所有流量挤在一个节点上跑。它的核心字段是 strategy,常见取值两种:

consistent-hashing:按请求的目标地址做一致性哈希,同一个目标域名/IP 大概率固定分配到同一个节点,这样能减少因为节点切换导致的连接中断,对需要保持会话一致性的场景(比如视频播放、下载中的大文件)更友好;
round-robin:按轮询顺序依次把新连接分配给组内节点,分配更均匀,但同一个目标地址前后两次请求可能落到不同节点上。

load-balance 同样支持 url 和 interval 做健康探测,探测到不可用的节点会被临时从分配池里剔除,等恢复可用后再重新纳入。需要强调的是,load-balance 分摊的是"连接数",不是实时限速意义上的"带宽",如果组内某个节点本身带宽上限很低,分到它头上的连接依然会慢,负载均衡不会替你补齐单节点的性能短板。

三种类型该怎么选

把三者放在一起对比,选型思路可以简化成一句话:看你要解决的是"选最快的"、"保主备"还是"摊并发"。

组内节点线路相近、纯粹想要延迟最优 → 用 url-test;
有明确的主用节点和备用节点,希望优先用主节点、故障才切换 → 用 fallback;
组内节点数量较多、想把并发连接摊开避免单点过载 → 用 load-balance;
只是想自己手动切、不需要任何自动逻辑 → 用最基础的 select。

实际配置中,这几种类型经常是嵌套使用的:外层用 select 让用户在"自动测速""固定线路""全部节点手选"之间切换,内层的"自动测速"选项本身又是一个 url-test 组,这样既保留了自动化,又不失去手动兜底的灵活性。

可直接套用的配置片段

以下是三种类型各自的最小可用配置示例,可以按需替换 proxies 里的节点名称后直接粘贴到 config.yaml 的 proxy-groups 段落里。

proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - "节点A"
      - "节点B"
      - "节点C"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "主备切换"
    type: fallback
    proxies:
      - "自建主节点"
      - "机场备用1"
      - "机场备用2"
    url: "https://www.gstatic.com/generate_204"
    interval: 180

  - name: "均衡分流"
    type: load-balance
    proxies:
      - "节点A"
      - "节点B"
      - "节点C"
      - "节点D"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

Clash Meta(mihomo)内核在此基础上额外支持 max-failed-times(连续探测失败多少次才判定为不可用,用于减少偶发网络抖动导致的误判)和 lazy 参数,如果客户端标注支持 Meta 内核规则集,可以按需加入这两个字段进一步调优,原版 Clash 内核不识别这些字段,写了也不会报错,但不会生效。

常见误区与排查建议

配置策略组时最容易踩的几个坑:

把延迟差异很大的节点混进同一个 load-balance 组——负载均衡不挑延迟,慢节点照样会分到连接,体验反而不如 url-test;
fallback 组里节点顺序写反,主力节点排在了后面,导致平时优先用的是备用线路;
url-test 的 tolerance 设得过小(比如 0 或 5ms),节点延迟本身就有波动,容差太小会导致频繁切换,连接被反复打断;
测速地址 url 选用了国内可直连的地址,导致所有节点测出来延迟都接近,失去了区分节点优劣的意义。

建议:调整策略组类型或参数后,先用客户端自带的延迟测试面板观察一轮实际切换行为,确认符合预期再长期使用,避免线上使用中才发现频繁跳线的问题。

把策略组类型和参数配对好之后,规则段的编写会顺畅很多——因为规则只需要关心"该走哪个策略组",具体走哪个节点、什么时候切换,已经交给策略组自己的判断逻辑处理了。这也是 Clash 分流体系里规则和节点解耦的核心价值所在。