先理解 rule-providers：把规则从主配置中拆出来

Clash 的规则匹配是一个按顺序执行的过程：客户端收到连接请求后，会根据域名、目标 IP、进程名或其他条件，从上到下检查 rules 列表，命中第一条规则后就交给对应的策略组处理。规则少时，直接把内容写在主配置文件里很直观；但当规则增长到数百甚至数千条，主配置会变得难以阅读，也不方便多人协作和定期更新。

rule-providers 的作用，就是把一组规则单独保存为 YAML、YAML 兼容的文本文件或纯规则列表，再通过主配置引用它。主配置只负责声明规则集名称、来源、更新周期和规则类型，具体规则则由独立文件维护。这样做的好处不仅是文件更短，还能把广告过滤、流媒体、办公服务、国内直连等规则按用途拆分，出现误匹配时也更容易定位。

需要区分的是，rule-providers 管理的是分流规则，而 proxy-providers 管理的是代理节点与代理组成员。前者回答「这个域名应该走哪种策略」，后者回答「代理策略组里有哪些节点」。两者可以同时使用，但不能把节点订阅 URL 填到规则集配置中，否则客户端下载后无法按预期解析。

核心思路

主配置保持稳定，规则文件独立更新；规则集名称用于引用，策略组名称用于执行。先确认这两类名称分别对应什么，再开始拆分配置，排错会简单很多。

rule-providers 的 YAML 结构与关键参数

在 Mihomo、Clash.Meta 以及兼容的 Clash 客户端中，规则集通常放在主配置的 rule-providers 节点下。每个规则集需要一个唯一名称，例如 github、streaming 或 private-network。名称只能由字母、数字、下划线和短横线组成时最稳妥，后续会通过 RULE-SET 规则引用它。

一个可运行的主配置片段

rule-providers:
  github:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/example-user/clash-rules/main/github.yaml
    path: ./ruleset/github.yaml
    interval: 86400
    format: yaml

  private-network:
    type: file
    behavior: classical
    path: ./ruleset/private-network.yaml
    format: yaml

rules:
  - RULE-SET,private-network,DIRECT
  - RULE-SET,github,PROXY
  - MATCH,DIRECT

type 决定规则来源。http 表示通过 URL 下载，适合托管在 GitHub、自己的静态服务器或其他可信 CDN 上；file 表示读取本地文件，适合公司内网、个人维护或不希望公开的规则。部分内核还支持其他来源类型，但不同客户端版本的兼容范围并不完全相同，迁移配置前应以当前内核文档和启动日志为准。

behavior 描述规则文件的组织形式。classical 适合包含完整 Clash 规则表达式的文件，例如 DOMAIN-SUFFIX,github.com 或 IP-CIDR,192.168.0.0/16,no-resolve；domain 适合每行一个域名或域名后缀的简化列表；ipcidr 则用于 IP 地址和网段。behavior 与远程文件实际内容不一致时，最常见的结果是启动报错、规则集为空，或者更新成功但始终无法命中。

path 是下载后的本地缓存位置。使用相对路径时，通常相对于 Clash 配置目录，而不是操作系统当前工作目录。建议统一放在 ruleset 子目录，并避免使用包含空格、中文或特殊符号的路径。interval 使用秒作为单位，86400 代表每天更新一次；规则并不需要每几分钟下载，过于频繁会增加 GitHub 请求压力，也可能触发限流。

format 用于告诉内核文件是 YAML 结构还是纯文本。若规则文件带有 payload 字段，通常使用 yaml；若服务端返回的是每行一条规则的文本，也可以根据内核支持情况使用 text。不要仅凭文件扩展名判断格式，应该打开文件确认顶层结构。

使用 GitHub 托管规则集的实践方法

GitHub 适合托管公开、可审计、更新频率适中的规则集。建议为规则单独建立仓库，而不是把大量规则直接混在个人配置仓库中。一个清晰的目录可以包含 ruleset/、README.md、许可证文件和用于校验格式的脚本。README 中应说明规则来源、适用范围、更新时间、已知误判以及提交规则，方便未来自己或其他协作者理解。

创建一个专门的 GitHub 仓库，例如用于维护个人 Clash 规则。
在仓库中按用途建立文件，如 github.yaml、ai-services.yaml 和 private-network.yaml。
每个文件开头写明文件格式，确保内容与 behavior 配套。
提交后通过 GitHub 的 Raw 地址访问文件，确认返回的是规则内容而不是网页 HTML。
将 Raw 地址填入 url，在客户端手动更新并查看更新日志。

GitHub 网页地址与 Raw 地址不是一回事。下面这种地址打开的是网页界面，不能直接作为规则下载源： https://github.com/example-user/clash-rules/blob/main/github.yaml。应改用对应的 Raw 地址： https://raw.githubusercontent.com/example-user/clash-rules/main/github.yaml。如果仓库分支或文件名发生变化，旧 URL 会返回 404，Clash 可能继续使用本地旧缓存，因此更新后一定要观察时间戳和文件内容。

托管时要留意安全边界

不要把订阅链接、私有节点信息、访问令牌或带有个人身份的日志提交到公开仓库。GitHub 提交历史通常可以长期追溯，即使后来删除文件，敏感信息也可能仍存在于旧提交中。公开规则仓库只放可公开审计的规则内容，私有规则使用本地文件或权限受控的服务器。

GitHub Raw 并不保证任何网络环境下都能稳定访问。若规则集对日常连接非常关键，可以准备一个可信的镜像地址，或将规则文件部署到自己的静态站点。镜像并不意味着盲目复制：每次同步后应比较文件大小、HTTP 状态码和内容摘要，避免上游异常页面被误当作规则文件保存。

设计可维护的规则文件与引用顺序

