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

三种策略组如何选择

需要自动选择低延迟出口，用 url-test；需要固定主备顺序，用 fallback；需要把不同连接分配给多个出口，用 load-balance。三者都属于策略组，不是代理协议，也不会创建新的节点。组内必须引用已经存在的代理节点或兼容的策略组。

Clash 是一类规则代理内核及其客户端生态的常用称呼，Clash Meta 后续以 mihomo 名称维护。客户端外观相似，不代表使用相同内核。本文的 YAML 示例以 mihomo 为目标；旧版 Clash 内核对可选字段和均衡算法的支持可能不同，应以实际内核文档及配置检查结果为准。

类型	选路依据	适用场景	主要限制
`url-test`	探测结果与切换容差	日常浏览，自动选择较低延迟节点	探测延迟不代表下载带宽
`fallback`	列表中优先级最高的可用成员	主线路优先，失效后使用备用线路	主线路较慢但仍可用时通常不切换
`load-balance`	可用成员与指定分配算法	多个目标或连接分摊到不同出口	不是把单条连接的带宽相加

url-test：按探测延迟选路

url-test 通过各成员访问指定 URL，记录探测结果，再据此选择出口。它适合节点质量随时间变化、又不希望频繁手动切换的场景。这里测量的是到探测目标的一次请求耗时，不是本地到节点服务器的单纯 ICMP 延迟。

interval 与 tolerance 的单位不同

interval: 300：自动健康检查间隔为 300 秒，即 5 分钟，不是 300 毫秒。
tolerance: 50：切换容差为 50 毫秒，用于减少延迟小幅波动引起的反复切换，不是探测超时。
url：健康检查使用的 HTTP 或 HTTPS 地址。它应稳定、响应内容少，并且各成员都能访问。
lazy: false：关闭惰性检查，便于在验证阶段持续观察检查结果；节点较多时会增加后台探测请求。

例如当前出口探测为 120 毫秒，另一成员为 95 毫秒，改善只有 25 毫秒；在容差为 50 毫秒时，不应期待立即切换。若另一成员为 60 毫秒，则改善达到 60 毫秒，已超过这一容差。这个例子只解释参数关系，不是实测记录；真正选择还受成员可用性、探测完成时间及内核实现影响。

不要把容差设为很大来“提高稳定性”。例如设成 500 毫秒，会容忍明显的延迟差距。可以先用 interval: 300 和 tolerance: 50 观察，再按网络波动幅度调整。视频缓冲或下载速度不佳时，也应检查丢包、带宽和目标网站线路，而不是只看面板上的最低数字。

fallback：按列表顺序主备切换

fallback 选择列表中靠前且健康的成员。列表顺序就是优先级：第一个成员可用时优先使用它；第一个不可用时再考虑第二个。它不以最低延迟为目标，也不需要 tolerance 字段。

把日常首选节点放在 proxies 第一项。
把备用节点按优先级依次排列，尽量避免所有成员依赖同一故障线路。
使用统一探测 URL，并先以 300 秒间隔观察可用性。
主节点恢复并被检查为健康后，后续连接可重新优先使用主节点。

假设第一项探测为 180 毫秒、第二项为 80 毫秒，只要第一项仍被判断为可用，fallback 就不会仅因第二项更快而主动追逐低延迟。主线路“能够打开探测地址，但访问业务网站很慢”时，组仍可能继续选用主线路。

load-balance：按算法分配连接

load-balance 把不同连接分配给组内的可用成员。它适合有多个并发请求、且允许不同请求使用不同出口的业务。三条线路各有一定带宽，并不意味着单个下载连接就能获得三条线路的总带宽。

mihomo 常见分配算法

strategy 值	主要行为	使用注意
`consistent-hashing`	按目标地址相关信息进行一致性哈希分配	有助于同一目标保持较稳定的出口，但成员变化后可能重新映射
`round-robin`	对新连接轮流选择可用成员	同一网站的不同连接可能使用不同公网 IP
`sticky-sessions`	依据来源与目标信息维持一段时间的粘性分配	需确认内核支持，不能视为账号级固定出口保证

示例采用 consistent-hashing。其目标分组方式会受域名信息是否可见等条件影响，不能理解成“一个账号永远对应一个节点”。对于对出口 IP 敏感的支付、后台登录或企业认证业务，优先使用固定节点，或单独建立手动选择组。

round-robin 的轮换发生在连接分配层面，不是把一个 TCP 连接的数据包逐个发往不同节点。浏览器可能复用 HTTP/2 连接，因此刷新几次页面也未必能观察到严格交替的公网 IP。验证均衡行为应查看客户端连接记录，并发起多个独立的新连接。

