节点多了以后，手动切换是最累人的事情。Clash 提供的三种自动化策略组——url-test、fallback、load-balance——各自解决不同的问题，搭配好可以让节点故障、延迟波动都变得「无感」。
三种自动化策略组速览
| 类型 | 选节点逻辑 | 适合场景 |
|---|---|---|
| url-test | 定时测速，始终使用延迟最低的节点 | 追求最优速度，允许偶尔切换 |
| fallback | 按顺序使用，当前节点失活才切下一个 | 有明确的「主备」优先级需求 |
| load-balance | 按算法把不同请求分散到多个节点 | 多节点分摊压力，避免单节点过载 |
url-test：自动挑最快的节点
这是最常用的策略组类型，Clash 会定时对组内所有节点发起测速请求，并始终选用延迟最低的一个。
tolerance（容差值，单位毫秒）避免了因为几毫秒的测速抖动就频繁切换节点：只有新节点的延迟比当前节点低于「当前延迟 − tolerance」时才会真正切换。
fallback：明确的主备顺序
如果你有一个「主力节点」，只有它失活时才希望切换到备用节点，fallback 更合适：它按 proxies 列表的顺序检测，始终优先使用列表靠前且可用的节点。
load-balance：把压力分摊出去
当有多个节点质量相近、希望把连接压力均摊时，可以用 load-balance，它支持两种分配算法：
- consistent-hashing：相同的目标地址会稳定落在同一节点，适合需要会话保持的场景。
- round-robin：按顺序轮流分配连接，分布更均匀，但同一目标地址可能落在不同节点上。
健康检查参数怎么调
url、interval、tolerance 这几个字段共同决定了策略组「多久检测一次」以及「多大差距才切换」，调得太激进或太保守都会带来问题。
| 字段 | 作用 | 调整建议 |
|---|---|---|
| url | 测速请求打到的目标地址 | 用轻量、稳定的探测地址，避免用大文件或经常波动的站点 |
| interval | 两次测速之间的间隔（秒） | 调太短会增加节点侧压力，一般 300 秒左右比较均衡 |
| tolerance | 切换所需的最小延迟差（毫秒） | 网络本身抖动大时适当调高，避免因几毫秒差异频繁切换 |
tolerance 设置过小，而不是急着怀疑节点质量问题。
策略组可以嵌套吗
可以。策略组的 proxies 字段既可以填具体节点名称，也可以填另一个策略组的名称，这意味着你可以搭建出「先按地区分组自动测速，再手动选择用哪个地区」这样的层级结构。但嵌套层级不建议太深——每多一层嵌套，实际生效的判断逻辑就多一层，遇到问题时排查起来也会更麻烦，一般两到三层足够覆盖大多数使用场景。
实战：多地区节点池怎么搭
一个常见的多层结构是：先按地区建立多个 url-test 子策略组（如「香港自动」「新加坡自动」），再用一个 select 手动策略组，让最终选择权交给自己，兼顾自动化与灵活性。
不同规则命中不同策略组
策略组的真正威力要结合 rules 才能发挥出来：不同类型的流量完全可以分别路由到不同的策略组，而不是所有流量都塞进同一个「大杂烩」策略组里。比如流媒体类域名可以单独路由到一个只包含解锁流媒体效果好的节点的策略组，游戏类域名路由到低延迟优先的 url-test 组，其余流量走通用的自动选择组。这样各类流量都能匹配到最适合的选节点逻辑，而不是用同一套标准应付所有场景。
怎么判断该不该拆分策略组
不是所有场景都需要拆分得很细。判断标准很简单：如果某一类流量对「节点选择逻辑」有明显不同的偏好（比如游戏对延迟极度敏感、流媒体对解锁地区有硬性要求），就值得单独拆一个策略组；如果只是普通网页浏览，用一个通用的自动选择组完全够用，没必要为了「看起来更专业」而过度拆分，那样反而会增加后期维护和排查问题的复杂度。
切换节点后为什么原连接不受影响
手动或自动切换策略组里的节点后，你可能会发现已经建立的连接（比如正在下载的文件、播放中的视频）并不会立刻切换到新节点，而是等这个连接自然结束后，下一次新建连接才会走新节点。这是符合预期的设计：代理层面的节点切换作用于「新建连接」，不会中断已经建立好的会话，这样可以避免频繁切换节点导致正在进行的下载或通话被打断。如果确实需要让所有连接立刻切换，可以在面板的 Connections 里手动关闭旧连接，让程序重新发起新的请求。
小结
没有哪种策略组是「万能」的：追求速度用 url-test，需要明确主备顺序用 fallback，想分摊压力用 load-balance。实际使用中把它们嵌套组合，再用一个手动 select 组兜底，往往是兼顾自动化与可控性的最佳做法。