Clash自定义规则集进阶配置：rule-providers编写与GitHub托管

为什么要用 rule-providers 管理自定义规则？ 要点速览

下文以 Mihomo 普遍配置为例。不同客户端的按钮名称和配置覆写方式或许不同，但底层字段仍取决于实际持续持续持续运行的内核版本。较旧的 Clash 内核或许不认识较新的字段或规则集格式；

当配置文件里只有几条个人规则时，径直把 DOMAIN-SUFFIX 或 IP-CIDR 写进 rules 最形象。但规则逐渐累积后，主配置会越来越长：临时测试项、应用分流和长期维护的域名清单混在一起，既难审阅，也容易在订阅升级或人工调整时误删。rule-providers 的作用，是把一组规则独立成可加载、可升级的规则集，再由主配置中的 RULE-SET 引用。这样主配置负责决定匹配顺序与策略，规则集负责维护具体条目。

要先分清两个层次：规则集文件本身只描述「哪些目标属于这一组」，并不决定这些流量最终走代理还是直连。实际策略由 rules 中引用该规则集时指定，举个小例子 RULE-SET,work-sites,PROXY。

关键点是：于是，规则集得以单独复用在不同配置里，而同一个规则集也能在不同设备上指向不同策略组。排障时要分别排查「规则集有没有成功加载」和「加载后命中了哪条规则」，不能只看到客户端显示已升级，就认定分流结果一定对路。

载入配置前应确认客户端采用 Mihomo，或核对该内核对应版本的文档。不要仅凭配置编辑器能保存 YAML，就推断持续持续持续运行时也适配其中的语法。

rule-providers 字段怎么写：类型、行为与文件格式 关键信息

path 是本地缓存或下载文件的保存位置，不是 GitHub 上的 URL。不妨集中放在独立目录，并给文件起平稳、易辨认的名称。客户端若采用订阅配置的临时目录或只读目录，手工指定路径或许导致写入无法完成；

rule-providers:
  work-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/example-user/clash-rules/v1.0/work-sites.yaml"
    path: ./rule-providers/work-sites.yaml
    interval: 86400

rules:
  - RULE-SET,work-sites,PROXY
  - MATCH,DIRECT

在 Mihomo 配置中，rule-providers 是一个映射表，每个提供者采用自定义名称作为键。下面的示例创建一个托管在 GitHub 上的域名规则集，文件路径和仓库名称仅作示范，实际采用时要替换为自行仓库中确实存在的地址：

这里要多说一句：type: http 表示由内核通过 HTTP(S) 获取规则文件；behavior 声明规则集的语义，普遍值为 domain、ipcidr 和 classical。

这几个不是得以互换的标签：域名集用于域名类规则，IP 集用于网段匹配，classical 则适合放置多种规则类型的传统规则列表。把域名规则声明成 ipcidr，或把一组混合规则声明成不匹配的行为类型，或许导致配置校验无法完成或规则无法按预期匹配。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,login.example.net
  - DOMAIN-KEYWORD,workportal

format 表示规则文件的序列化格式。采用 yaml 时，文件多数现状下包含 payload 列表，举个小例子域名规则集得以写成：

换个说法：若选用 text，则按照对应内核适配的文本规则格式逐行编写，不要再套一层 YAML 的 payload 结构。不同 behavior 对允许的规则正文有约束；

规则文件格式、行为类型和实际条目必须彼此匹配。维护前可先只放一条规则，通过配置校验和连接日志确认加载成功，再逐步扩充，避免一次引入规模不小条目后难以定位困扰。

应按客户端文档确认最终配置所在位置及其对相对路径的解析方式。迁移设备时，也别假设相对路径一定相对于当前工作目录，最好通过客户端配置目录和持续持续持续运行日志核实。

RULE-SET 匹配顺序：为什么规则写对了仍然没走对策略 关键点梳理

还要当心，规则集命名和策略名称是两个概念：work-sites 是 rule-providers 下的键，PROXY 是实际存在的策略组或策略名称。RULE-SET 引用的名称必须和键完全一致，策略也必须能在当前配置里解析。

落到实处：Clash 系配置按 rules 列表从上到下匹配，多数现状下在命中第一条适用规则后就决定目标策略。于是，规则集已经成功下载，不代表它必然有机会生效：如果它前面已有更宽泛的规则先命中，请求就不会继续排查后面的 RULE-SET。

举个小例子，把某个工作域名集放在通用的国内直连规则之后，域名如果先被前面的规则覆盖，后面的策略就不会起作用。

