Clash 策略组 url-test、fallback、load-balance 详解与配置写法

先分清规则、策略组和节点

在 Clash 配置中，rules 决定一条连接交给哪个策略组，proxy-groups 决定这个组从哪些节点或下级组中选出口，proxies 和 proxy-providers 则提供候选节点。排查「规则已经命中，出口却不对」时，应先看规则指向的组，再看组内当前选中的成员，而不是只检查节点列表。

策略组的 type 决定选择方式：select 由人手动指定；url-test 根据探测延迟自动选择；fallback 按列表顺序选择可用项；load-balance 在可用节点间分配连接。它们都可以作为规则的目标，但「自动选择」并不等于修改订阅中的节点，也不会替你改变规则匹配顺序。

select：把最终出口留给手动选择

select 通常放在规则和其他策略组之间。例如规则指向「手动选择」，组内同时列出「自动优选」「故障切换」、具体节点和 DIRECT。这样无需改动规则，就能在客户端的「代理」页面切换出口。DIRECT 表示直接连接；把它列进组里，是为了需要对照代理与直连结果时有一个明确选项。

select 不会依据延迟替你改选成员。若列表里同时有自动组和具体节点，选中「自动优选」后，才由下级 url-test 继续决定具体节点。客户端显示的当前选择也可能随订阅更新、组名变化而需要重新确认；更新配置后，先核对组内成员是否还存在，再检查实际出口。

url-test：按探测延迟选择，而非按测速带宽选择

url-test 使用 url 指定探测地址，用 interval 指定探测间隔，单位为秒。例如 interval: 300 表示每 300 秒安排一次周期探测；客户端显示的延迟来自探测请求，不是下载速度，也不能单独代表视频吞吐量。探测地址应能稳定返回响应，示例采用常见的 https://www.gstatic.com/generate_204。如果当前网络或节点无法访问它，应换成自己确认可达的轻量地址，否则延迟栏可能持续显示失败。

tolerance: 50 表示设置 50 毫秒的选择容差，用来减少延迟接近的节点之间频繁切换；它不是连接超时，也不是「超过 50 毫秒就判为故障」。如果某个业务要求固定出口 IP，例如登录状态对出口变化敏感，优先在 select 中指定具体节点，不要仅凭最低探测延迟决定出口。

fallback：列表顺序就是优先级

fallback 同样依赖 url 和 interval 检查成员是否可用，但选择依据不是谁的延迟最低。假设候选顺序是「香港 01」「香港 02」「日本 01」，只要「香港 01」仍被判断可用，即使「香港 02」的探测延迟更低，组也会优先使用「香港 01」。当首个成员不可用时，才按顺序尝试后面的成员。

因此，fallback 适合需要主用与备用节点的连接：把希望长期使用的节点放在前面，把备用节点放在后面。编排顺序时不要只看节点名称，还要确认这些节点确实支持所需业务。探测失败后的切换取决于健康检查结果；它不是对每个网页请求即时重试一次。已经建立的连接也不能据此假定会自动迁移到新节点。

load-balance：分配连接，不是叠加单次带宽

load-balance 面向多个可用节点分配连接。mihomo 配置中的 strategy: consistent-hashing 使用一致性哈希策略，使相同目标倾向于落到相同节点；strategy: round-robin 则按轮转方式分配。这里分配的是连接，不是把一个文件下载拆成多条线路合并传输，因此不能把多个节点的标称带宽相加，当作单个连接的速度。

选择策略前先看业务：同一站点希望尽量保持出口一致，可以从 consistent-hashing 开始；多个彼此独立的请求需要轮流使用节点，可以测试 round-robin。涉及登录、支付或依赖固定来源地址的服务时，轮转出口可能触发额外验证。此时改用具体节点或 fallback，比反复调低探测间隔更直接。

可改写的 proxy-groups 配置

下面示例假定当前配置的 proxies 或代理提供者中，已经存在名为「香港 01」「香港 02」「日本 01」的节点。粘贴前，把这三个名称逐字换成自己配置中的实际节点名；名称中的空格也必须一致。示例的 proxy-groups 和 rules 是顶层字段，不要缩进到某个节点下面。若文件已有同名顶层字段，应合并其内容，不要再新增第二份。

proxy-groups:
  - name: 自动优选
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

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

  - name: 均衡分流
    type: load-balance
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

  - name: 手动选择
    type: select
    proxies:
      - 自动优选
      - 故障切换
      - 均衡分流
      - 香港 01
      - DIRECT

rules:
  - MATCH,手动选择

MATCH 是兜底规则，放在已有规则的最后；如果直接用示例中的 rules 覆盖原文件，原有的分流规则就不会继续生效。希望保留现有分流时，只把各条规则需要使用的目标组名改成「手动选择」，并保留原有规则顺序。想让「均衡分流」按轮转方式工作，可在确认内核支持后把它的 strategy 改为 round-robin。

使用代理提供者时怎么写

如果节点由 proxy-providers 提供，而不是直接列在配置的 proxies 中，策略组可以用 use 引用已有的提供者名称。例如提供者顶层键名为 main-provider 时，在对应策略组中写 use: [main-provider]。先确认提供者已经成功加载，再检查组内是否出现节点；仅写 use 不会创建订阅或替你填写订阅地址。需要同时加入手动节点时，可按所用内核支持的语法，在同一组中分别配置 use 与 proxies。

导入后的检查顺序

1. 先检查语法和名称。YAML 使用空格缩进，type、proxies、url 与 interval 应属于同一个组。若提示找不到节点，逐字核对成员名称；若提示重复字段，检查是否粘贴了第二个顶层 proxy-groups 或 rules。
2. 再看健康检查。在客户端「代理」页面打开「自动优选」或「故障切换」，触发延迟测试，观察三个节点是否返回结果。全部失败时，先检查探测地址是否可达及节点本身能否连接，不要立即把 interval: 300 改成更短的数值。
3. 最后核对流量路径。在「代理」页面选中「手动选择」及其下级组，确认客户端的代理接管方式已启用，再访问目标站点。如果启用了规则模式，查看连接记录命中了哪条规则；若仍在全局或直连模式，不能仅凭 rules 中的 MATCH 判断实际出口。

需要稳定指定出口时用 select；优先考虑探测延迟时用 url-test；主备顺序明确时用 fallback；不同连接希望分配给多个节点时再使用 load-balance。四种组可以在同一份配置中并存，关键是让规则指向正确的组，并在更新订阅后重新检查节点名、探测结果和当前选择。