前言：为什么把规则拆成 rule-providers？
当 Clash 配置中的规则越来越多时，把所有域名和 IP 规则都写在主配置文件里，会让配置变得冗长，也不方便单独维护。rule-providers 可以将一组规则放在独立文件中，再由主配置按需引用。规则集更新时，只需要维护托管文件，不必每次手动编辑整份配置。
本文以 Mihomo 为例，演示如何将自定义规则托管在 GitHub，并在配置中定义规则提供者、设置更新间隔和安排规则顺序。Clash Verge、Clash Verge Rev 等客户端能否使用此功能，取决于它们实际运行的内核版本；配置字段应以所用内核支持的功能为准，而不是只看客户端名称。
先确认内核支持
rule-providers 属于内核配置能力。若配置提示字段不受支持，请先确认当前客户端使用的是 Mihomo 或兼容内核，并查看该内核版本对应的配置文档。
1准备 GitHub 规则文件
先在 GitHub 仓库中创建一个专门存放规则的文件，例如 rules/custom-services.yaml。建议使用公开仓库的默认分支，并通过文件页面的 Raw 链接获取原始文件地址。配置里的 url 必须指向原始内容，不能直接填写 GitHub 网页展示地址；网页地址通常包含 HTML 页面，而不是 Mihomo 能解析的规则 YAML。
将规则文件按用途拆分，比维护一个不断增大的万能规则集更清晰。例如，可以分别管理工作软件、个人直连域名和测试规则。文件名与仓库目录可以自行设计，但要保持稳定；如果改动路径或分支，记得同步修改主配置中的 URL。
选择规则格式
最适合入门的做法是采用 classical 行格式。它允许规则文件直接包含完整匹配类型，例如 DOMAIN-SUFFIX、DOMAIN 或 IP-CIDR。下面是一个简化示例：
这里的 payload 是规则内容列表，规则项不需要在文件内写策略名称。规则集被主配置引用时，再由 RULE-SET 指定策略。请使用普通文本保存文件，并检查缩进、冒号、逗号与引号，避免混入全角标点或不合法的 YAML 结构。
不要发布敏感信息
公开仓库中的规则内容任何人都可能访问。规则文件不要包含订阅链接、访问令牌、私有域名清单或其他凭据。还要注意，仓库历史可能保留曾经提交过的敏感内容。
2在 Mihomo 中声明 rule-provider
规则文件推送到 GitHub 后，在主配置中添加 rule-providers 项。示例使用 GitHub 原始文件地址，并采用 classical 行格式。请将示例 URL 替换成自己的仓库地址、分支名和文件路径。
- type: http：表示从 HTTP 或 HTTPS 地址获取规则文件。
- behavior: classical：表示文件内容是由完整规则类型组成的传统规则列表。规则文件格式必须与这里声明的行为相匹配。
- url：远程规则文件地址。GitHub 上的
blob页面链接不是原始文件链接，通常应使用raw.githubusercontent.com地址。 - path：规则下载到本地后的保存位置。使用相对路径时，它通常相对于配置文件所在位置解析；客户端的配置管理方式可能影响实际目录。
- interval：自动更新间隔，单位为秒。示例中的
86400表示约一天更新一次。 - format: yaml：说明规则提供者文件采用 YAML 格式。若目标内核版本不支持该字段，按对应版本文档调整。
更新间隔不是“每隔这么多秒一定成功下载一次”的保证，而是自动检查的周期设置。刚编辑完 GitHub 文件时，客户端未必立即拉取新内容；你可以通过客户端的规则提供者更新功能，或按客户端支持的方式重新加载配置。多个规则集可以使用不同的间隔，例如稳定规则每天更新，临时测试集则按需手动更新。
3将规则集接入分流规则
声明规则提供者之后，还要在主配置的 rules 列表中使用它。以下示例假设策略组名为 Proxy，并将自定义规则集中的匹配项交给该策略组处理：
RULE-SET 后面的名称必须与 rule-providers 下的键名完全一致。本例的 custom-services 是提供者名称，Proxy 则是已经定义好的策略组名称。如果把规则集名称拼错、策略组不存在，配置校验或运行时就可能报错。
规则顺序决定匹配结果
Clash 按照 rules 从上到下检查，命中一条后就使用对应策略，不会继续向下寻找。因此，顺序通常应遵循“具体规则在前，范围较大的规则在后”的原则。若同一个域名同时出现在自定义规则集和其他规则中，先出现的规则会优先生效。
- 需要优先处理的精确域名规则，放在通用后缀规则之前。
- 希望某些域名不受自定义集影响时，将对应的例外规则放在
RULE-SET之前。 MATCH通常作为兜底规则放在列表末尾，否则后面的规则将无法命中。- 如果规则集同时包含域名和 IP 项，应确认对应规则类型、DNS 解析方式以及目标内核行为符合预期。
建议分层维护
把个人例外规则放在前面，把通用规则集放在中间，再用 GeoIP 或 MATCH 等规则兜底。这样排查命中结果时更容易判断究竟是哪一层规则生效。
4用 Git 管理规则集版本
GitHub 托管的优势不只是提供下载地址，也让规则修改有据可查。建议在每次调整时只做小范围提交，并在提交说明中记录变更目的，例如新增了哪些域名、删除了哪些误匹配项。发现问题时，可以通过提交历史比较差异，必要时回退到上一个可用版本。
修改完成后，先在本地检查 YAML 结构，再推送到远程仓库。若你使用 Git 命令行，可以参考下面的基本流程：
当规则文件内容已经更新，但客户端仍表现为旧结果时，建议先检查远程 Raw 页面是否显示了最新内容，再手动触发规则集更新。若希望回滚某次改动，可在 GitHub 历史中查看文件版本，或用新的提交恢复正确内容。不要为了短期测试频繁改动默认分支上的稳定规则；可以先用单独分支验证，确认无误后再合并。
规则集托管在第三方平台意味着运行时依赖网络连通性。客户端可能保留本地缓存，但不应把缓存视为永久备份。保留本地副本和 Git 提交记录，能在仓库、网络或链接暂时不可用时更快恢复。对于重要配置，也应避免直接依赖来源不明、内容不可审计的规则文件。
5常见故障排查
遇到规则集不生效时，先区分问题发生在“远程文件获取”“文件解析”还是“规则匹配”阶段。逐层检查比反复改写配置更有效。
- 更新失败或连接超时：在浏览器中打开 Raw URL，确认地址可访问且返回的是规则文件文本；检查网络、DNS、仓库是否公开，以及分支和文件路径是否正确。
- 提示 YAML 解析错误：检查顶层是否有
payload，列表缩进是否一致，是否使用了全角标点或多余的制表符。也要确认远端返回的不是 GitHub 错误页面或 404 文本。 - 配置校验不通过：核对内核版本是否支持相关字段，并检查
behavior、format与文件内容是否一致。字段兼容性应以当前 Mihomo 版本文档为准。 - 规则下载成功但分流不符合预期：确认
RULE-SET名称与提供者键名一致，策略组确实存在，并检查它前面是否有更早命中的规则。 - 更新后仍使用旧规则：手动触发更新或重新加载配置，确认本地路径可写，并查看客户端日志中对应规则提供者的下载与解析状态。
- GitHub 内容已改但 Raw 结果未更新：确认改动已提交到 URL 指定的分支和路径；同时考虑网络缓存或客户端更新周期，之后再主动刷新。
排查时尽量一次只改一个变量，并保留一份已知可用的配置。若需要公开日志寻求帮助，请先删除订阅地址、节点信息、令牌和个人域名等敏感内容。
常见问题
rule-providers 能直接读取私有 GitHub 仓库吗？
不要默认认为标准 HTTP 提供者能自动完成 GitHub 身份验证。私有仓库需要认证，而把访问令牌直接写入客户端配置会带来泄露风险。更稳妥的做法是使用公开且不含敏感信息的规则文件，或采用符合当前内核能力、并经过安全评估的私有托管方案。
domain、ipcidr 和 classical 应该怎么选？
根据规则文件内容选择。只维护域名类型规则时可考虑 domain 行为；只维护 IP 网络规则时可考虑 ipcidr；需要保存完整规则类型或混合多种匹配方式时，使用 classical 通常更直观。请确保文件内容与声明的行为及当前内核支持范围相符。
更新间隔设置得越短越好吗？
不一定。间隔过短会增加不必要的请求，也可能让故障排查更复杂。稳定规则可以按天更新；变化不频繁的规则可以设置更长周期，临时规则则可按需手动刷新。关键是结合规则变更频率和托管服务的可用性设置合理周期。
所有 Clash 客户端都支持本文配置吗？
不一定。客户端只是管理界面，实际解析配置的是内核。Clash Verge、Clash Verge Rev 等客户端可能支持不同内核或版本；若遇到不识别字段、更新方式不同等情况，请查看客户端当前内核信息与对应文档，并先备份原配置。
通过 rule-providers 拆分规则后，主配置可以保持精简，规则文件也能独立审查、更新和回滚。实际部署时，优先从少量规则开始验证，再逐步扩展规则集，并定期检查 GitHub 文件地址、内核日志与规则优先级，能有效降低配置变更带来的意外影响。