Clash rule-providers进阶配置：用GitHub管理自定义规则集

NT-06.1rule-providers 是什么:把规则从主配置中拆出来

Clash 的 rules 字段负责决定一条连接最终交给哪个策略组,但当规则数量增加到几十条、几百条甚至更多时,把所有内容直接写在主配置文件里会变得难以阅读和维护。rule-providers提供了一种拆分方式:主配置只声明规则集的名称、来源、格式与更新周期,具体规则则保存在独立的 YAML、文本或远程文件中。

使用 rule-providers 后,规则匹配链路会多一层。Clash 启动或更新配置时,先根据 provider 定义加载外部规则文件;收到连接请求后,内核按照 rules 中的顺序逐条匹配,遇到类似 RULE-SET,apple,PROXY 的引用,再进入名为 apple 的规则集进行判断。规则集本身不会自动决定代理节点,它只负责提供匹配条件,真正的出口仍由 RULE-SET 后面的策略组名称决定。

因此需要区分三个概念:规则文件是被托管的具体条目,provider 是对这份文件的配置描述,rules 中的 RULE-SET 则是把它接入主规则链的引用。如果只写了 provider 而没有在 rules 中引用,规则集不会参与流量分流;如果 RULE-SET 名称拼错,客户端也无法找到对应的 provider。

NT-06.2编写 YAML:HTTP provider 与本地规则文件

mihomo 常用的远程规则集配置包含 type、behavior、url、path 与 interval。其中 type 表示规则集来源类型,远程文件通常使用 http; behavior 描述规则内容属于域名类、IP 类还是经典规则格式; path 是下载后保存到本机的缓存位置。

rule-providers:
  personal-sites:
    type: http
    behavior: domain
    url: https://raw.githubusercontent.com/example-org/clash-rules/main/personal-sites.txt
    path: ./ruleset/personal-sites.yaml
    interval: 86400

  office-network:
    type: http
    behavior: ipcidr
    url: https://raw.githubusercontent.com/example-org/clash-rules/main/office-network.txt
    path: ./ruleset/office-network.yaml
    interval: 43200

rules:
  - RULE-SET,personal-sites,PROXY
  - RULE-SET,office-network,DIRECT
  - MATCH,PROXY

上面的地址只是结构示例,实际使用时应替换为自己维护且可以稳定访问的仓库文件。path 不只是临时文件名,它还是客户端离线启动时使用的本地缓存位置。首次启动无法访问远程地址时,如果缓存文件已经存在,部分客户端可以继续使用上一次成功下载的内容;首次从未成功下载过则不会凭空生成规则。

behavior 必须和文件内容对应。域名规则集可以使用 behavior: domain,例如每行一个域名;IP 网段规则使用 ipcidr;如果文件包含 DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR 这类带动作的完整规则行,则应使用 classical。不同 mihomo 版本和客户端对格式细节可能存在差异,导入后要查看日志或规则集状态,不能只看 YAML 是否能保存。

按内容选择 behavior

• domain:文件通常只包含域名,例如 example.com 或 +.example.com,由 provider 类型为这些条目补充匹配行为。
• ipcidr:文件包含 IPv4 或 IPv6 网段,例如 192.168.0.0/16,适合局域网、企业网段或固定地址集合。
• classical:文件保留完整规则表达式,可以在同一个集合里混用域名、关键词和 IP-CIDR,但维护时必须严格保持每行语法。

NT-06.3用 GitHub 拆分规则集:目录、提交与发布边界

GitHub 适合托管规则集,并不是因为它能替代 Clash 的配置管理,而是因为仓库提供了目录结构、提交记录和变更回溯能力。建议把主配置与规则文件分开考虑:主配置负责节点、策略组和引用关系,仓库负责规则条目的来源、审阅与版本记录。这样更新某一类域名时,不必频繁改动包含敏感节点信息的主配置。

仓库目录可以按用途拆分,例如将广告过滤、办公域名、国内直连、个人例外分别放在独立文件中。文件名应反映实际用途,不要使用过于宽泛的 rules.txt。如果一个规则集同时承担直连和代理两种相反用途,后期很容易在策略组调整时误用,拆分成职责单一的集合更容易检查。

clash-rules/
├── README.md
├── domains/
│   ├── direct-domains.txt
│   ├── proxy-domains.txt
│   └── work-domains.txt
├── cidr/
│   └── office-network.txt
└── releases/
    └── 2026-08-02.txt

规则文件每行放一条记录,建议统一使用 UTF-8 编码,避免把说明文字、Markdown 标题或不可见字符混入集合。提交信息应说明修改范围,例如新增了某个服务的域名、删除了失效网段,而不是只写“update”。当规则影响范围较大时,先通过 Pull Request 或独立分支检查内容,确认没有误把测试域名、私有地址或敏感信息提交到公开仓库。

