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

先按目标选组：低延迟、固定优先级或连接分摊

url-test 在可用节点中按探测延迟选路；fallback 按配置顺序选择第一个可用节点；load-balance 按指定算法分配不同连接。三者都能使用健康检查，但“检查节点是否可用”和“决定连接交给谁”是两件事。不能看到自动探测，就把它们都理解成自动选择最快节点。

类型	选择依据	适合的目标	主要限制
`url-test`	探测 URL 的延迟与切换容差	日常浏览，自动选择响应较快的节点	探测延迟不等于下载带宽
`fallback`	候选顺序与可用状态	固定主线路，故障后切备用	排在后面的低延迟节点不会优先使用
`load-balance`	哈希或轮询等分配算法	把多个连接分配给不同节点	不会把单条连接叠加成多节点带宽

例如三个节点的探测结果分别为 HK-A 90ms、HK-B 65ms、JP-A 130ms。自动测速组在满足切换条件时倾向于 HK-B；故障切换组若按 HK-A、HK-B、JP-A 排列，仍使用健康的 HK-A；负载均衡组则可能让不同目标经由不同节点。这里的数值仅用于说明选路过程，不是线路实测或速度承诺。

url-test 写法：用 tolerance 限制小幅延迟抖动

url-test 会通过候选节点访问指定 URL，把请求耗时作为选路依据。它不是直接对节点服务器做一次 ICMP ping；结果会受到节点握手、出口链路、目标站点以及连接复用等因素影响。因此，测试地址需要稳定，并且最好能代表实际访问方向。

proxy-groups:
  - name: 自动测速
    type: url-test
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

三个参数先分清单位

interval: 300：探测间隔为 300 秒，即 5 分钟，不是 300 毫秒。
tolerance: 50：切换容差为 50 毫秒，用于减少因小幅延迟波动产生的切换，不是请求超时。
lazy: true：启用惰性探测，组未被使用时可能暂停周期探测；它不代表应用的每个请求都会先测速。

假设当前节点约 90ms，另一个节点约 65ms，差距只有 25ms。设置 50ms 容差后，不应期待组立刻切到后者。若另一个节点降到约 30ms，才更符合触发切换的条件。实际选择还取决于当前节点是否有效、探测结果是否更新；当前节点不可用时，也不能把容差理解为必须继续保留故障节点。

日常使用可以从 300 秒间隔、50ms 容差开始观察。把间隔缩到 5 秒，通常只会增加探测请求、移动网络唤醒和服务端压力。把容差设为 0，则可能因几毫秒差异频繁改变后续连接的出口。需要稳定会话时，优先降低不必要的切换，而不是一味追求面板上的最小数值。

fallback 写法：节点顺序就是优先级

fallback 的核心不是“谁快用谁”，而是“从上到下，第一个健康的节点是谁”。主线路正常时，即使备用线路延迟更低，也不会因此抢占主线路的位置。这适合有固定地区、固定出口或费用优先级的场景。

proxy-groups:
  - name: 主备线路
    type: fallback
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

HK-A、HK-B 都健康：优先选 HK-A。
健康检查确认 HK-A 不可用、HK-B 可用：后续选路使用 HK-B。
后续检查确认 HK-A 恢复：组会重新优先选择 HK-A。

这里的“恢复”以健康检查结果为依据。300 秒检查间隔不代表所有故障都能在一秒内切换，也不代表一定恰好等满 300 秒：手动测试、客户端触发行为及内核实现都会影响状态更新。正在进行的 TCP 会话也不会被自动迁移到备用服务器；已经断开的下载、SSH 或视频连接，仍需要应用重连。

load-balance 写法：分摊连接，不聚合单连接带宽

load-balance 把连接分配给多个健康节点。它既不是逐个数据包轮流发送，也不是把三条 100Mbps 线路自动合并成一条 300Mbps 隧道。单个 TCP 连接仍沿着选定的节点传输；应用建立多个连接时，才可能看到多节点同时承担流量。

proxy-groups:
  - name: 连接分摊
    type: load-balance
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

consistent-hashing 与 round-robin 怎么选

consistent-hashing：根据目标信息做一致性哈希，倾向于让同一目标保持相同出口。具体哈希键会受内核实现和域名信息是否可用影响，不能理解为所有账号会话永久绑定。
round-robin：按轮询方式分配连接。需要观察多连接分摊效果时可以使用，但同一网站的不同连接可能经由不同出口。

需要轮询时，将示例中的最后一行改为 strategy: round-robin，不必重写整组。不要通过“开一个下载任务是否变快”判断负载均衡是否工作；更直接的方法是在客户端连接列表中观察多个目标、多个新连接的实际代理链。

即使使用一致性哈希，一个网页也可能同时访问登录、图片、API、验证码等多个域名，这些域名不保证分到同一节点。涉及地区限制、账号安全或来源 IP 一致性的服务，不适合直接使用跨地区负载均衡。节点集合变化、健康状态变化，也可能让原有映射重新分配。

