进阶配置 预计阅读 12 分钟

Clash 策略组 url-test、fallback 与 load-balance 怎么选

逐一拆解三种自动策略组的选路逻辑、测速参数 interval 与 tolerance 的含义，并给出不同使用场景下的配置写法对照。

1. 先区分：最低延迟、优先级与连接分配

三种策略组都能容纳多个代理节点，但解决的问题不同。url-test 依据探测延迟自动选择；fallback 按列表顺序选择可用节点；load-balance 按分配算法把不同连接交给多个可用节点。选组前，先明确需要“自动择优”“主备切换”，还是“分散连接”。

类型 主要依据 适用需求 需要注意
url-test 健康检查测得的延迟 日常浏览、自动选择低延迟节点 探测快不等于下载带宽大
fallback 节点顺序与可用状态 固定主线路、备用线路接替 不会因为备用节点更快就主动择优
load-balance 连接分配策略与可用状态 多节点分担不同目标或连接 不是单连接带宽叠加

本文配置以使用 mihomo 内核的客户端为基准。旧版 Clash 与不同分支对扩展字段的支持可能不同，尤其是负载均衡算法。先在客户端“关于”或内核信息中确认内核名称，再保存并检查配置加载结果；不要仅凭客户端名称判断兼容性。

2. url-test：按探测延迟选择，使用 tolerance 减少抖动

url-test 适合没有固定出口要求的日常流量。内核通过各候选节点访问测试地址，记录探测结果，再依据可用性、延迟及切换容差选择出站。它测量的是一次特定 HTTP 请求的耗时，不是 ICMP ping，也不是持续下载测速。

基础配置：300 秒探测，50 毫秒容差

以下片段用于合并进现有配置。示例中的“香港 01”“香港 02”“日本 01”必须已经存在于 proxies 中，并与实际节点名称逐字一致；若使用订阅节点池，后文给出 use 的写法。

proxy-groups:
  - name: 自动低延迟
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false
  • interval: 300：周期性探测间隔为 300 秒，即 5 分钟，不是 300 毫秒。
  • tolerance: 50：切换容差为 50 毫秒，用于避免延迟只有小幅变化时频繁换节点。
  • lazy: false：关闭懒惰探测，使未被使用的组也能按周期更新健康状态；代价是更多探测请求。

例如，当前节点测得 110 毫秒，另一节点为 95 毫秒，差距只有 15 毫秒。设置 50 毫秒容差后，不应把这次差异理解为“必须切换”。如果候选节点降到 45 毫秒，改善幅度达到 65 毫秒，才更符合切换条件。这里的数值是参数解释示例，不是线路实测；实际结果还受探测时机、当前节点状态与内核实现影响。

延迟最低，为什么视频仍然卡顿？

小体积探测请求不能代表高峰期吞吐量。节点可能在测试地址上响应很快，却对视频服务限速，或者到目标站点的路径拥塞。遇到这种情况，应同时比较实际业务表现与连接日志，而不是把 interval 从 300 改成 5，试图靠频繁测速提高带宽。

如果低延迟节点在两个地区之间反复切换，登录站点可能观察到出口变化。可以适当提高 tolerance，或者把同一地区的节点组成独立组。需要长期固定出口的业务，则更适合手动选择或明确的主备结构。

3. fallback：按节点顺序建立主备关系

fallback 的关键是顺序。列表中的第一个可用节点具有最高优先级；它不可用时，才继续尝试后面的候选节点。主节点在健康检查中恢复可用后，后续选路可以重新回到优先级更高的节点，因此它不是“切换到备用后永远留在那里”。

proxy-groups:
  - name: 主备线路
    type: fallback
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

在这个例子中，即便“香港 01”为 180 毫秒、“香港 02”为 60 毫秒，只要前者被判断为可用，仍然优先使用“香港 01”。因此，把一条较慢但稳定的线路放在第一位是有效的主备配置，不是测速失灵。

切换时间不是固定的 60 秒

interval: 60 只规定周期性探测的间隔，不能当作故障恢复的时间承诺。故障发生在两次探测之间，可能需要等待下一次检查；单次检查本身也需要时间。连接失败触发的额外检查与相关参数，还会因内核版本和配置而不同。

  • 把业务优先使用的节点排在最前，不要按测速结果随意重排列表。
  • 主备节点尽量避免完全共享同一故障点；相同上游故障可能让全部候选同时失效。
  • 主节点失效后，已有 TCP 连接可能中断，需要应用重连；策略组不会迁移既有连接。

4. load-balance：分配不同连接，不叠加单连接速度

load-balance 会在可用候选之间进行选择，但不把一个 TCP 连接拆到多个代理节点上。单线程下载通常仍由一个出口承担；多连接下载可能使用不同节点，也受下载器、服务器、连接复用与分配算法影响，不能据此保证总速度成倍增长。

consistent-hashing：让相同目标尽量使用相同出口

