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

先选切换逻辑，再写 proxy-groups

想自动选择响应较快的节点，用 url-test；想固定主线路、失效后才启用备用线路，用 fallback；想把不同连接分配给多个节点，用 load-balance。三者都能结合健康检查，但“自动”不代表它们会按同一种标准选节点。

客户端负责导入订阅、展示策略组与启用配置，真正执行选择逻辑的是内核。Clash 与 Clash Meta（现称 mihomo）的基础字段相近，扩展字段和支持的策略可能不同。本文示例以 mihomo 为目标；保存前先在客户端的内核信息或启动日志中确认运行的内核，再用配置检查验证字段。

url-test：按延迟选择，使用 tolerance 抑制抖动

url-test 通过候选节点访问同一个测试地址，根据健康检查结果选择响应较快的节点。这个数字包含代理路径访问测试服务的耗时，并不是对代理服务器做一次 ICMP ping，也不是测速文件的下载速度。

最小配置与参数单位

proxy-groups:
  - name: 自动低延迟
    type: url-test
    proxies:
      - 香港日常
      - 日本备用
      - 新加坡备用
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• url：健康检查目标，示例地址通常返回 HTTP 204。应选择体积小、稳定、能通过候选节点访问的 HTTPS 地址。
• interval: 300：检查间隔为 300 秒，即 5 分钟，不是 300 毫秒。
• tolerance: 50：切换容差为 50 毫秒，用来避免因很小的延迟差频繁更换出口。
• lazy: true：启用惰性检查，未使用的组可以减少周期性测试。首次启用、手动测速与内核调度仍可能触发检查。

容差不是固定延迟上限

假设某次测试中，当前节点为 120 ms，另一节点为 95 ms，差值只有 25 ms。设置 50 ms 容差后，通常不会仅因这点优势切换。若另一节点降到 60 ms，差值扩大到 60 ms，便可能满足切换条件。这是说明参数的假设数据，不是本站实测结果；实际选择还取决于健康状态与内核实现。

不要把 tolerance 理解成“超过 50 ms 就不用”。它衡量的是切换时的延迟差，而不是对所有节点设一个 50 ms 的合格线。频繁跨地区切换时，可以先把容差从 20 ms 调到 50 ms，再观察，而不是把检查间隔降到 5 秒。

fallback：按顺序保留主线路，失效后选择备用

fallback 的重点是顺序，不是最低延迟。列表中第一个健康节点优先使用；它失效后，才选择后面的健康节点。若主节点恢复健康，后续选择通常会重新优先考虑主节点。

proxy-groups:
  - name: 主备切换
    type: fallback
    proxies:
      - 香港日常
      - 日本备用
      - 新加坡备用
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

在这个例子里，即使“日本备用”为 70 ms、“香港日常”为 150 ms，只要香港节点健康，主备组仍优先使用香港节点。因此，先把需要固定地区、流量成本较合适的节点放到前面，再把跨地区备用节点放到后面。

故障切换不是无中断迁移

• 周期检查之间可能存在状态滞后。300 秒间隔不等于故障发生后立即发现，也不是恢复时间保证。
• 组切换主要影响后续新连接。已有 TCP 连接无法直接把服务器端会话迁移到另一出口，视频、SSH 或下载任务可能需要重连。
• 这里的 fallback 不是“每个请求失败都立即把同一请求换节点重试”的业务层重试器。
• lazy: false 让未被使用的组也持续进行周期检查，状态更容易保持更新，但会增加测试请求与移动设备唤醒。

如果业务需要稳定地区，应让主备候选尽量位于同一出口地区。测试地址可达，只说明该检查请求成功；并不保证所有业务域名均可访问，也不保证两个节点获得相同的内容服务权限。

load-balance：分散不同连接，不合并单连接速度

load-balance 在健康候选之间分配连接。它不是链路聚合，也不会把一个 TCP 下载连接拆成三份同时走三个节点。收益主要来自多个独立连接或多个目标的分散使用，而非把单次下载速度直接乘以节点数。

proxy-groups:
  - name: 多出口分配
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港日常
      - 日本备用
      - 新加坡备用
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

consistent-hashing 与 round-robin 怎么选

一般浏览可先使用 consistent-hashing。它有助于降低同一目标反复换出口的概率，但不等于账号级会话绑定：一个服务可能同时访问多个域名，也可能在候选失效时重新分配。登录、支付、需要固定来源 IP 的管理后台，宜单独用规则指向手动选择组或稳定主备组。

