进阶配置 预计阅读 9 分钟

Clash 策略组 url-test、fallback、load-balance 区别与配置写法

三种自动策略组各解决什么问题:url-test 选最快、fallback 保可用、load-balance 分摊流量。逐一拆解 interval、tolerance、strategy 等参数含义,并给出可直接套用的 YAML 配置示例。

Clash 与 Clash Meta(mihomo 内核)的 proxy-groups 里,除了手动选择的 select,还提供三种自动化策略组类型:url-test、fallback、load-balance。三者都会周期性对组内节点做健康检测,但检测结果的用途完全不同——一个用来挑最快的,一个用来保证有节点能用,一个用来把流量摊开。不理解这个区别,直接抄网上的配置片段,很容易出现"明明配了自动测速,结果一直用着同一个慢节点"之类的困惑。这篇文章按类型逐一拆解参数,并给出可以直接套用的 YAML 写法。

三种自动策略组解决的问题不同

先明确一个前提:这三种策略组都需要组内至少两个可用节点才有意义,单节点组内它们和 select没有区别。它们的核心差异在于"选中哪个节点"的判断逻辑:

  • url-test:定期给组内每个节点发测速请求,选延迟最低的一个作为当前出口。目标是"总是用最快的那条线"。
  • fallback:按配置里节点的顺序依次检测可用性,用第一个检测通过的节点,只有当前节点失败才切换到下一个。目标是"保证有节点能连上",不追求最快,追求稳。
  • load-balance:不做"哪个最好"的判断,而是把不同请求按算法分散到组内多个节点上,目标是"把流量摊开",避免单一节点长期承压或被针对性限速。

选哪种类型,取决于你更看重延迟、稳定性,还是流量分摊,三者不能互相替代。

url-test:延迟优先的自动选路

url-test 是最常用的自动策略组类型,适合"手上有一批节点,不想手动切换,只想始终用延迟最低的那个"的场景。典型写法:

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 香港01
      - 新加坡02
      - 日本03
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

关键字段说明:

  • url:测速请求的目标地址,通常用国外可访问的轻量接口,请求成功即视为节点可用,响应耗时即视为延迟值。
  • interval:测速周期,单位秒。周期太短会增加节点的探测负载,太长则延迟变化后切换不及时,常见取值在 180~600 之间。
  • tolerance:容差值,单位毫秒。只有新测得的延迟比当前节点低出这个容差,才会触发切换。设置容差是为了避免节点延迟在几毫秒内抖动就频繁切换出口,导致连接反复中断。
  • lazy:为 true 时,只有该策略组被实际使用时才执行定时测速,组未被选中则暂停探测,减少不必要的请求。
提示

url-test 组切换节点时,已建立的 TCP/UDP 连接不会被打断,只有新发起的连接会走新选中的节点。如果观察到下载中的文件"卡一下",通常不是策略组切换导致的,更可能是节点本身波动。

fallback:保证可用性的备用切换

fallback 的定位是"主备"而非"择优"。它按 proxies 列表里的顺序,从第一个开始检测,只要当前使用的节点还能连通,就不会主动切到后面延迟更低的节点。只有当前节点检测失败时,才会依次向后寻找第一个可用的节点。写法示例:

proxy-groups:
  - name: 备用链路
    type: fallback
    proxies:
      - 主节点-上海中转
      - 备节点-东京直连
      - 备节点-首尔直连
    url: http://www.gstatic.com/generate_204
    interval: 180

fallback 没有 tolerance 参数,因为它本身不比较延迟高低,只判断"通"或"不通"。这种类型适合对连接稳定性要求高、不希望节点频繁切换的场景,例如长期挂在后台的下载任务或需要保持会话的服务。列表顺序即优先级顺序,把最稳定、最看重的节点放在最前面。

load-balance:多节点分摊流量

load-balance 不追求"选最优",而是把不同的请求分配到组内多个节点上,常用于同时挂多个规格相近的节点、希望流量分摊以避免单节点长期高负载的场景。配置示例:

proxy-groups:
  - name: 负载均衡
    type: load-balance
    proxies:
      - 节点A
      - 节点B
      - 节点C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

strategy 决定分配算法,常见两种:

  • consistent-hashing:按源地址与目标地址的哈希值分配节点,同一个连接会话在有效期内固定走同一个节点,适合需要会话保持的场景(例如某些登录状态依赖出口 IP 一致的网站)。
  • round-robin:按顺序轮流分配,新连接依次分给下一个节点,分配更均匀,但不保证同一目标始终走同一节点。

load-balance 同样会周期性检测节点可用性,失效的节点会被临时排除在分配范围之外,等恢复后再重新纳入。它和 url-test 的本质区别是:url-test 永远只用"当前最优"的一个节点,load-balance 是同时用多个节点分担请求。

参数含义速查与常见误区

参数适用类型作用
url三者通用健康检测请求地址,响应成功判定节点可用
interval三者通用检测周期,单位秒
tolerance仅 url-test延迟容差,避免节点抖动导致的频繁切换
lazy仅 url-test策略组未被使用时暂停定时检测
strategy仅 load-balance流量分配算法:一致性哈希或轮询

几个容易踩的坑:

  1. fallback 组里节点顺序写反,导致优先用了延迟更高的备用节点——fallback 不比较延迟,只看列表顺序和当前节点是否失效。
  2. 把 tolerance 设为 0,会导致 url-test 组只要新的一轮测速里有任何节点比当前节点快 1 毫秒就切换,出口频繁跳动,建议至少保留 30~50 毫秒的容差。
  3. load-balance 里塞进延迟差异很大的节点(比如把高延迟中转节点和低延迟直连节点混在一组),分摊流量后整体体验反而不如挑单个最优节点,更适合放规格相近的节点。
  4. interval 设置过短(例如 10 秒以内),会让节点探测请求变得频繁,部分机场或自建节点服务端可能因此限流,建议不低于 120 秒。

三种策略组该怎么选

如果只能记一句话:优先延迟就用 url-test,优先稳定就用 fallback,优先分摊就用 load-balance。实际使用中,也可以把三者组合起来——例如用 url-test 组作为日常出口,再单独建一个 fallback 组挂着几个稳定的直连节点,专门给需要长连接的场景(如下载工具、远程桌面)通过规则单独分流过去,兼顾速度与稳定性。策略组类型选定后,再配合规则集把不同域名/应用分流到不同策略组,才是完整的分流逻辑,策略组本身只解决"这一类流量该走哪个/哪些节点"的问题。

下载客户端