远程 URL 最好固定到明确的分支或发布版本,不要在生产配置中随意引用会频繁变化的开发分支。引用固定提交内容可以提高可复现性;如果使用分支地址,则应接受它会随着仓库提交自动变化,并配合测试和更新记录。需要注意的是,规则文件公开托管后,文件地址、提交历史和仓库内容都可能被访问,不要把订阅链接、节点密码或私人域名清单和公共规则混放。

NT-06.4规则优先级:外部规则集不是独立的分流层

Clash 规则采用从上到下的顺序匹配,一旦某条规则命中,后面的规则就不会继续参与判断。RULE-SET 和 DOMAIN-SUFFIX 没有天然的“外部优先”关系,谁写在前面谁先获得匹配机会。一个宽泛的规则集如果放在前面,可能会提前截获本应交给更具体规则处理的域名。

rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - RULE-SET,proxy-domains,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

例如 internal.example.com 同时出现在代理域名集合中,上面的精确后缀规则会先命中,因此连接走 DIRECT。如果把 RULE-SET,proxy-domains,PROXY 放到第一行,内部域名可能已经被代理集合截获,后面的例外规则完全没有机会执行。

1. 先放本机、局域网和企业内网等必须直连的精确例外,避免被宽泛集合覆盖。
2. 再放用途明确的自定义域名集,例如工作代理集、媒体代理集或测试集。
3. 之后放较宽泛的第三方规则集,并检查它们之间是否存在重叠。
4. 最后处理 GEOIP、MATCH 等兜底规则,尤其不要把 MATCH 放在所有 provider 之前。

NT-06.5自动更新与生产环境版本管理

interval 的单位通常是秒,例如 86400 表示每天更新一次。它控制的是客户端检查远程规则的周期,不是 GitHub 仓库的发布周期,也不代表每次检查一定会下载成功。更新频率应根据规则变化速度和托管服务的承载能力设置,普通域名清单每天一次已经足够,频繁变动的临时规则才需要缩短周期。

自动更新的配置示例如下:

rule-providers:
  work-domains:
    type: http
    behavior: domain
    url: https://raw.githubusercontent.com/example-org/clash-rules/main/domains/work-domains.txt
    path: ./ruleset/work-domains.yaml
    interval: 21600

生产环境不建议只依赖“远程文件当前是什么样”这一种状态。更稳妥的做法是把规则变更分成编辑、检查、发布三个阶段:先修改仓库文件,再检查重复项、空行、拼写和是否误加入私有地址,最后合并到生产引用的分支。对影响范围较大的变更,可以先在单独的测试配置中引用,确认连接日志和策略组结果正确后再切换。

• 保留回滚点:每次发布都使用清晰的提交记录,发现误分流时可快速定位最近变更。
• 区分测试与生产:测试规则集可以缩短更新周期,生产规则集则固定到经过确认的版本或分支。
• 检查缓存状态:更新失败时确认本地 path 是否仍有旧文件,并查看日志中的 HTTP 状态、解析错误或超时信息。
• 避免更新过密:规则文件没有变化时不需要反复提交,客户端也不必设置极短的轮询间隔。

NT-06.6配置完成后的验证顺序

rule-providers 配置完成后,建议使用一个明确可判断的测试域名,而不是直接凭整体上网体验下结论。先确认 provider 是否成功下载,再确认规则集是否被主规则引用,最后确认策略组是否按预期执行。三层中任意一层失败,表现都可能只是“规则没有生效”。

1. 在客户端的规则集、配置或日志页面确认 provider 已加载,检查远程请求是否返回成功,并留意文件解析错误。
2. 核对 provider 的名称,确保 rules 中的 RULE-SET 使用完全相同的拼写,包括连字符、大小写和缩进。
3. 检查规则文件内容是否符合声明的 behavior,确认没有把完整规则行误放入 domain 类型集合。
4. 用测试域名发起一次新连接,查看日志中的命中规则、provider 名称和最终策略组,必要时先清理旧连接后重新访问。
5. 临时注释或下移宽泛规则,验证是否存在前置规则抢先匹配;确认后再恢复最终顺序。

当 provider 更新失败但旧缓存仍可用时,界面可能看起来一切正常,这也是生产环境容易忽略的隐患。定期查看更新时间和日志,比等到规则突然失效后再处理更可靠。对于涉及内网、办公系统或关键服务的集合,每次调整都应至少验证直连、代理和兜底三类结果,避免一次错误提交影响整组设备。