轮询分配的是连接，不是流量字节。三个节点各承担若干连接，也可能因为某个连接持续下载而出现明显的流量差异。该基础示例不包含权重控制；节点的 0.5 倍、1 倍或 2 倍计费倍率，也不会被负载均衡自动识别为成本权重。

合并示例：保留手动入口，再把规则指向策略组

下面的片段把三种自动组收进一个 select 组。配置启用后，可在客户端的代理组面板中选择“代理出口”，再选择自动低延迟、主备切换、多出口分配，或直接指定节点。这样排查时可以绕过自动策略，确认单个节点是否正常。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自动低延迟
      - 主备切换
      - 多出口分配
      - 香港日常
      - 日本备用
      - 新加坡备用

  - name: 自动低延迟
    type: url-test
    proxies:
      - 香港日常
      - 日本备用
      - 新加坡备用
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 主备切换
    type: fallback
    proxies:
      - 香港日常
      - 日本备用
      - 新加坡备用
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

  - name: 多出口分配
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港日常
      - 日本备用
      - 新加坡备用
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

rules:
  - MATCH,代理出口

最后的 MATCH 只是展示规则与组名的关系。实际配置应保留原有局域网、直连和业务分流规则，把兜底规则放在末尾。直接用这一行替换全部规则，会让原本应直连的流量也进入代理出口。

订阅使用 proxy-providers 时改用 use

若节点由已有的 proxy-providers 提供，不必在组内手写每个节点名。假设配置已经定义名为 线路订阅 的提供器，可以这样引用：

proxy-groups:
  - name: 提供器自动选择
    type: url-test
    use:
      - 线路订阅
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

use 引用的是提供器名称，proxies 引用的是节点或组名称，不能互相混用。提供器更新间隔决定何时获取节点列表，健康检查间隔决定何时测试可用性；改成每 60 秒检查，不会让订阅列表每 60 秒更新。

提供器本身也可能配置 health-check。组与提供器的检查由内核调度，不能简单把两个间隔相加来推算故障切换时间。维护配置时应明确谁负责定期检查，避免让多个提供器和策略组都用过短周期制造额外请求。

验证与排查：先看实际出口，再调整测试参数

先检查 YAML 与节点引用

1. 备份当前可用配置。在持久化覆写或合并配置入口中修改策略组，避免直接修改会被订阅更新覆盖的临时文件。
2. 使用空格缩进，不使用 Tab。组名保持唯一，规则中的名称与组名逐字一致，组之间不能形成循环引用。
3. 若命令行内核已在 PATH 中，运行 mihomo -t -f ./config.yaml 检查配置；相对路径按实际文件位置调整。
4. 重新加载配置，手动触发一次健康检查，再看策略组候选状态。只有配置检查通过，并不代表节点已经能连接。

用明确代理入口验证新连接

如果当前配置的 HTTP 或混合代理端口确实为 7890，可以用下面的命令测试。这里的端口是验证示例，不是所有客户端的固定值，应先在端口设置或配置的 mixed-port 中核对。

curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://cp.cloudflare.com/generate_204

显式指定代理后，命令不依赖终端是否读取系统代理。成功返回 HTTP 204 可用于验证这条测试路径；还应在客户端连接记录中确认命中的规则、策略组与实际节点。要判断业务可用性，再对实际业务建立新连接，不能仅凭测试地址成功下结论。

常见现象与处理顺序

• 所有节点同时超时：先手动选择一个已知可用节点。若业务访问正常但测试失败，检查测试域名、DNS 与该地址的可达性；不要立即删除全部节点。
• url-test 总在换节点：先确认测试地址是否稳定，再增加容差。把 300 秒改成 10 秒通常会放大短期波动，还可能增加耗电。
• fallback 不选最快节点：这是按顺序选健康节点的预期行为。需要比较延迟时，应换成 url-test，而不是调整备用列表来模拟测速排序。
• load-balance 的流量不平均：检查是否只有少数长连接，或多个请求集中在相同目标。一致性哈希和连接轮询都不保证每个节点获得相等字节数。
• 组已切换，页面仍显示旧出口：先建立新连接。浏览器连接复用、持续下载与长连接可能仍留在原节点；关闭连接会中断任务，应在可接受时操作。
• 订阅更新后设置丢失：把自定义策略迁移到客户端支持的持久化覆写机制，再确认合并后的最终配置，而不是只检查编辑器中的片段。