嵌套 select 组：保留人工切换入口与规则出口

自动组通常不需要直接承担所有流量入口。更容易维护的结构是：外层 select 负责选择工作模式，内层分别负责自动测速、主备切换和连接分摊。遇到探测异常时，可以在客户端界面直接切到某个节点，不必临时修改组类型。

下面是一份整合片段，可替代前面三个独立片段。每个候选名称都必须能解析到已有节点或已定义策略组；不要让“代理出口”反过来成为其子组的候选，否则会形成循环引用。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自动测速
      - 主备线路
      - 连接分摊
      - HK-A
      - HK-B
      - JP-A

  - name: 自动测速
    type: url-test
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 主备线路
    type: fallback
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: 连接分摊
    type: load-balance
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,代理出口
  - MATCH,DIRECT

若节点来自 proxy-providers，可以在支持的组中用 use 引入现有 provider，而不是把 provider 名称写进 proxies 充当节点。还应检查 provider 的 health-check：provider 节点的健康检查需要在对应提供者侧正确配置，不能只看组里写了 url 就认为所有来源节点都已按预期探测。

订阅更新可能覆盖直接编辑的配置。修改前先备份，再确认客户端提供的是本地覆写、合并配置还是临时编辑入口。这里涉及的是内核 YAML 结构，不能假定不同客户端都有完全相同的“设置”菜单。基础导入步骤可参考入门指南，规则与 DNS 的关系可查阅配置进阶。

应用后按四步验证，避免“组在切，流量没变”

确认配置加载成功。重新加载后先看错误日志。节点名大小写、缩进错误、未知策略类型、重复顶层键，都可能导致新配置没有生效。界面仍显示旧组时，应先解决加载问题。
确认模式与规则命中。在 Proxies 查看外层组当前选择，在 Rules 核对目标规则，在 Logs 或连接详情中确认最终链路。使用规则模式时才按 rules 分流；全局模式可能绕过为特定域名设计的入口。
主动测试并记录结果。手动触发组测试，记下时间、URL、节点延迟和最终选中节点。比较前后结果时使用同一个测试地址，避免把两个不同目的地的延迟当成同一指标。
建立新连接复查。组切换后，旧连接可能仍在原节点上。使用新的命令行请求，或结束测试应用的连接后重试，再查看代理链；不要只靠刷新页面后的主观速度判断。

用 curl 排除浏览器连接复用的影响

假设本地 HTTP 或 mixed 代理监听 127.0.0.1:7890，可执行下面的命令。端口必须以客户端当前配置为准；若 7890 是纯 SOCKS 端口，就不能照抄 HTTP 代理协议。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/

Windows PowerShell 可将命令开头换成 curl.exe，避免部分环境中的命令别名差异。这个请求对应前面的 example.com 演示规则，适合配合日志确认是否经过“代理出口”。它只验证该目标的请求路径和响应，不代表所有网站、UDP 流量或 TUN 接管都已正常。

如果启用 TUN，连接可能由虚拟网卡接管，但最后采用哪个策略组仍由工作模式与规则决定。开启 TUN 不会把 fallback 变成测速组，也不会让 load-balance 自动获得单连接带宽叠加能力。

常见异常：先核对探测结果，再调整参数

测速全部 timeout，但个别网站能打开

这通常说明“测试 URL 不可达”和“所有业务不可达”没有被区分。先检查测试地址的 DNS、TLS、节点出口访问情况，再换一个确实能返回小体积响应的 HTTPS 地址交叉验证。不要把需要登录、存在跳转验证或会限流的业务首页当作长期健康检查端点。

url-test 总停在旧节点

先检查组是否正在被使用、惰性探测是否影响刷新，以及差距是否超过 tolerance。再看当前连接是不是早已建立。面板里显示另一个节点快 10ms，而容差是 50ms，并不构成配置故障。只有在探测结果更新、差距明显且新连接仍不符合预期时，才继续检查内核版本和组引用关系。

fallback 不选延迟最低的备用节点

这是顺序优先的正常结果。若要求主节点失败后从备用节点中挑最快线路，可以把一个 url-test 组放到主备组的备用位置，再用实际连接验证嵌套后的选择。嵌套会增加状态判断复杂度；只有两三条线路时，先使用平铺结构更容易定位问题。

负载均衡后网站反复要求登录

先把该网站单独分流到固定节点或手动选择组，观察新会话是否恢复稳定。仅将轮询改成一致性哈希不一定够，因为网站可能依赖多个域名共同校验地区和 IP。处理完会话问题，再考虑是否仍有必要给这类服务分摊连接。

最终选择原则：日常浏览先用带合理容差的 url-test；固定主线路用 fallback；明确需要多连接分摊时才用 load-balance。三者外面保留一个 select，配合规则命中、健康检查与新连接日志验证，比反复修改测速间隔更容易得到可解释的结果。