规则集拆分的重点不是「拆得越多越好」，而是让每个文件拥有清晰、单一的职责。可以把长期稳定的局域网规则、变化较快的服务域名规则和容易误判的例外规则分开。文件名称应表达用途，而不是使用含糊的 new.yaml、test2.yaml。当规则数量变多时，明确的命名能够直接降低维护成本。

推荐的规则文件内容

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,githubassets.com
  - DOMAIN,api.github.com

主配置中的引用顺序非常重要。RULE-SET 并不是全局标签，而是一条普通规则，仍然遵循从上到下的优先级。例如某个域名同时属于广告规则和流媒体规则，排在前面的规则集会先命中。通常应先放局域网与自定义例外，再放隐私或广告规则，然后放业务分类规则，最后使用 GEOIP、MATCH 等兜底规则。

局域网规则优先：将私有网段、路由器地址、NAS 域名放在前面并指向 DIRECT。
个人例外优先：需要强制代理或强制直连的域名，不要埋在大型公共规则集之后。
规则集保持专一：不要把广告、办公、游戏和流媒体规则全部混成一个文件。
保留兜底规则：最后至少有一条 MATCH，避免未匹配连接的行为因客户端而异。

如果规则集使用的是域名匹配，DNS 模式也会影响结果。某些应用先解析域名再直接连接 IP，可能需要使用 IP-CIDR、no-resolve 或更完整的 Mihomo 配置配合。不要看到一条域名规则没有命中，就立刻判断 rule-provider 失效；应先在连接日志中确认请求的原始域名、解析结果、命中的规则类型和最终策略组。

更新、验证与故障排查流程

规则集的自动更新让配置更省心，但也引入了远程内容变化、网络失败和格式错误等问题。建议第一次接入时不要直接把它放到全局关键链路中，而是先复制一份配置，在客户端手动更新规则集，确认下载成功后再启用自动更新。对于生产环境或多人共享配置，还应记录最近一次成功更新时间。

在浏览器中打开规则 URL，确认状态码为 200，并检查返回内容不是 GitHub 错误页。
查看文件顶层结构，确认 payload、规则表达式和缩进符合预期。
检查主配置中的规则集名称与 RULE-SET 引用名称完全一致。
手动更新后观察客户端日志，确认缓存文件被写入且规则数量不是零。
用一个明确的测试域名发起连接，在日志中核对命中的规则和实际策略。

常见的「配置加载成功但规则不生效」通常有四类原因。第一，规则集名称拼写不一致，例如定义为 github-rules，引用时却写成 github。第二，behavior 与文件格式不匹配。第三，前面已有更宽泛的规则先命中，例如 DOMAIN-SUFFIX,com,DIRECT 放在自定义规则之前。第四，客户端实际运行的不是刚修改的配置文件，尤其是同时存在订阅配置、Mixin 和本地配置时更容易发生。

排错建议

先把目标域名写成一条临时的明确规则，确认策略组本身可用，再测试 rule-provider。若临时规则有效而规则集无效，重点检查 URL、缓存、格式和引用顺序；若临时规则也无效，则应转向检查当前配置是否被客户端真正加载。

对 GitHub 仓库中的规则可以使用 Pull Request 做审核。提交者说明新增域名的来源和用途，维护者检查是否过宽、是否包含 IP 误判、是否与现有规则重复，再合并到主分支。对于自动生成的规则，最好在 CI 中执行 YAML 语法检查、重复项检测和空文件检测。这样即使规则每天自动更新，也不会因为一次错误提交让所有客户端同时下载坏文件。

一套适合长期维护的配置模板

下面的模板体现了「来源独立、引用清楚、顺序可审计」的思路。实际使用时，请将示例地址替换成你自己维护且能够信任的仓库，并根据客户端内核支持情况调整参数。策略组名称必须与配置中已经定义的名称一致，不能直接照抄后忽略自身配置。

rule-providers:
  personal-direct:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/example-user/clash-rules/main/personal-direct.yaml
    path: ./ruleset/personal-direct.yaml
    interval: 43200
    format: yaml

  services-proxy:
    type: http
    behavior: domain
    url: https://raw.githubusercontent.com/example-user/clash-rules/main/services-proxy.txt
    path: ./ruleset/services-proxy.txt
    interval: 86400
    format: text

rules:
  - RULE-SET,personal-direct,DIRECT
  - RULE-SET,services-proxy,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

这套结构适合先从两个规则集开始：一个放个人直连例外，一个放需要代理的服务域名。运行稳定后，再按真实需求拆分广告、流媒体、办公和开发平台规则。每增加一个规则集，都应该回答三个问题：它解决了什么问题、它为什么放在当前顺序、出现误判时如何快速撤回。若无法回答，继续拆分只会增加复杂度。

与把所有内容塞进单一订阅配置的方式相比，GitHub 托管的 rule-providers 更容易查看变更记录、回滚错误提交，也便于在 Windows、macOS、Android、Linux 和路由器上的 Mihomo 客户端之间复用。不过，部分封闭客户端对高级字段、自动更新或特定规则格式的支持并不一致，配置发布前最好在实际使用的平台上做一次加载和命中测试。

一些同类代理工具往往要求用户把规则、节点和界面设置混在一个大型配置文件中，规则更新时容易覆盖本地改动，遇到错误也缺少清晰的命中日志。Clash 通过 rule-providers 将规则来源、缓存位置和匹配顺序分开管理，并配合可视化日志、规则模式和跨平台内核，让自定义分流更容易审计、回滚与迁移。如果你希望在图形界面中直接验证这些配置，不妨前往下载 Clash，先用一份小型 GitHub 规则集完成测试，再逐步扩展到自己的完整规则体系。