进阶配置 预计阅读 12 分钟

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

逐个拆解三种自动策略组的测速逻辑、切换时机与 interval、tolerance 等字段，附 YAML 示例与各自适合的使用场景。

三种策略组的选择依据

Clash 的自动策略组解决的是“这条连接从哪个节点出去”，不是让每个应用都自动获得更高带宽。url-test 比较探测延迟，fallback 保持节点优先顺序，load-balance 将不同连接分配给可用节点。先确定需要低延迟、固定主备还是分散连接，再调整配置字段。

策略逻辑由内核运行。客户端负责导入订阅、展示测速结果和提交选择；不同客户端即使按钮名称相似，所用内核及支持的字段也可能不同。下面的 YAML 以 mihomo，也就是 Clash Meta 后续使用的内核名称，对应的配置能力为准。其他 Clash 内核是否接受相同字段，应以其配置文档与加载日志为准。

策略类型 选择依据 典型用途 注意事项
url-test 健康检查延迟与切换容差 网页、交互请求的低延迟出口 延迟较低不代表下载带宽较高
fallback 列表中靠前且可用的节点 固定主线路与备用线路 主节点仍可用时，不因备用更快而切换
load-balance 分配策略与节点可用状态 多个任务、多个目标的连接分散 不把单条连接拆成多条线路叠加带宽

url-test：按探测延迟自动选择

url-test 通过各候选节点访问指定测试 URL，记录探测延迟，再从可用候选中选择出口。这里的“测速”是一次请求的延迟探测，不是持续下载测试。结果会受到本机网络、节点到目标站点的线路、DNS、连接建立及服务端响应等因素影响。

interval 与 tolerance 的分工

  • interval: 300：周期性健康检查的间隔为 300 秒，即 5 分钟。它不是连接超时时间。
  • tolerance: 50：延迟切换容差为 50 毫秒。用于减少候选节点仅略快时的频繁改选。
  • timeout: 5000：单次健康检查的超时上限为 5000 毫秒。超过上限的探测可能被判为失败。
  • lazy: false：不因策略组闲置而暂停周期性健康检查，便于观察连续探测结果。

例如，假设当前节点测得 120 毫秒，另一节点测得 95 毫秒，两者只相差 25 毫秒，设置 50 毫秒容差时不应期待仅凭这点优势就改选。若另一节点降到 60 毫秒，差距达到 60 毫秒，才具备超过该容差的条件。以上数字用于解释配置，不是线路实测；最终选择还受节点存活状态与内核实现影响。

proxy-groups:
  - name: 自动延迟
    type: url-test
    proxies:
      - 香港-A
      - 香港-B
      - 日本-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: false

测试地址应能通过每个候选节点访问，且响应体较小、行为稳定。示例 URL 用于连通性探测，并不代表它能反映所有网站的访问质量。若主要使用某个业务站点，应同时验证该站点的实际请求；不要把登录页、验证码页或大文件地址直接用作周期性探测目标。

fallback：按列表顺序保留主备线路

fallback 不以最低延迟作为主要目标，而是从候选列表中选择靠前且通过健康检查的节点。适合希望日常保留同一出口，仅在主线路失效时启用备用线路的场景。

proxy-groups:
  - name: 主备线路
    type: fallback
    proxies:
      - 香港-A
      - 日本-A
      - 香港-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: false

故障切换与恢复顺序

  1. “香港-A”通过检查时，优先使用它，即使“日本-A”的探测延迟更低。
  2. “香港-A”被判定不可用后，选择下一条可用的“日本-A”；它也不可用时，再检查“香港-B”。
  3. 后续健康检查确认“香港-A”恢复后，策略可重新优先选择它，后续连接可能回到主线路。

因此，fallback 表示按优先级选择，不等于“切到备用后一直留在备用”。如果业务要求人工确认后才回切，应使用手动 select 组管理出口，不能只依靠自动主备组实现这个流程。

故障也不会总在发生的同一秒被发现。仅考虑周期性检查时，线路可能在一次成功探测后立即断开，随后等待下一轮检查及超时判定。其他失败触发机制取决于内核配置，不能把 interval: 300 解读为即时切换承诺。

备用线路应尽量具有独立的故障来源。两个名称不同、实际共用同一上游出口的节点，可能同时失效。对重要任务，可分别检查本地接入网络、节点可用性与目标服务状态，避免把目标站点自身故障误判成主节点故障。

load-balance：分配连接而非合并带宽

load-balance 在可用节点之间分配连接。多个网页、下载任务或不同目标的请求可以落到不同出口，但一条既有 TCP 连接仍使用选定节点。浏览器显示的总下载速度是否提高，取决于任务并发、服务器限制以及各节点是否共享带宽。

proxy-groups:
  - name: 分散连接
    type: load-balance
    proxies:
      - 香港-A
      - 香港-B
      - 日本-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: false
    strategy: consistent-hashing

consistent-hashing 与 round-robin

strategy 分配方式 适用边界
consistent-hashing 按目标相关信息进行一致性哈希，使相同目标倾向于同一出口 希望减少同一站点跨节点访问时优先考虑
round-robin 新连接在可用候选间轮换分配 适合可容忍出口变化的独立并发任务

