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

三种自动策略组：按延迟、顺序或连接分配选路

proxy-groups 定义的是出口选择逻辑，不是代理服务器本身。节点通常来自 proxies 或 proxy-providers；规则命中策略组后，才由策略组决定使用哪个出口。把组名写进配置但没有让规则引用它，不会改变实际流量路径。

先确认客户端实际使用的内核和版本。Clash 图形客户端是操作界面，Clash 原版内核与 Clash Meta 后续演进的 mihomo 才负责解析这些字段。以下完整配置以 mihomo 为目标；旧内核对扩展字段和负载均衡算法的支持可能不同，应以启动日志和对应版本文档为准。

类型	选择依据	适用条件	主要限制
`url-test`	探测延迟与切换容差	希望自动选择响应较快的出口	探测延迟不代表下载吞吐量
`fallback`	列表顺序与健康状态	固定主线路，故障时用备用线路	靠后的节点更快也未必被使用
`load-balance`	算法分配新连接	多个可用出口分担连接	不能把多个节点合并成单连接带宽

url-test：interval 与 tolerance 如何配合

url-test 经候选节点访问指定的 url，记录探测结果，并据此选择出口。它测到的是到该探测地址的请求耗时，包含代理链路及目标响应的影响，不是 ICMP ping，也不是视频站点或文件服务器的完整性能测试。

先分清三个参数的单位

url：健康检查请求地址。通常选择响应小、稳定且能经候选节点访问的 HTTPS 地址，例如返回 204 的检测端点。
interval: 300：周期性检查间隔，单位为秒，即约每 5 分钟检查一次；不是 300 毫秒，也不是连接超时值。
tolerance: 50：切换容差，单位为毫秒。用于减少轻微延迟波动造成的频繁换线；它不是丢包率，也不是最大可接受延迟。

例如当前节点最近一次探测为 105 ms，另一个节点为 80 ms，差距只有 25 ms。设置 50 ms 容差时，不应期待客户端仅因这点优势就立即切换。如果当前节点升至 155 ms，而另一个仍为 80 ms，差距达到 75 ms，便具备更明显的切换条件。这是说明容差作用的计算示例，不是本站实测；最终选择仍取决于内核当轮健康状态和实现。

检查周期不等于故障恢复承诺

把 interval 从 300 改为 60，会增加探测频率，但不能保证故障后 60 秒内所有业务恢复。探测本身需要时间，已有连接也可能等待超时。候选节点数量越多，周期性请求越多；普通日常使用可先从 300 秒开始，再根据日志调整。

mihomo 的 lazy 会影响未使用策略组的周期检查行为。排查时可显式设为 false，减少“组未被使用，所以没有持续探测”的干扰。若节点来自 provider，还应单独检查 provider 的 health-check 设置，不要把 provider 检查和组级探测当成同一个定时器。

fallback：按列表优先级选可用出口

fallback 从候选列表中选择靠前的可用节点。假设列表依次为“节点-A”“节点-B”，只要 A 的健康检查结果可用，即使 A 为 180 ms、B 为 60 ms，仍应预期使用 A。要让更快的节点优先，应选择 url-test，而不是调换探测间隔。

把日常主线路放在 proxies 第一项，备用线路依次排列。
使用所有候选节点均可访问的检查地址，避免把目标站点限制误判为节点故障。
重新加载配置，在代理页确认组内顺序，再手动触发一次检查。
临时停用主节点对应服务，观察后续新连接是否转向备用；测试完成后恢复服务。

当主节点重新被判定为可用后，优先级逻辑会再次倾向列表前面的节点。这个行为适合“主线优先、备用兜底”，但不等于已有 TCP 连接会被迁移。网页短请求通常会重新建连；下载、SSH、视频长连接可能需要应用重试。

load-balance：分配连接，不合并带宽

load-balance 在可用候选出口之间按算法分配连接。mihomo 可使用 strategy 指定算法；下面采用 consistent-hashing。对登录、支付、会话绑定等业务，出口稳定性通常比均匀分配更重要，适合先用一致性哈希，或直接把这些域名指向固定节点。

strategy 值	用途	核对重点
`consistent-hashing`	按目标相关信息进行相对稳定的映射	同一业务倾向固定出口，但节点变化时可能重映射
`round-robin`	轮转分配新连接	同一站点的多个连接可能走不同出口

具体哈希输入、域名处理方式和额外算法支持随内核实现而异，不能把“一致性哈希”理解成永久固定公网 IP。节点上下线、配置重载或候选列表变化都可能改变映射。若服务强依赖固定出口，单独写规则指向手动选择组更可控。

例如浏览器并发建立 10 条连接时，轮转算法可能把它们分配到不同节点；一条已建立的 TCP 连接仍走一个出口。HTTP/2 或 HTTP/3 还可能复用连接，所以刷新网页并不一定产生新的分配。验证负载均衡要看连接记录中的策略链和实际节点，不能只连续刷新同一个 IP 查询页面。

