Clash 策略组 url-test、fallback、load-balance 怎么选:三种自动策略的切换逻辑

三种自动策略：先确定选择依据

Clash 自动策略组解决的是“新连接交给哪个节点”，不是自动改写网站分流规则。规则先把连接交给一个策略组，策略组再按自身逻辑选出节点。规则模式下，如果某个域名已经命中 DIRECT，调整自动组的测速周期不会改变该域名的出口。

三种策略都可以使用健康检查，但检查结果的用途不同：url-test 比较延迟，fallback 判断按顺序排列的节点是否可用，load-balance 在可用成员之间分配连接。下面以 mihomo 内核的配置语义为主；旧版 Clash 内核及不同客户端可能只支持其中部分字段，应先确认实际运行的内核，而不是只看应用名称。

策略类型	选择依据	适合需求	主要取舍
`url-test`	探测延迟与切换容差	日常浏览，自动选择响应较快的线路	测试目标不代表所有网站的体验
`fallback`	配置顺序中的首个可用成员	主线路固定，故障后使用备用线路	主线路恢复后可能自动回切
`load-balance`	哈希或轮询分配	多个独立连接分摊到多条线路	出口不一定统一，也不叠加单连接带宽

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

url-test 通过候选节点访问指定测试 URL，并依据探测结果选择节点。这里的延迟不是 ICMP Ping，也不是下载速度；它反映代理链路访问这个测试地址所花费的时间，受节点连接、目标站点响应以及链路状态等因素影响。

日常浏览的起始配置

以下片段放在配置的顶层 proxy-groups 下。示例假定 香港-A、香港-B、日本-A 已作为节点存在于 proxies 中；实际使用时，成员名称必须与已有节点名称完全一致。这是策略组片段，不是包含服务器凭据的完整订阅。

proxy-groups:
  - name: 日常自动
    type: url-test
    proxies:
      - 香港-A
      - 香港-B
      - 日本-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300：周期检查间隔为 300 秒，即 5 分钟，不是 300 毫秒。
tolerance: 50：切换容差为 50 毫秒，用于避免因为很小的延迟差异频繁更换节点。
lazy: true：启用惰性检查，未被使用的组不会一直按活跃组的节奏检查；周期并不意味着后台永远持续探测。
url：选择所有候选节点都能正常访问的轻量地址；示例地址通常返回 HTTP 204。

用具体数值理解容差

假设当前节点 A 的探测结果是 110 毫秒，节点 B 是 90 毫秒，二者仅差 20 毫秒。设置 50 毫秒容差后，不应期待组为了这点差距立即换到 B。若 A 变为 180 毫秒，而 B 保持 90 毫秒，差距达到 90 毫秒，就具备切换到更快节点的条件；具体更新时间仍取决于检查和选择时机。这些数字用于解释机制，不是本站实测结果。

容差不是额外等待时间，也不是判定节点失效的超时值。把它设为 0 会提高对细微延迟变化的敏感度，但不保证网页更快。日常使用可从 50 毫秒开始，观察是否存在频繁切换，再决定是否调整到 100 毫秒。

fallback：按顺序保留主线路，故障后启用备用

fallback 选择列表中第一个可用的成员。只要第一项仍被健康检查判为可用，第二项即使延迟更低，也不会因此取代第一项。它适合“优先用指定出口，只有不可用时才换线”，而不是“始终找最快节点”。

proxy-groups:
  - name: 主备线路
    type: fallback
    proxies:
      - 香港-A
      - 日本-A
      - 香港-B
    url: https://www.gstatic.com/generate_204
    interval: 120
    lazy: true

故障与恢复的选择过程

三个成员都可用时，选择列表第一项 香港-A。
香港-A 检查失败、日本-A 可用时，后续连接使用 日本-A。
后续检查确认 香港-A 恢复后，优先级重新生效，新连接可能回到 香港-A。

因此，fallback 不是“切到备用后永久停留”的粘滞主备机制。若主线路在可用与不可用之间反复变化，可能出现回切。需要固定某条线路进行工作时，使用手动 select 组通常更直观。

检查间隔设为 120 秒，也不代表故障必定在 120 秒内完成恢复。实际时间还受故障发生位置、探测超时、惰性检查和应用重试影响。主线路只是严重拥塞、但仍能访问测试地址时，fallback 也可能继续使用它，因为“慢”与“不可用”不是同一个状态。

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

load-balance 在可用节点之间分配连接。它适合多个任务并行运行，但不会将一个普通 TCP 下载连接拆分到三条线路上。假设三个节点分别能提供 10 MB/s，单连接下载不会仅因启用该策略就获得 30 MB/s。

consistent-hashing 与 round-robin 的差别

consistent-hashing：按目标相关信息进行一致性哈希，让相同目标倾向于使用相同成员。它更适合希望减少同一目标出口变化的场景，但节点可用集合变化后，映射仍可能改变。
round-robin：轮流选择可用成员，更便于将多个新连接分散出去。它不是按实时带宽、CPU 负载或剩余流量进行调度。

proxy-groups:
  - name: 多线分摊
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港-A
      - 香港-B
      - 日本-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

