Clash 策略组类型详解：url-test、fallback 与 load-balance 区别

策略组如何参与 Clash 规则分流

Clash 配置中的代理节点负责建立实际连接，规则负责判断流量属于哪一类，策略组则位于两者之间，决定某一类流量最终交给哪个节点。规则中的目标通常不是直接写某个节点名称，而是引用一个策略组，例如将办公域名交给“工作服务”、将流媒体域名交给“媒体服务”，再由组内的选择逻辑处理节点切换。

url-test、fallback 与 load-balance 都属于自动策略组，但“自动”并不表示它们会做出相同选择。三者分别对应延迟优选、按顺序故障接管和多节点连接分配。若只看节点列表而忽略组类型，同一批节点可能产生完全不同的访问表现。

proxy-groups:
  - name: 工作服务
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,example.com,工作服务
  - MATCH,工作服务

以上配置中，规则只负责把匹配到的连接送入“工作服务”。真正决定使用节点 A、B 还是 C 的，是 url-test 的测速结果与切换参数。策略组不是一条额外的网络隧道，也不会改变节点自身的协议、加密方式或服务器线路；它只是组织节点并执行选择。

健康检查在自动策略组中的作用

自动组通常需要定期通过每个候选节点访问一个测试 URL。内核根据请求是否成功、响应耗时以及连续检查结果维护节点状态。测试 URL 应当稳定、响应体较小，并尽量贴近实际网络出口。常用的 204 响应地址适合测量基础连通性，但如果配置主要服务于特定业务，也可以使用自己能够长期控制的轻量地址。

interval 表示检查间隔，单位通常为秒。间隔太短会增加节点与设备的额外请求，移动网络下还可能频繁唤醒连接；间隔太长则会延迟发现线路故障。桌面常驻环境可从 300 秒左右开始观察，网络波动明显或节点数量很多时，再结合实际需求调整。

url-test：按健康检查延迟选择节点

url-test 会测试组内节点，并优先选择当前可用节点中测得延迟较低的一项。它适合成员线路功能接近、用户更关心响应速度的场景，例如多个相同地区出口、多个都能访问同一业务的节点，或日常网页与代码仓库访问。

这里的“延迟最低”只针对健康检查请求，不等同于下载速度最高。小型 HTTP 请求主要反映握手、往返时间和线路当前可达性，无法完整代表大文件吞吐、晚高峰拥塞或目标站点到出口服务器的带宽。因此，url-test 更准确的理解是“从测试结果中选择响应较快的健康节点”，而不是持续进行带宽竞速。

tolerance 如何减少来回切换

网络延迟本身会抖动。若节点 A 测得 82 毫秒，节点 B 测得 76 毫秒，仅凭 6 毫秒差距立即切换，通常不会带来可感知提升，却可能让新连接换到另一个出口。tolerance 用于设置可容忍的延迟差，在当前节点与候选节点差距未超过阈值时维持现有选择。

- name: 日常低延迟
  type: url-test
  proxies:
    - 香港-01
    - 香港-02
    - 新加坡-01
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 100
  lazy: true

在支持这些字段的 mihomo 配置中，lazy: true 可用于减少策略组长期未被使用时的检查活动；当组开始承载流量后，内核再按机制更新状态。具体触发行为可能随内核版本变化，使用前应以当前版本文档和运行日志为准。

url-test 的适用边界

适合：候选节点用途一致，地区差异不会改变网站内容或账号风控结果。
适合：网页浏览、接口请求等更依赖响应延迟的连接。
需要谨慎：必须保持固定出口 IP 的登录、支付、远程办公或白名单业务。
不宜只看测速：大文件下载、视频高码率传输和持续上传还取决于带宽与丢包。

如果业务要求会话期间尽量保持同一出口，可以提高 tolerance、减少成员范围，或者在自动组外再增加一个 select 手动选择组。这样既能保留自动优选入口，也能在特定时间固定使用某个节点。

fallback：按节点顺序执行故障接管

fallback 的核心不是比较谁最快，而是按照配置顺序使用第一个健康节点。只要排在前面的节点仍通过健康检查，后面的节点即使延迟更低，通常也不会取代它；当前置节点不可用时，策略组才会依次寻找下一个可用成员。

这种行为适合主备关系明确的环境。例如主节点拥有固定出口、专用线路或更符合业务地区要求，备用节点只在主线路故障时接管。与 url-test 相比，fallback 的决策更容易预测：节点排列本身就是优先级列表。

- name: 办公主备
  type: fallback
  proxies:
    - 办公主线路
    - 办公备用线路
    - 临时应急线路
  url: https://www.gstatic.com/generate_204
  interval: 180
  lazy: false