完整 YAML：三种组并列，外层手动选择

下面是一份供 mihomo 校验结构的完整示例：select 组作为统一入口，内部可切换低延迟、主备或均衡模式。两个节点使用文档专用地址 192.0.2.10 和 192.0.2.11，不能连接真实代理。实际使用前，必须将整个节点定义替换为服务提供方给出的协议、地址、端口和凭据。

config.yaml · mihomo 结构示例

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: 节点-A
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"
  - name: 节点-B
    type: ss
    server: 192.0.2.11
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - 自动低延迟
      - 主备切换
      - 连接均衡
      - 节点-A
      - 节点-B
      - DIRECT

  - name: 自动低延迟
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

  - name: 主备切换
    type: fallback
    proxies:
      - 节点-A
      - 节点-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

  - name: 连接均衡
    type: load-balance
    proxies:
      - 节点-A
      - 节点-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

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

规则从上到下匹配；示例中的 example.com 及其子域名直连，其余流量交给“出口选择”。这是演示规则，不是完整的国内外分流方案。mixed-port: 7890 提供 HTTP 与 SOCKS 混合入口；是否设置系统代理，仍由客户端或系统设置决定。

使用订阅 provider 时怎么改

如果现有配置已经定义名为“订阅节点”的 proxy-providers，可以用下面的组替换对应的静态候选写法。use 引用 provider 名称，proxies 引用节点或策略组名称，两者不是同一个命名空间。此片段依赖现有 provider 定义，不能单独作为完整配置运行。

proxy-groups 片段 · 引用现有 provider

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

不要直接改写会被远程订阅覆盖的临时配置。客户端若提供覆写、合并或扩展配置功能，应在该功能中保存自定义组；具体入口按客户端版本确认。修改后更新一次订阅，检查组和规则是否仍保留，才能验证持久化方式是否正确。

嵌套组合：地区内测速，地区间主备

更细的组织方式是先给每个地区建立独立 url-test 组，再让一个外层 fallback 按地区优先级引用它们。例如“主地区测速”只包含主地区节点，“备用地区测速”只包含备用地区节点，外层顺序固定为主地区在前。这样地区内部考虑延迟，地区之间保留业务优先级。

外层组只能引用已经定义的组名；不要把自身写进候选列表，也不要构造 A 引用 B、B 又引用 A 的循环。
外层看到的是内层组当前选出的路径，不能假定它会展平全部节点重新比较。
内外层各自有检查周期，恢复过程可能经历多轮更新；先测试单层，再增加第二层。
登录敏感业务可单独指向固定节点或 select 组，不必与批量下载共享均衡策略。

若只需要日常网页自动选路，示例中的“外层 select + 内层 url-test”通常已足够。嵌套层数越多，连接记录越难排查；只有确实存在地区、费用或主备优先级差异时，才增加层级。

常见误配与验证步骤

现象	先核对什么	处理方式
低延迟组没有换线	当前差值、容差和最近探测时间	手动检查一次，再确认规则是否命中该组
主备组一直使用较慢节点	列表顺序与健康状态	这是顺序优先；需要延迟优先时改用 url-test
所有节点同时超时	检查地址、本机 DNS、系统时间	先验证单节点访问同一检测端点，避免只更换策略类型
配置提示找不到代理	组名、节点名、provider 名和缩进	逐字核对引用，YAML 使用空格而非 Tab
切换后旧下载仍异常	是否仍复用已有连接	重建该业务连接，必要时只关闭对应连接记录
订阅更新后自定义组消失	修改的是源配置还是临时配置	通过客户端支持的持久化覆写方式保存

按四步核对实际生效结果

先校验配置：使用客户端配置检查功能；直接运行 mihomo 时，可执行 mihomo -t -f config.yaml。校验通过只说明配置可解析，不代表节点凭据和网络可用。
再重新加载：在配置页启用修改后的配置，查看日志是否报告未知字段、重复名称或引用不存在。合并进已有配置时，不要重复创建同层的 proxy-groups 或 rules 键。
检查规则链：以 Rule 模式发起一次新请求，在连接页确认命中规则、外层组、内层组和最终节点。Global 或 Direct 模式可能绕过本次要验证的规则入口。
最后测业务：分别检查网页访问、目标服务登录和实际下载。记录测试时间、出口节点与探测延迟，再决定是否调整 300 秒间隔或 50 ms 容差。

选择依据可以压缩为三个问题：要自动追随较低延迟，选 url-test；要固定主线并保留故障备用，选 fallback；要让多个出口承担不同新连接，选 load-balance。确定需求后再调整参数，比把所有策略层层叠加更容易验证和维护。