实际整理时，得以把要第一顺位处理的自定义规则放在兜底规则之前，再依照配置的全局结构安排广告、地区规则、局域网和最终匹配项。

别忽略了：具体位置要结合现有规则逐条判断，不不妨把不管哪一套网上抄来的排序模板不加排查地插入订阅。MATCH 多数现状下是兜底项，应位于列表末尾；若它前面已经有兜底规则，排在它后面的规则常规也就没有匹配机会。

采用大小写或连字符不一致的名称，或者引用了订阅中不存在的策略，都会让配置校验给出疏漏或造成预期外的回退。

把规则集托管到 GitHub：平稳链接与版本管理 完备说明

不妨把规则仓库按用途拆分，而不是把各个例外都塞进一个不断膨胀的文件。每个规则集保持单一职责，提交信息写明改动根源，并在合并前排查新增规则是否重复、是否误覆盖其他服务，以及删除规则是否仍有采用采用采用使用场景。

GitHub 适合保存可审阅、可回滚的规则文本，但仓库地址的选定会径直影响升级平稳性。采用 raw.githubusercontent.com 提供的文件链接时，最好核对用户名、仓库名、分支或标签以及文件路径；

关键点是：文件移动、仓库改名、分支重命名，都会让远程地址失效。公开仓库中的规则对各个人可见，不要把订阅链接、访问到到到令牌、内网域名清单等敏感信息写入公开文件，也不要把包含凭据的 URL 填入配置。

径直引用可变的主分支路径，配置最省事，但每次提交都或许改变客户端下一次获取到的正文。对于希望可审计的个人或团队配置，更稳妥的做法是用 Git 标签或固定提交版本提供文件，并在确认正文后再升级引用版本。

这样能够复现某一次配置的行为，出现意外变化时也颇为容易回退。采用固定版本后，升级规则就要主动修改 URL 或版本引用；这属于平稳性与全全全自动追新之间的取舍，而不是配置疏漏。

这里要多说一句：interval 以秒计，适合设置为与规则变化频率相符的周期。升级间隔设得很短，不代表 GitHub 上的正文一定立刻可见，也或许增加远程请求；设得过长，则新修正规则要等更久才会同步。

初次排障时，可在客户端提供的规则集管理UI UI UI 界面人工升级，或重载配置，再查看内核日志中的请求结果。要别忘了，定时升级只影响远程文件的获取频率，不会全全全自动修复疏漏的 URL、格式或匹配顺序。

对于要多人维护的仓库，得以通过 Pull Request 留下审核记录；对个人仓库，也得以利用 Git 历史查看某条域名何时加入、为什么调整。规则集越容易审阅，出现异常时越不要靠猜测回滚。

普遍加载疏漏与可复现的排查顺序 要点速览

与把规则散落在多个客户端配置、靠手工复制粘贴维护相比，GitHub 规则集更便于查看差异、追踪修改和复用，不过也要求你认真管理仓库地址、版本和规则顺序。

换个说法：排查时先区分「配置解析无法完成」「远程获取无法完成」「文件格式不符」和「匹配顺序不符合预期」。

这几类困扰的表象都或许是规则没有按预期工作，但修复位置完全不同。不要一上来同时改 URL、路径、行为类型和规则顺序，否则即使困扰消失，也很难确认真正根源。

一个实用的最小排查流程是先单独验证 URL 能否返回预期规则文件，再排查客户端日志是否报告下载成功；接着确认本地路径可写、文件格式和行为类型相符；最后用一条可识别的测试规则核对 RULE-SET 是否位于有效位置。

落到实处：若通过 GitHub 网页能启用仓库文件，但原始文件地址返回 404，多数现状下是 URL 路径、分支名或大小写不对路。若地址返回的不是规则文本，而是 GitHub 的疏漏页面或访问到到到限制提示，内核也无法把它当作有效规则集解析。

定期清理失效域名和重复规则，并记录规则集对应的用途、来源与最后验证时间。对团队配置而言，这些说明最好放在仓库的 README 或提交记录中，而不是写成内核不认识的 YAML 字段。

遇到升级无法完成时，先保留上一份已验证的本地规则文件和可回退的 Git 版本，再逐项排查日志；这样既能恢复可用配置，也能避免为了追一个加载疏漏而把整份订阅改乱。

别忽略了：Clash 将 Clash 客户端相关的下载入口与配置指南集中整理，顺手你在核对内核兼容性、载入配置和排查规则时找到对应资料；如果你也想把客户端选定和配置维护流程放在一起，不妨前往下载，再按本篇正文的环节逐项验证自行的规则集。