策略组是把若干节点编成一组,再由组的类型决定当前用哪一个:手动选择由你点,自动测速按延迟挑,故障转移在当前节点不可用时切到下一个,负载均衡把请求分散到多个节点。规则负责决定“这类流量交给哪个组”,策略组负责决定“组里用哪个节点”。
策略组是 Clash 系客户端里一个很容易被忽略、却决定“你到底在用哪个节点”的概念。很多人导入订阅之后,界面里出现一排叫“自动选择”“手动切换”“故障转移”的条目,随手点一下就算配置完了;等到节点变差、连接频繁断开、或者不知道为什么自己选的节点没起作用,才发现需要弄懂这套机制。这篇把策略组的类型、适用场景、测速间隔的取舍和验证办法讲清楚。
策略组是什么:规则之后的第二道分流
先看一次请求在客户端里的旅程:
- 请求到达客户端,先由规则判断它属于哪一类,比如“国内网站”“视频网站”“其他”;
- 规则把它交给某个策略组,比如“视频”这个组;
- 策略组再根据自己的类型,在组里挑出具体的一个节点,请求从这个节点出去。
所以规则管的是“交给谁”,策略组管的是“谁来办”。规则怎么匹配、为什么顺序重要,读 规则分流是什么,而日常切换规则模式的操作,见 Clash 规则模式怎么选。把这两层分开记,排错的时候思路会清晰很多。
clash策略组的四种常见类型
多数订阅里最常出现的是下面四种,具体名称和可选参数以内核文档为准:
| 类型 | 怎么挑节点 | 优点 | 缺点 |
|---|---|---|---|
| 手动选择 | 由你在界面里点选 | 完全可控,不会莫名切换 | 节点变差时得自己发现并切换 |
| 自动测速 | 定期探测延迟,选当前最低的 | 省心,能跟上节点状态的变化 | 可能来回切换,延迟低不等于体验好 |
| 故障转移 | 按顺序用第一个可用的,坏了才换 | 平时稳定,出问题能自动兜底 | 排在前面的节点如果一直“能用但很慢”,不会被换掉 |
| 负载均衡 | 把请求分散到多个节点 | 能分担并发连接 | 同一站点可能从不同出口访问,容易触发网站的异常提示 |
还有一种常被用来把多个节点串起来的类型,一般用户用不到,这里不展开,需要时查官方文档。
节点自动选择:怎么配才不折腾
很多人想要“自动选个最好的”,于是把所有流量都丢给自动测速组。需要留意几件事:
- **延迟低不等于体验好。**自动测速选的是延迟最低的节点,而延迟只是众多指标之一,详见 节点延迟是什么;
- **容差能减少无谓的切换。**如果客户端提供“容差”类设置,可以让它在两个节点相差不大时保持原状,避免为了几毫秒的差距反复切换;
- **切换会打断连接。**正在下载或看直播时,节点一切换,连接可能重新建立,所以自动测速不适合对连接连续性要求很高的场景;
- **探测地址要选得合理。**客户端用某个固定地址来测速,如果这个地址和你实际访问的目标路径不同,选出来的节点未必适合你。
故障转移:把“能不动就不动”变成默认
故障转移的思路和自动测速相反:平时一直用排在最前面的节点,只有它探测不通时,才换到下一个。适合这样的人:
- 有一个自己用着满意的主力节点,不希望它被频繁换掉;
- 想在主力节点偶尔不可用时,有个自动兜底的备胎;
- 对“连接不要无故断开”比较敏感,比如远程办公、长时间下载。
它的盲点前面表里也提到:如果主力节点是“还能连但已经很慢”,故障转移不会察觉,这时需要你自己介入。把它和手动选择配合使用,是比较实用的组合:日常用故障转移,发现异常手动切走。
不同场景,该选哪一种类型
把使用习惯对应到类型上,会更容易做决定:
| 你的情况 | 更合适的类型 | 理由 |
|---|---|---|
| 刚入门,只想先用起来 | 手动选择 | 行为可预测,出了问题也容易判断是哪一步 |
| 有一个满意的主力节点,想要备胎 | 故障转移 | 平时不动,只在不可用时才换 |
| 节点很多、质量参差,想让客户端替你筛 | 自动测速,配上容差 | 跟得上节点变化,又不至于频繁抖动 |
| 需要长时间稳定连接,比如远程办公 | 故障转移或手动选择 | 减少无谓的切换对连接的打断 |
| 需要同时跑大量并发连接 | 负载均衡 | 把请求摊到多个出口,但要留意网站的异常提示 |
如果拿不准,就从手动选择起步,运行一周再看是否需要升级。组的数量也不用多,日常三五个就足够,多了只会让排错变难。
一个简化的结构示意
下面是一个只用来说明层次的结构示意,字段写法为简化示意,不能直接使用:
proxy-groups:
- name: 主用
type: fallback
proxies:
- 节点甲
- 节点乙
- name: 视频
type: select
proxies:
- 主用
- 直连
意思是:“视频”这个组由你手动选择,可选项是“主用”这个故障转移组,或者直连;“主用”组里先用节点甲,甲不可用再换乙。规则命中视频流量时,就会交给“视频”组。真实配置里字段更多,以内核文档为准。
自己验证:策略组是不是在按你想的工作
配置之后,用下面几步确认:
- 在客户端的连接或日志页面,找一条正在进行的连接,看它走的是哪个策略组、哪个节点;
- 手动让当前节点失效(比如暂时选一个不可达的节点放在最前面),观察故障转移是否按预期换到后一个;
- 对自动测速组,隔一段时间看当前选中节点是否变化,变化得是否太频繁;
- 记下节点切换的时刻,对照当时的使用感受,判断策略是否合适。
如果发现流量没有走你期望的组,先回头检查规则,而不是策略组本身。订阅导入的完整步骤见 Clash 订阅怎么导入,测速的方法论见 节点测速怎么做。
几个常见的误解
- **“策略组越多越高级。”**组多了只会让排错变难,日常三五个就够;
- **“自动选择永远选到最快的。”**它选的是探测结果最低的,和实际体验可能不一致;
- **“故障转移会自动换到更快的节点。”**它只在不可用时换,不会因为更快而换;
- **“负载均衡能把速度叠加。”**它分散的是并发连接,单个下载的速度并不会因此翻倍。
下一步:从适合自己的组合开始
新手建议这样起步:规则用默认的国内直连、国外代理;策略组先用手动选择,挑一个稳定的节点;用顺手之后,再考虑给主力节点配一个故障转移的备胎。如果你还在挑机场,可以先用 选机场向导 缩小范围,再到 机场推荐榜 对照资料,买月付档试用一周,再决定怎么组织自己的策略组。
- 本文讲概念和取舍,不提供可直接粘贴的订阅配置;字段写法与参数含义请以内核官方文档为准。
- 自动测速依赖客户端的延迟探测,数字只反映连通情况,不等于真实速度,爱梯子没有任何节点的测速数据。
- 各客户端界面名称不同,本文用通用叫法,具体按钮请以你使用的客户端为准。
资料里明确写了支持 Clash 的几家
把 Clash 写进客户端栏的品牌很少。没写不等于不能用,多数机场都能给 Clash 格式的订阅,只是档案里找不到可以核对的说法。
看 Clash 上手手册 → 数据来自机场档案,价格以官网结账页为准。
本文引用的官方来源
这篇的几个常见问题
策略组和节点是什么关系?
节点是具体的一条线路,策略组是把若干节点(有时还包括别的策略组)归成一组,并规定怎样在组里挑一个来用。规则命中某类流量时,把它交给对应的策略组,策略组再决定落到哪个节点上。你在界面里点选的“节点”,通常就是在某个策略组里点选。
自动测速和故障转移有什么区别?
自动测速会定期探测组内节点的延迟,并选延迟最低的那个,可能在节点之间来回切换;故障转移则按顺序使用第一个可用的节点,只有它不可用时才换到后面的,平时保持不动。前者追求“当下最快”,后者追求“能不动就不动”。
测速间隔设得越短越好吗?
不是。间隔太短会频繁发出探测请求,增加客户端和节点的负担,还可能因为一次波动就切换节点,导致连接反复中断。间隔太长则节点变差后切换得慢。多数人取几分钟一次这样的中间值,并配合容差设置,减少无意义的切换。
负载均衡适合谁用?
适合手里有多个质量相近的节点、并且想把大量并发连接分散开的人。普通浏览和视频用不到它,反而会因为同一个网站的请求被分到不同出口,触发网站的异常登录提示。一般用户用手动选择或故障转移就足够了。