需要轮询时，将上例的 strategy 改成 round-robin 即可，前提是当前内核支持该策略字段。这里的分配单位是连接，而不是网页上的每一次点击，也不是 HTTP/2 连接里的每一个请求。浏览器复用长连接时，即使页面发出很多请求，也可能只使用少数几个节点。

interval、测试地址与节点提供者的边界

自动策略的检查流量会经过候选节点。将 30 个节点的间隔设为 30 秒，在持续活跃且每轮完整检查的简化条件下，每小时约产生 30 × 120 = 3600 次探测；改为 300 秒，约为 360 次。实际数量还取决于惰性检查、提供者及内核的调度行为。这说明缩短周期有成本，并不是越短越好。

设置项	单位或作用	建议起点
组内 `interval`	健康检查周期，秒	日常 300 秒，主备场景可从 120 秒观察
`tolerance`	url-test 切换容差，毫秒	50 毫秒；不是通用超时参数
`lazy`	是否惰性检查	一般从 `true` 开始
`strategy`	load-balance 分配算法	先用 `consistent-hashing`

区分订阅刷新与健康检查

若使用 proxy-providers，提供者外层的 interval 通常控制远程节点列表的更新周期；其 health-check.interval 控制节点健康检查。这与策略组里的同名字段不是同一件事。把订阅刷新周期改成 60 秒，不会自动得到每分钟测速的效果。

通过 use 引入提供者时，应核对提供者的健康检查配置，不能只给策略组写上测试 URL 就认为所有提供者成员都已按预期探测。也不要不加区分地在多个位置安排高频检查。建议先用少量直接列出的节点验证策略，再接入提供者，单独检查其更新日志和健康状态。

测试地址应保持可达且可比较

测试地址若被某些节点所在网络阻断，节点可能被判为不可用，但它访问其他站点仍正常。反过来，能访问测试地址也不能证明所有业务可用。遇到全组超时时，应先用一个已知可用节点访问同一地址，排除测试站点故障、DNS 错误和 TLS 握手失败，再判断是否为节点问题。

配置接入与验证：确认新连接确实进入目标组

三个自动组不必同时启用。若需要在同一份配置中对比，可以将前面三个定义放在同一个 proxy-groups 列表内，再增加一个手动入口。不要在 YAML 顶层重复写多个同名 proxy-groups 键，否则可能覆盖已有内容或导致解析错误。

  - name: 代理入口
    type: select
    proxies:
      - 日常自动
      - 主备线路
      - 多线分摊
      - 香港-A

上例需要追加在同一列表中，并与其他组保持相同缩进。原有规则中需要代理的目标应指向 代理入口。例如，明确要代理 example.com 及其子域名，可将下面这条规则放到相关的更宽泛规则之前；它只是目标规则示例，不要求把现有所有流量都改成代理。

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

这段规则用于说明匹配关系，最后一行会将其余流量直连，不能拿它直接覆盖订阅中完整的分流规则。规则按从上到下的顺序匹配，已有更靠前的规则也可能截获测试流量。

保存并检查配置。确认内核没有报告未知策略、组名重复或节点不存在；订阅管理器更新后可能覆盖直接编辑的内容，长期修改应使用客户端提供的覆写或合并配置功能。
保持现有接管方式。先沿用已经可用的系统代理或 TUN 设置，不要同时更换 DNS、端口和策略。三种策略本身都不要求必须开启 TUN。
选择入口中的目标组。从 日常自动 开始，触发一次检查并记录候选节点延迟与当前选择；再切换到主备组比较选择顺序。
建立新连接观察。在连接面板查看匹配规则、策略链和最终节点。已有网页可能复用连接，必要时关闭该页面及其连接后重新访问。
受控验证故障。在本地测试配置中暂时移除主节点或使用已知不可用成员，观察后续检查与新连接；不要通过高频探测或中断工作网络来验证。

常见现象与对应检查

url-test 总在两个节点之间跳：检查延迟差是否接近容差、测试地址是否波动，以及是否设置了过短周期。先调整一个参数，保留一段观察时间。
fallback 没选最低延迟：这是按优先级选择的正常结果。需要延迟优先时改用 url-test，而不是继续压低 interval。
load-balance 看起来只走一个节点：先检查是否使用一致性哈希、是否总访问同一目标，以及应用是否只建立了一条长连接。
换组后出口 IP 没变化：确认查询网站命中了目标组，并重新建立连接；也要考虑多个节点可能共享同一个公网出口。
全部显示超时：先检查同一个测试 URL、节点状态、系统时间与日志。客户端面板中的一次手动测速，不一定与自动组使用相同的测试地址和参数。

选择建议：延迟、主备与分摊分别配置

日常浏览可从 url-test + interval 300 + tolerance 50 开始；希望优先保留指定地区或线路时，使用按顺序排列的 fallback；多个独立任务需要分摊连接时，再考虑 load-balance，并先使用一致性哈希观察业务兼容性。

自动策略解决节点选择，规则解决目标归属，系统代理与 TUN 解决流量接管。将这三层分开验证，比同时更换内核、DNS 和自动组更容易定位问题。关于字段支持与接管边界，可继续查阅本站技术参考；需要先完成导入与基础连接时，按使用文档逐项验证即可。