proxy-groups:
  - name: 多线分担
    type: load-balance
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing 根据目标地址进行一致性哈希分配，使相同目标尽量落在同一个节点上。可用节点集合变化时，映射仍可能改变。它适合分散不同目标的访问，但不是“整个浏览器永远固定一个出口”：同一页面可能调用登录、图片、接口等多个域名。

round-robin：轮询分配新连接

将上例的 strategy 改为 round-robin，即采用轮询方式分配连接。轮询不等于按字节均分，也不会自动依据剩余流量配额分配。一个长时间下载连接与一个很快结束的网页连接，在流量体积上可能相差很大。

登录、支付或对出口变化敏感的服务，优先使用固定节点或单独的稳定策略组。已有 HTTP/2 长连接可能承载很多请求，因此也不能通过连续刷新几次网页，就断言轮询没有生效。应在连接面板检查新建连接使用的实际节点。

5. interval、tolerance 与节点池：配置边界

字段 含义 使用建议
url 健康检查的 HTTP 测试地址 选择稳定、响应体小的目标；不同组比较时保持一致
interval 探测间隔，单位为秒 日常可从 300 秒开始，主备需求可按成本缩短
tolerance url-test 的切换容差，单位为毫秒 可从 50 毫秒开始，不用于定义主备优先级
lazy 是否在组未使用时避免周期性探测 需要持续更新备用组状态时显式设置为 false
strategy load-balance 的分配算法 明确选择一致性哈希或轮询，不与测速容差混用

proxies 与 use 不要混淆

proxies 引用节点或其他策略组的名称；use 引用 proxy-providers 中定义的节点提供者。假设现有配置已经定义名为“订阅节点池”的提供者，可以这样让自动组使用它：

proxy-groups:
  - name: 订阅自动选择
    type: url-test
    use:
      - 订阅节点池
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

这不是一份可独立运行的完整配置，前提是“订阅节点池”确实存在。提供者的 interval 控制节点资源更新间隔，提供者中 health-check.interval 控制其健康检查间隔，组内 interval 则控制策略组的探测周期。几个同名字段处于不同层级，不能互相替代。

节点数量也影响成本。若一个组包含 30 个候选，每 300 秒对全部候选执行一轮探测，则每小时约有 360 次探测请求；实际次数受懒惰探测、额外检查等机制影响。把间隔缩短到 30 秒，会显著增加请求量，却不一定改善日常体验。

6. 接入规则与客户端：先验证组，再验证流量

策略组创建成功后，还需要让规则或上层手动选择组引用它。下面的组合便于比较三类行为；合并时应把这些组加入同一个 proxy-groups 列表，而不是在 YAML 顶层重复声明多个同名键。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自动低延迟
      - 主备线路
      - 多线分担
      - DIRECT

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

这个片段依赖前文三个自动组已经存在。它只演示引用关系，不是一套国内外分流方案：最后的 MATCH 会把此前未匹配的请求交给“代理出口”。已有规则应按实际用途保留，别为了测试把原来的直连规则全部覆盖。

  1. 备份配置。先导出当前配置；远程订阅更新可能覆盖直接修改的内容，需要持久保留时使用客户端支持的覆写、合并或扩展配置功能。
  2. 加载配置。检查日志是否出现未知组名、未知节点名或 YAML 缩进错误。缩进使用空格，不使用制表符。
  3. 切换规则模式。确认客户端当前使用“规则”模式；在“全局”模式下，规则列表不是验证分流路径的依据。
  4. 选择入口组。在“代理”页面找到“代理出口”，分别选择三个自动组，再执行客户端提供的“测速”或“延迟测试”。按钮名称随客户端而异。
  5. 检查连接。打开“连接”页面，确认请求命中的规则、策略链及最终节点。手动测速是即时测试，不等同于完整观察周期性健康检查。

验证主备时，可在备份后的测试配置中暂时移除首选节点，重新加载后观察下一候选是否接替。验证出口切换时应新建业务连接，避免浏览器连接池继续复用旧连接。涉及 TUN 模式的接管问题，可另行查看排查手册，先确认流量确实进入内核。

7. 按使用场景确定默认选择

  • 日常网页与一般应用：先选 url-test，以 300 秒间隔、50 毫秒容差作为调试起点，再根据实际波动调整。
  • 有固定首选线路：选 fallback，认真排列候选顺序；备用线路更低的延迟不会改变优先级。
  • 多条线路承担不同访问：选 load-balance，先考虑 consistent-hashing；确有轮询需求时再使用 round-robin。
  • 账号需要稳定出口：单独设置手动选择组与域名规则，不把这类请求混入频繁变动的自动组。

最终判断应落在“实际请求命中了什么规则、最终用了哪个节点”。延迟数字、组名中的“自动”字样以及系统代理开关，都不能替代这一步。先用少量候选验证逻辑，再扩展节点池，通常比同时修改测速间隔、DNS 与 TUN 设置更容易定位问题。

下载Clash