前言：把分流规则做成可维护的规则集
当 Clash 配置中的规则越来越多，直接把每条域名规则都堆进主配置，会让文件变得难以阅读和维护。想在多台设备之间复用规则，或者只更新某一类应用的分流策略，也容易牵一发而动全身。Mihomo 提供的 rule-providers 可以把规则列表独立存放，再由主配置按需引用；规则文件托管在 GitHub 后，更新规则时通常只需修改远程文件，无须反复手工复制整份配置。
本文以 Mihomo 为例，介绍如何准备规则文件、发布到 GitHub、在配置中声明 Provider、将规则指向策略组，并确认更新确实生效。需要注意，rule-providers 是内核配置能力，并非每个名为 Clash 的客户端都使用 Mihomo。开始前先在客户端确认当前内核为 Mihomo，并备份原配置；如果客户端通过订阅生成配置，还要确认它允许使用覆写、Merge 或自定义配置功能。
本文目标
将自定义规则与主配置分离，利用 GitHub 保存可访问的规则文件，再通过 RULE-SET 绑定策略组，并用日志、连接记录和远程文件更新结果验证整条链路。
1认识 rule-providers 与规则文件格式
rule-providers 用来声明一组可独立加载的规则。每个 Provider 都需要名称、获取方式、规则行为类型、远程地址、本地缓存路径和更新间隔；主规则列表则通过 RULE-SET 引用它。它解决的是规则的组织与更新问题，不会自动创建代理节点或策略组，也不会自动判断某条规则应该走代理还是直连。
先选择规则行为，再决定文件内容。常见的 domain 行为用于域名条目，文件中放域名模式；ipcidr 用于 IP 网段；classical 则适合保留完整的 Clash 规则类型，例如 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD。以下示例采用 classical，文件以 YAML 列表保存完整规则：
将此文件保存为 custom-sites.yaml。请勿在列表中加入策略组名称，策略由主配置中的 RULE-SET 行指定；也不要把说明文字写成未注释的条目。YAML 对缩进敏感，使用空格而不是 Tab，并保证 payload: 下的列表缩进一致。若规则文件本身无法通过 Mihomo 校验，即使 GitHub URL 可访问，Provider 也可能加载失败。
在主配置中声明 Provider
在主配置中添加 Provider 定义，并把地址替换为你自己的 GitHub 仓库、分支和文件路径：
type: http 表示通过 HTTP 获取远程文件；behavior 必须与规则内容相匹配；format: yaml 指定文件格式；path 是 Mihomo 保存缓存的位置；interval: 86400 表示以秒计的更新间隔，即大约一天。不同 Mihomo 版本及客户端对字段支持可能存在差异，遇到校验错误时应以当前内核版本文档和启动日志为准。路径建议使用独立目录，避免与客户端管理的订阅文件重名。
2将规则托管到 GitHub 并接入策略组
创建一个公开 GitHub 仓库，在仓库中建立 rules 目录并上传 custom-sites.yaml。公开仓库的文件可通过 GitHub Raw 地址读取；配置里的 URL 应指向具体文件，而不是仓库首页、文件预览页或下载按钮页面。仓库分支和文件路径必须与 URL 中的内容一致，文件改名或移动后也要同步修改 Provider 地址。
将以下字段替换为实际值后，可在浏览器中打开 Raw URL 检查：页面应返回规则文件内容，而不是 GitHub 登录页、HTML 页面或 404。还要留意仓库的可见性与访问限制：私有仓库通常无法由 Mihomo 直接匿名读取，带有个人令牌的 URL 也不适合写入公开配置，因为订阅或配置文件可能被他人看到。
Provider 声明完成后，在主配置的 rules 中引用其名称。名称必须与 rule-providers 下的键完全一致：
此处的 Custom 是示例策略组名，需替换成配置中真实存在的策略组；如果配置没有名为 Proxy 的组，也要相应调整示例。规则按顺序匹配，因此自定义规则应放在可能提前命中的宽泛规则之前，且 MATCH 通常放在列表末尾。若前面已有覆盖相同域名的规则，Provider 虽然加载成功，流量仍可能先被前置规则处理。
维护建议
将不同用途的列表拆分为独立文件，例如广告拦截、工作服务或个人测试域名；命名保持稳定，并在仓库提交说明中记录规则变更原因。这样出现误分流时，可以快速定位到对应 Provider，而不必在一份超长配置中逐行排查。
3验证自动更新并排查常见故障
写好配置后，先通过客户端的配置检查或内核校验功能确认 YAML 语法正确，再应用配置并查看 Mihomo 日志。不同客户端菜单名称可能不同，重点是找到配置校验、内核日志、规则提供者或 Provider 更新状态相关页面。确认日志中没有配置解析错误、HTTP 请求失败或规则格式异常后，再用连接记录检查目标域名是否命中了预期策略。
分层验证：从 URL 到流量命中
- 检查远程文件：在浏览器中打开 Raw URL，确认返回的是最新 YAML 内容，文件名、分支和目录均正确。
- 检查 Provider 状态：在客户端重新加载配置或触发规则集更新，并查看日志是否报告获取成功。首次加载与周期更新可能受网络、缓存及客户端实现影响，不要只凭等待几秒判断更新失败。
- 检查规则命中：访问规则文件中明确列出的域名，在连接记录中查看命中的规则类型、Provider 名称和最终策略组。若连接匹配了更靠前的规则，应调整规则顺序，而不是盲目重复添加条目。
- 验证远程更新：在 GitHub 上加入一条容易辨认的测试规则并提交，确认 Raw 内容已变化；再等待更新间隔或手动更新 Provider，检查客户端中的规则与命中结果。验证完成后移除测试规则，避免影响实际流量。
常见问题与处理思路
- Provider 获取失败：先检查 URL 是否能直接访问、仓库是否公开，以及网络是否能连接 GitHub。若客户端所在网络无法访问 GitHub，可考虑使用自己管理且可信的镜像或托管服务；不要随意把规则转交给来源不明的第三方。
- HTTP 404 或加载旧内容：核对分支名、文件路径和文件名，确认提交已经完成。浏览器缓存或 CDN 缓存可能造成短暂延迟，可在稍后重新请求并查看内核的实际更新结果。
- 配置校验不通过：检查字段缩进、冒号、列表格式与
format设置；确认behavior与文件中的规则类型一致。若版本不支持某字段，应按当前内核文档调整，而不是直接删除所有报错字段后忽略结果。 - 规则加载了但没有按预期分流：检查
RULE-SET名称、策略组名称和规则顺序；确认该域名实际触发了对应规则。规则集只匹配配置中定义的对象，不会自动覆盖未列入文件的其他域名或 IP。 - 客户端更新后配置消失：有些客户端会在刷新订阅时重建主配置。请使用客户端支持的覆写、Merge 或独立配置机制，并在更新订阅后重新检查 Provider 定义和规则引用是否仍然存在。
安全提醒
远程规则会影响流量去向。只使用自己维护或充分审查的规则来源，变更前先查看 GitHub 提交差异；不要将订阅链接、访问令牌或其他凭据提交到公开仓库。更新间隔也不宜设置得过短，以免造成不必要的请求或触发托管平台限制。
4建立可复用的规则维护流程
把规则搬到 GitHub 并不意味着以后可以完全不检查。实用的维护方式是让每个规则文件只承担一个清晰用途，保留简短的 README 说明规则覆盖范围、维护者和更新时间；修改前通过 GitHub 差异检查新增、删除和调整的条目，提交后再从客户端验证实际命中。若多个设备需要共享规则，可让它们引用同一个稳定 URL，并保持 Provider 名称与策略组设计一致。
对重要配置，建议保留本地备份或使用 Git 标签记录已验证版本。规则出现问题时，可以回退到上一次可用提交，再检查是否由域名变更、匹配范围过宽、规则顺序或网络缓存造成。对不确定的条目，先在单独 Provider 或测试策略组中验证，不要直接把宽泛规则插入生产配置最前面。
通过 rule-providers 管理规则集后，主配置负责声明来源和更新策略，GitHub 仓库负责保存规则内容，RULE-SET 则将规则连接到实际策略组。把这三部分分别校验，并形成“提交—更新—命中检查”的小闭环，自定义分流就能从一次性的手工配置变成更易复用、回滚和协作维护的工程化配置。