一致性哈希不是永久绑定。候选节点数量或健康状态变化后，映射可能改变；域名是否可用、目标如何被识别，也会影响分配。一个页面还可能请求多个不同域名，因此“同一个页面”不等于“所有请求都使用同一个出口”。

mihomo 还提供 sticky-sessions 策略，用于按来源与目标相关信息保持一段时间的分配黏性。需要使用时，应确认当前内核支持并核对其行为；不要把扩展字段直接复制到未确认兼容性的旧内核配置里。

登录与长会话的出口安排

银行、支付、企业认证或对出口 IP 敏感的服务，更适合分流到固定节点或手动组。负载均衡可能让同一账户的不同连接使用不同公网地址，引起重新验证。即使采用一致性哈希，也应把相关域名作为一组检查，而不是只测试首页。

策略组接入规则与订阅覆写

定义组不等于流量已经进入该组。规则模式下，连接先按 rules 从上到下匹配，再由命中的规则指定节点或策略组。客户端的系统代理、TUN 与规则匹配属于不同层次：前两者决定流量怎样进入内核，策略组决定进入后的出口选择。

可以将三种自动组放进一个手动入口，在客户端选择需要的策略。下面片段以已经定义好的三个自动组为前提；组名可以自定，但引用必须一致，也不能让组之间形成循环引用。

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - 自动延迟
      - 主备线路
      - 分散连接

rules:
  - DOMAIN-SUFFIX,example.com,主备线路
  - MATCH,出口选择

example.com 是用于演示规则结构的保留示例域名。这段规则说明特定域名可以固定交给主备组，其余连接再由“出口选择”处理；不是建议覆盖现有订阅的全部规则。MATCH 是兜底规则，应放在需要优先匹配的规则之后。

订阅更新后的配置保留

  • 直接修改订阅下载得到的 YAML，下一次更新可能覆盖修改。先确认客户端是否支持持久化覆写或配置合并。
  • 使用客户端覆写功能时，检查数组是整体替换、追加还是按名称合并。不同客户端的实现不能互相套用。
  • 使用 proxy-providers 时，策略组通常通过 use 引用提供器。提供器自己的健康检查与组的候选管理需要一并核对。
  • 订阅端修改节点名称后，静态 proxies 引用可能失效。更新后检查加载日志和组内候选列表。

通用字段与规则顺序可继续查阅 YAML 手册的策略组说明。涉及流量接入方式时，再对照 TUN 配置教程，不必为了更换策略组而同时改动所有网络设置。

自动切换异常的检查顺序

测速正常，但下载速度慢

先区分延迟和吞吐量。健康检查只请求一个小资源，无法测出晚高峰拥塞、持续传输限速或单连接带宽。固定同一个下载目标与测试时段，手动选择候选节点比较持续速度；不要单凭 80 毫秒和 100 毫秒的差异判断哪条线路下载更快。

节点已经断开，却没有切换

  1. 检查当前模式是否为规则模式，并在连接记录中确认实际命中的规则和最终出口。
  2. 确认应用流量确实进入 Clash。终端工具可能需要单独设置代理环境变量，并不一定遵循 macOS 系统代理。
  3. 检查 url 是否通过节点测试、interval 是否过长，以及组是否因懒检查而没有按预期持续探测。
  4. 重新建立一条测试连接，区分“新连接仍未切换”和“旧连接仍然保留”。

url-test 频繁改选

先记录多个检查周期的延迟变化，再调整容差。可以从 interval: 300 与 tolerance: 50 这样的起点观察，不必将间隔压到几秒。若候选节点只有轻微抖动，适当增加容差有助于减少改选；若测试地址本身不稳定，应先更换合理的探测目标。

所有节点同时显示不可用

优先检查测试 URL 的可访问性、DNS 解析、本地网络和订阅凭据，而不是立即重装客户端。用同一节点访问其他已知可用的小页面，再对比日志中的超时、解析失败或连接拒绝。所有候选同时失败，可能是共同依赖故障，而不是每条远端线路都同时中断。

配置验证与日常选用

网页浏览和交互请求可先用 url-test；有明确主线路、希望备用接管时使用 fallback；多个独立任务需要分散出口时再考虑 load-balance。单个账户需要稳定公网地址时，固定节点或手动选择通常更容易控制。

  1. 保存原配置。保留可以回退的副本，先只修改策略组，不同时调整 DNS、TUN 栈和全部规则。
  2. 确认配置已加载。在客户端日志中排除未知字段、节点名称不存在和组循环引用等错误。
  3. 验证实际出口。发起新请求，在连接记录里查看命中规则、策略链和最终节点，不只看组标题。
  4. 观察至少两个周期。设置 300 秒间隔时，给健康检查留出相应时间；手动测速只能说明当次结果。
  5. 受控测试备用。在可恢复的环境中模拟主节点不可用，再恢复，分别观察后续连接的切换与回切。

策略组配置的重点是让选择规则符合业务需求。延迟、可用性、出口稳定性和并发分配是不同指标；把它们分开验证，比反复点击测速或盲目缩短检查间隔更容易定位问题。

下载Clash