Clash 规则分流进阶：策略组、规则集与常用模板怎么写

先理解三个概念

Clash 的分流模型很简单：

流程是：请求进来，按规则从上到下匹配，命中就交给对应策略组，策略组再决定用哪个节点。

基础操作先读 Clash 使用教程。桌面端具体入口见 Clash Verge Rev 教程。

策略组类型

新手建议：日常用 url-test，要求稳定出口的用 select。

规则类型与顺序

常用规则写法如下，每条的格式是「类型,内容,策略组」：

顺序原则：

1. 越具体的规则越靠前。
2. 宽泛的规则（GEOIP、MATCH）靠后。
3. 你自己的规则放订阅规则前面，用 Merge 的 prepend 即可。

规则集 rule-provider

手写几百个域名既累又容易漏。规则集把它们打包成一个列表，通过链接订阅，自动更新。

示意写法：

rule-providers:
  ai-sites:
    type: http
    behavior: domain
    url: "你信任的规则集地址"
    interval: 86400
rules:
  - RULE-SET,ai-sites,AI

要点：

• behavior 要和规则集内容类型一致，比如 domain、ipcidr、classical。
• 来源要可信。规则集决定你的流量去哪，别乱用不明来源。
• interval 单位是秒，一天更新一次通常够用。

常用模板思路

下面是三个常见需求的思路，不绑定具体写法，按你的订阅调整。

AI 工具固定出口

AI 服务对出口地区较敏感。新建一个 select 策略组 AI，只放你确认可用的节点，再把相关域名指向它。选哪些地区更合适见 AI 用哪个机场稳定。

流媒体分流

建一个 select 组「流媒体」，放订阅里标注了解锁的节点，把对应域名规则指过去。解锁能力要看机场和节点，参见 流媒体解锁指南。

国内直连与广告拦截

国内常见域名用 DIRECT。可以用 GEOIP,CN,DIRECT 兜底，再加广告规则集指向 REJECT。

不被订阅覆盖

订阅更新会覆盖对订阅文件的改动。正确做法：

对应教程见 Stash 使用教程。

调试规则

规则不对时按下面步骤查：

1. 在日志页看这个请求命中了哪条规则。
2. 确认策略组名称与规则里的完全一致，包括大小写。
3. 暂时切到全局模式，确认问题是出在规则而不是节点。
4. 把可疑规则挪到最前面测试。

规则和节点都没问题还是不通，回到 连接故障排查。

几个常见误区

把所有流量都交给代理

全局模式看起来简单，但会让国内网站也绕一圈，速度变慢，流量也被白白消耗。日常用规则模式，只让需要的走代理。

规则堆得太多

规则不是越多越好。过多的手写规则会让排错困难。优先用成熟的规则集，自己只补少量例外。

策略组命名随意

名字改了，规则里没跟着改，就会报错或不生效。策略组名称建议简短统一，比如 AI、流媒体、直连。

忽略 DNS

分流不止是规则，DNS 解析的结果也会影响命中。遇到某些域名总是走错，除了看规则，也看看 DNS 设置是否正常。

一个够用的最小配置思路

对大多数人来说，下面这套就足够：

1. 一个自动选择组，用于日常。
2. 一个 AI 组，固定可用节点。
3. 一个流媒体组，放有解锁标注的节点。
4. 国内规则集走直连，广告规则集走拒绝。
5. 最后一条 MATCH 指向自动选择组。

按这个骨架搭好，再按自己的使用习惯微调就行。

小结前的建议

动手前先备份现有的配置。每次只改一处，改完测试，确认没问题再改下一处。一次改很多条，出了问题就很难定位。

规则分流是个慢慢调的过程，不用一开始就追求完美。用一段时间，把总是走错的域名补上，几周后规则就会很顺手。

总结

规则分流不复杂：节点放进策略组，规则决定交给谁，顺序决定结果。

自定义写在 Merge 或覆写里，用规则集省去维护，最后用 MATCH 兜底。

线路本身质量也影响体验，选线路见 IEPL 是什么。