上例会优先使用“办公主线路”。当该节点健康检查失败时，才尝试“办公备用线路”，之后才是“临时应急线路”。如果主线路后续恢复并重新被判定为健康，策略组可能回到更靠前的节点。恢复判定和既有连接是否立即迁移，需要区分看待：策略组选择影响的是后续连接，已经建立的 TCP 或 UDP 会话未必能够无感转移。

节点顺序比延迟数字更重要

配置 fallback 时，应先根据业务优先级排列节点，再考虑测速结果。主线路应当是长期希望使用的线路，备用线路则需要具备相同的关键访问能力。如果备用节点无法访问主业务，即使健康检查 URL 返回正常，也无法完成真正的接管。

对于地区敏感服务，不建议把不同地区节点随意混在一个 fallback 组中。更稳妥的方法是先建立地区内部主备组，再把地区组交给上层手动选择。例如“日本主备”只包含日本节点，“新加坡主备”只包含新加坡节点，用户在最外层决定所需地区。这样发生故障时，出口地区不会因为自动接管而意外变化。

适合 fallback 的典型情况

远程办公服务要求优先使用已经加入访问白名单的固定出口。
主线路质量稳定且成本明确，备用线路仅承担故障期间流量。
不同节点之间存在清晰的可靠性排序，而不是单纯比较瞬时延迟。
希望自动恢复基本连通性，同时保持选择逻辑容易审计和解释。

load-balance：把新连接分配给多个节点

load-balance 会让组内多个健康节点共同承载连接。它的目标不是选出一个永久胜者，而是依据负载均衡策略，为不同连接确定出口。适合存在大量相互独立请求、多个节点能力接近，并且业务允许使用多个出口的环境。

需要注意，Clash 的负载均衡通常以连接或目标为决策对象，并不是把同一个 TCP 连接拆分到多台代理服务器。单个大文件下载若只建立一条连接，速度仍受该连接所选节点限制；只有应用产生多条并发连接时，才可能让多个节点分别承担其中一部分。

- name: 多节点分配
  type: load-balance
  proxies:
    - 节点-A
    - 节点-B
    - 节点-C
  url: https://www.gstatic.com/generate_204
  interval: 300
  strategy: consistent-hashing

consistent-hashing 与 round-robin

mihomo 支持的具体均衡策略应以所用版本为准。常见的 consistent-hashing 会根据目标信息进行相对稳定的映射，使相同或相关目标更可能继续落到同一个节点。它有助于减少访问同一站点时出口频繁变化，适合网页包含多个资源请求、站点对会话来源较敏感的情况。

round-robin 倾向于按顺序轮换可用节点，让连续的新连接分布到不同成员。它的流量分散更直观，但同一网站的多个连接可能使用不同出口。若站点根据来源 IP 维护登录状态或执行安全检查，这种变化可能带来重复验证、会话失效或内容地区不一致。

部分 mihomo 版本还提供其他策略选项，其字段与行为可能发生调整。迁移配置时，不应因为旧文件能够被解析，就默认所有策略语义完全一致。应查看启动日志中的配置警告，并通过连接详情确认实际命中的节点。

负载均衡不适合所有业务

账号登录、网银、企业身份认证等需要稳定出口的服务，应优先使用固定节点、select 或按目标稳定映射的方案。
节点出口地区不一致时，搜索结果、媒体目录、货币单位和页面区域设置可能随连接变化。
节点性能差异很大时，均匀分配连接不代表均匀分配带宽，较慢节点仍会拖累部分请求。
移动网络频繁切换、设备资源有限或节点数量过多时，健康检查和并发连接会产生额外开销。

url-test、fallback 与 load-balance 核心区别

比较项	url-test	fallback	load-balance
主要目标	选择测试延迟较低的健康节点	优先使用列表中靠前的健康节点	让多个健康节点共同承载新连接
节点顺序作用	通常不是主要选择依据	直接表示主备优先级	作用取决于均衡策略
切换原因	延迟差超过容忍范围或当前节点失效	前置节点失效，或更高优先级节点恢复	新连接按策略分配，节点失效后排除
出口稳定性	中等，可通过 tolerance 降低切换	较高，主节点健康时保持优先	取决于哈希或轮询方式
常见用途	网页、接口、同地区低延迟选择	办公主备、固定地区故障接管	多连接下载、并发请求分散

按需求选择，而不是按名称选择

选择策略组时，可以先回答三个问题。第一，业务是否要求固定地区或固定出口；第二，节点故障时是否允许自动切到任意可用节点；第三，是否真的需要多个节点同时承载连接。如果必须维持主出口并只在故障时切换，fallback 更直接。如果节点等价且优先考虑响应速度，url-test 更合适。如果请求量大、连接彼此独立且来源变化可接受，再考虑 load-balance。

一个配置不必只使用一种自动组。实际方案可以分层组合：底层用 fallback 组织每个地区的主备节点，中层用 url-test 在若干等价地区组之间选取响应较好的入口，顶层用 select 允许用户手动固定策略。策略组嵌套能够表达更清晰的业务边界，但层级过多也会增加排查难度，应让组名准确反映用途。