proxy-groups 配置示例

下面是可合并到 mihomo 配置的策略组片段。前提是配置的 proxies 中已经存在名为“香港01”“日本01”“新加坡01”的三个节点。请把这三个名称替换为实际节点名称，保留节点原有的服务器、协议与认证字段。

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - 自动测速
      - 故障切换
      - 均衡出口
      - DIRECT

  - name: 自动测速
    type: url-test
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

  - name: 故障切换
    type: fallback
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

  - name: 均衡出口
    type: load-balance
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

这里的 generate_204 地址仅用于健康检查，不是订阅链接，也不是节点服务器。该地址通常返回 HTTP 204；如果所在网络或出口无法稳定访问它，应换成经过确认的轻量探测地址。不要选需要登录、存在复杂跳转或响应很大的网页。

把业务规则接到策略组

定义组之后，还需要让规则引用它。以下是规则语法示例，不是建议覆盖现有完整规则集。保留已有的局域网、直连和业务分流规则，把最终兜底规则放在最后：

rules:
  - DOMAIN-SUFFIX,example.com,出口选择
  - MATCH,出口选择

example.com 是规则语法示例域名，实际使用时应改为要分流的业务域名。MATCH 会匹配前面尚未命中的连接，因此不能放在其他精细规则之前。在客户端使用规则模式，再从“出口选择”中选择“自动测速”“故障切换”或“均衡出口”，对应策略才会参与这部分流量的处理。

订阅与 provider 的合并要点

通过 proxy-providers 加载节点时，策略组通常使用 use 引用提供者，而不是把提供者名称写到 proxies 中。两者不是同一个命名空间。下面假定现有配置已经定义名为“订阅节点”的 provider：

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

这个片段不包含 provider 的下载地址、缓存路径与更新设置，不能单独充当完整配置。若原订阅已经提供可用策略组，优先检查现有组的行为，不必再建一套相同组。把几十个节点同时放入多个自动组，可能增加探测请求和排查难度。

提供者的 health-check.interval 与策略组的 interval 属于不同配置位置，不能只改一处就假定全部检查节奏都已改变。具体探测组织及复用行为取决于内核实现。排查时应同时检查 provider 和策略组配置，并以实际日志为准。

订阅更新可能覆盖直接编辑的配置文件。需要长期保留自定义组时，应使用客户端支持的覆写、合并或扩展配置机制。不同客户端入口名称不同，可先从“订阅”或“配置”页面打开当前配置的操作菜单，确认编辑的是持久覆写文件还是下载后的临时配置。

配置验证与异常排查

按顺序验证，不只看测速数字

备份当前配置。保留可正常使用的配置副本，记录当前内核名称。命令行部署可用 mihomo -v 查看版本信息。
检查语法和引用。命令行环境可执行 mihomo -t -f ./config.yaml。若配置依赖相对路径资源，应在实际运行目录与环境中检查。
重载配置。使用客户端的配置重载功能，或按部署方式重启内核。仅保存文件，不一定会改变正在运行的配置。
触发健康检查。在策略组页面执行一次测速，确认至少一个成员可用。初次检查尚未完成时，不要仅凭旧延迟判断选择结果。
检查规则命中。在连接记录中查看目标域名、命中的规则、策略链与最终节点，确认流量确实经过新建策略组。
建立新连接复测。关闭测试应用的旧连接后重试。对比探测状态、策略选择与业务访问结果，而不是只刷新同一个长连接页面。

常见现象与对应原因

提示找不到代理：检查节点名称是否完全一致，特别是空格、大小写和订阅更新后的重命名；使用 provider 时检查 use 引用。
自动测速组不切换：检查当前模式、规则是否命中该组，以及延迟差是否超过 tolerance；不要把另一个未被使用的同名近似组当作当前出口。
全部成员都显示超时：先单独验证一个节点，再检查探测 URL、DNS 和网络可达性。共同的探测目标故障可能让多条正常线路同时被判为异常。
fallback 一直使用第一项：如果第一项仍健康，这是符合顺序优先逻辑的结果；要追求较低延迟，应改用 url-test。
load-balance 导致登录状态异常：检查是否使用轮询，以及业务是否对出口 IP 敏感。将该业务单独分流到固定节点，比频繁更换均衡算法更直接。
更新订阅后自定义组消失：检查改动是否写在被更新覆盖的文件中，把持久化修改迁入客户端支持的覆写机制。

最后按需求收敛配置：日常浏览优先验证 url-test，固定主备顺序选 fallback，确有多连接分摊需求再使用 load-balance。继续调整规则或 DNS 前，可先阅读配置文件参考；安装与导入步骤见客户端配置教程。