规则集 rule-providers 使用指南

想拦广告，就得在 rules 里手写几百条广告域名？大可不必。规则集（rule-providers）让你像订阅节点一样订阅规则：社区维护、定时更新，你的配置文件只需要一行引用。

规则集是什么

普通规则直接写在 rules 里，一条管一个匹配；规则集则是把成百上千条同类规则打包成一个外部文件，我定时去拉取更新。两者配合使用：

rule-providers 段：声明"有哪些规则包、从哪下载、多久更新"。
rules 段：用 RULE-SET,包名,出口 一行引用整个包。

声明一个规则集

rule-providers 示例

rule-providers:
  reject-ads:
    type: http
    behavior: domain
    url: "https://example.com/ruleset/reject.yaml"
    path: ./ruleset/reject.yaml
    interval: 86400       # refresh once a day

  cn-direct:
    type: http
    behavior: domain
    url: "https://example.com/ruleset/direct-cn.yaml"
    path: ./ruleset/direct-cn.yaml
    interval: 86400

  telegram-cidr:
    type: http
    behavior: ipcidr
    url: "https://example.com/ruleset/telegram.yaml"
    path: ./ruleset/telegram.yaml
    interval: 86400

字段逐个解释：

字段	说明
`type`	`http` 远程订阅（推荐）或 `file` 本地文件
`behavior`	规则格式：`domain`（纯域名）/ `ipcidr`（纯 IP 段）/ `classical`（混合完整规则）
`url`	规则文件的下载地址
`path`	本地缓存路径，断网时用缓存兜底
`interval`	自动更新间隔（秒），86400 = 24 小时

在 rules 里引用

RULE-SET 引用

rules:
  - RULE-SET,reject-ads,REJECT       # thousands of ad domains, one line
  - RULE-SET,cn-direct,DIRECT
  - RULE-SET,telegram-cidr,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

顺序依然重要：拦截类规则集放最前面，直连类其次，兜底 MATCH 永远最后。

behavior 怎么选

三种格式对应不同的匹配性能，选对了能让匹配更快：

domain：内容全是域名时用它，我会构建前缀树，几万条规则命中耗时也在微秒级。
ipcidr：内容全是 IP 段时用它，底层是高效的 trie 结构。
classical：混合了 DOMAIN、IP-CIDR、PROCESS-NAME 等多种类型时才用，灵活但匹配开销最大。

实用建议 社区维护的常见规则集组合是：广告拦截 + 国内直连 + 流媒体分组 + Telegram IP 段。第一次配置直接抄一份成熟的模板改改就好，不必从零开始。

规则集更新失败怎么办

规则集毕竟依赖外部下载，偶尔会遇到更新失败的情况。排查思路按顺序来：

先看本地缓存：path 指向的文件如果存在，我会先用旧版本兜底，不会因为一次更新失败就整个规则集失效，所以你可能完全没感觉到问题——这也是为什么建议隔一段时间主动检查一下更新时间。
检查下载地址是否还有效：社区维护的规则集偶尔会迁移仓库或改路径，在浏览器里直接打开 url 看能不能访问，访问不了就去规则集的项目主页找最新地址替换。
确认 interval 没设置得离谱：见过有人把 interval 设成几十秒，触发了源站的限流反而经常失败，日常场景 43200~86400 秒（12~24 小时）就足够。

常见的规则集去哪里找

不需要自己从零攒规则，GitHub 上有几个长期维护、star 数很高的规则集仓库，覆盖广告拦截、国内直连、流媒体解锁、常见 App 分流等场景，搜索"clash rule providers"或"ruleset"基本都能找到。挑选时留意两点：最近是否还在更新、behavior 类型是否和你的引用方式匹配。规则集和我的客户端本身是两回事——规则集决定"怎么分流"，我负责"怎么连接、怎么调度"，两者配合才能既干净又好用。

把广告拦截规则集接进来之后，很多网页上讨厌的横幅广告会直接从源头消失，比装浏览器插件还省心——毕竟这是在网络层拦截，所有设备、所有 App 都能一起生效。

手写规则和规则集要怎么配合，而不是二选一

很多人一上手规则集就把所有手写规则全删了，其实不必这么彻底。两者的定位不同：规则集适合处理"数量庞大、更新频繁、自己维护不现实"的场景，比如成千上万条广告域名或者随时可能变化的流媒体 IP 段；手写规则则更适合"数量很少但你非常在意优先级、需要精确控制"的场景，比如公司内网域名、自己常用的几个特殊网站。

推荐的写法是：把个性化的手写规则放在最前面，确保它们优先命中；规则集紧随其后处理大批量的通用分类；最后用 GEOIP,CN,DIRECT 和 MATCH 兜底。这样既保留了灵活性，又不用为了几百条广告域名把配置文件撑到几千行，维护成本大幅下降。

一个新手最容易忽略的细节：规则顺序真的会影响结果

规则是自上而下逐条匹配的，第一条命中就立即生效，后面的规则即使写得再对也不会被执行到。所以如果你发现某个网站"明明配了规则却没生效"，八成不是规则写错了，而是前面某一条更宽泛的规则（比如某个规则集里的通用条目）提前把它拦住了。排查这类问题最快的办法是打开控制面板的连接页，直接看这条连接实际命中的是哪一条规则，而不是对着配置文件干猜——这一点在讲控制面板的那篇文章里也提到过，两者结合起来用效率会高很多。

小结

规则集把"人工维护规则"这件苦差事交给了社区和自动更新，你要做的只是声明来源、选对 behavior、按正确顺序引用。记住三个关键点：拦截类放最前面，直连类紧随其后，MATCH 永远兜底；behavior 要和规则集本身的内容格式对应，选错会导致匹配变慢甚至报错；更新失败时先看本地缓存是否还在生效，再排查下载地址和更新间隔。配置一旦搭好，后续几乎不用再手动维护，规则集自己就会随着社区更新保持新鲜。

如果你目前配置文件里还堆着几百条手写的域名规则，不妨挑个周末抽半小时时间，把能替换成规则集的部分都换掉——配置文件会立刻清爽很多，日后维护也不再是负担。