proxy-groups:
  - name: 香港主备
    type: fallback
    proxies:
      - 香港主线路
      - 香港备用线路
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 新加坡主备
    type: fallback
    proxies:
      - 新加坡主线路
      - 新加坡备用线路
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 自动区域
    type: url-test
    proxies:
      - 香港主备
      - 新加坡主备
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 120

  - name: 最终选择
    type: select
    proxies:
      - 自动区域
      - 香港主备
      - 新加坡主备
      - DIRECT

配置策略组的完整检查步骤

一、确认内核、客户端与配置字段

Clash 原版、Clash Meta 与后续 mihomo 分支在功能范围和字段支持上存在差异，图形客户端也可能对策略组提供不同的编辑界面。订阅中出现某个字段，不代表当前内核一定支持。导入配置后应查看内核启动日志，确认没有未知字段、策略类型错误或代理名称引用失败。

若客户端允许切换内核，需要确认实际运行的是哪一个核心，而不是只根据客户端名称判断。某些客户端还会在订阅更新时重新生成配置，手动修改的策略组可能被覆盖。长期使用的自定义规则与策略，适合通过客户端支持的覆写、扩展配置或配置合并功能维护。

二、检查代理名称与缩进

YAML 对缩进敏感，策略组中的 proxies 成员名称必须与代理节点或其他策略组名称完全一致。中文、空格和符号本身可以用于名称，但复制时要避免多余空格。若一个组引用另一个组，还要避免形成循环引用。

proxies:
  - name: 节点-A
    type: ss
    server: server.example
    port: 443
    cipher: aes-128-gcm
    password: example-password

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

三、验证健康检查而不是只看图标

客户端显示的延迟数字可能来自手动测速，也可能来自策略组健康检查，两者测试地址和时间点未必相同。遇到节点显示可用但网站打不开时，应查看连接日志，确认规则命中了哪个策略组、策略组实际选中了哪个节点，以及请求失败发生在 DNS、连接建立还是目标服务器响应阶段。

如果所有成员同时超时，优先检查测试 URL 是否能在当前网络访问、DNS 是否返回异常结果、系统时间是否准确，以及节点本身是否能够建立连接。不要立即通过缩短 interval 反复测速，因为测试频率增加并不能修复基础连通问题。

四、结合系统代理与 TUN 模式验证

策略组只有在流量进入 Clash 内核后才会生效。系统代理主要接管遵循操作系统代理设置的应用；不读取系统代理的程序、部分游戏和特定 UDP 流量，可能需要 TUN 模式才能进入规则链。若浏览器能按预期切换节点，而某个应用始终直连，应先确认流量是否被接管，而不是先修改策略组。

启用 TUN 模式后，还要关注 DNS 模式、路由排除和局域网访问。错误的 DNS 配置可能让域名规则无法按预期匹配，路由排除则可能让目标流量绕过内核。排查时可以选择一个明确的测试域名，依次检查 DNS 解析、规则匹配、策略组选择、节点连接和目标响应。

五、处理订阅更新后的节点变化

订阅提供方可能新增节点、修改名称或移除旧节点。若策略组通过静态名称列出成员，名称变化后会出现引用失效。mihomo 配置也可以通过代理集合与筛选规则动态组织订阅节点，但筛选表达式需要谨慎设计，避免把“剩余流量”“套餐信息”等非节点条目纳入自动组。

使用动态筛选时，可以按地区和用途分别建立集合，并为每组保留清晰边界。例如低延迟组只包含同一业务可接受的地区，主备组只包含确实具备接管能力的线路。节点数量不是越多越好；候选成员过多会延长健康检查列表，也会让异常节点更难定位。

稳定策略组的实践建议

让组名表达决策逻辑。“香港主备”“低延迟自动”“下载均衡”比“代理组 1”更便于查看连接记录。
把业务边界放在速度之前。先确保候选节点都能满足地区、账号和协议要求，再比较延迟或分配连接。
为自动切换保留缓冲。url-test 设置合理 tolerance，避免因微小延迟波动频繁更换出口。
不要用 load-balance 代替测速。它用于分配连接，并不保证每条连接都落到最快节点。
定期查看实际命中。通过客户端连接页面确认域名规则、策略组和最终节点是否符合预期。
修改后进行分层测试。先验证节点单独可用，再验证健康检查，之后检查规则命中，最后测试真实业务。

概括而言，url-test 解决“哪条健康线路当前响应更快”，fallback 解决“主线路故障后由谁接管”，load-balance 解决“如何让多个健康节点参与承载连接”。只要先明确业务需要的是速度、优先级还是连接分散，再设置健康检查、切换阈值和规则入口，Clash 的自动分流就能保持清晰且可预测。