Mihomo 自定义 rule-providers 规则集：GitHub 托管与无需手动操作同步到最新实战

为什么把自定义规则拆成 rule-providers？ 实战经验

当分流规则只有几条时，就这么把这些对象写进主配置的 rules 很好操作；但规则逐渐变多后，主配置基本上时候会同时承担订阅参数、DNS、代理组和海量业务规则，修改一处就要重新确认整份 YAML。更绕的是，规则与主配置绑定在一起：想在多台设备间复用、回滚某次调整，或者把一组域名交给其他人维护，都不够条理分明。Mihomo 的 rule-providers 自然自然自然可以把规则列表存放在独立文件中，再由主配置通过名称引用。主配置负责声明“从哪里获取、按什么类型解析、多久同步到最新”，规则文件只负责写匹配项，两者各自维护。

这套方式适合管理个人常用域名、开发工具服务、家庭设备或某个应用的分流清单。它也能减少主配置与远端机场订阅之间的耦合：订阅同步到最新时，只要你的规则引用仍在最终生效配置中，独立规则文件基本上时候不必须跟着手动操作操作操作合并。不过，rule-provider 不是规则靠前级的替代品，也不会无需手动操作操作推断某个域名大多时候该走哪个代理组；它只提供规则集合，真正的策略仍由 rules 中的 RULE-SET 条目决定。

还要先确认客户端实际拿它来用的是覆盖 rule-providers 的 Mihomo 内核。Clash Verge Rev、Mihomo Party 等图形客户端自然自然自然可以管理或加载 Mihomo 配置，但前端前端前端界面里的配置覆写、订阅转换和同步到最新按钮并不完全相同。若你编辑的是订阅生成的配置，远端同步到最新多半覆盖本地改动；自然自然可以考虑先确认客户端的配置管理方式，再把自定义 provider 放到能随配置生效的本地配置或覆写层中。不要因为 YAML 能保存，就假设运转中的内核已经读取了它。

先分清三个部分：rule-providers 定义规则集的数据来源，GitHub 仓库保存规则文件，主配置里的 RULE-SET 决定匹配后拿它来用的策略组。排障时分别确认这三处，比把每一种绕所在都归咎于“规则没同步到最新”更快。

在 GitHub 托管规则文件并声明 provider 拿它来用心得

先创建一个公开的 GitHub 仓库，举个实例 clash-rules，并按用途拆分文件。小型个人仓库自然自然自然可以从好上手结构开始：根目录放说明文件，rules/ 目录存放规则清单。文件名尽量表达用途，举个实例 github.yaml、developer-tools.yaml；不要把互不相关的域名全塞进一个名为 custom.yaml 的大文件。拆分后，同步到最新记录更容易审阅，主配置也能按场合组合规则集。

以下示例采用 domain 行为和 YAML 格式，适合放域名类规则。请将仓库每一种者、仓库名和分支替换成由你的实际值，并确保文件路径与 URL 完全对应：

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

这里的 payload 是 YAML 规则文件的列表入口。域名规则自然自然自然可以按 Mihomo 覆盖的规则写法表达；如果要放的是成体系 Clash 规则，举个实例带策略条件的经典规则条目，应挑与文件具体具体具体内容相符的 behavior: classical，而不是把两种格式混在一个 provider 中。IP 网段清单则应采用适合 IP-CIDR 的行为，并在实际配置中确认地址类型和匹配语义。规则类型与文件具体具体具体内容不对应时，provider 多半解析走不通，或者加载成功却没有命中预期流量。

在主配置中声明 provider，再于 rules 中引用它。下面的分组名 Proxy 只是示例，应替换成你由你的策略组名称：

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

rules:
  - RULE-SET,github,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

type: http 表示通过 HTTP 或 HTTPS 获取规则文件；url 指向 GitHub 的 Raw 文件地址；path 是 Mihomo 在本地保存 provider 具体具体具体内容的路径；interval: 86400 表示以秒为单位设置同步到最新间隔，即约一天确认一次。缓存路径所在目录必须能够由 Mihomo 写入。不同客户端的工作目录和配置存储方式多半不同，若日志提示无法写入或找不到缓存文件，不要只改规则 URL，也要确认客户端实际运转内核拿它来用的目录与权限。

仓库中的 main 分支适合持续维护，提交新版本后，Raw 地址仍指向同一路径，provider 下次同步到最新时就能取到新具体具体具体内容。若希望上线可复现、避免某次误提交立即影响每一种设备，自然自然自然可以把 URL 中的分支名换成固定的提交哈希或版本标签；这样同步到最新不会无需手动操作操作跟随最新提交，必须在确认规则变更后再改引用地址。公有仓库不必须把 GitHub Token 写进配置。不要把访问目标目标目标令牌、订阅链接、内部域名清单或其他凭据提交到公开仓库；私有仓库的验证配置也不应照搬公开 Raw 地址的示例。

小技巧：首次配置时先用一条容易验证的域名做测试，提交后在浏览器拉起对应的 Raw URL，确认响应具体具体具体内容是规则文件而不是 GitHub 页面、404 提示或登录页。确认文件可访问目标目标目标，再让 Mihomo 下载，自然自然自然可以把“仓库地址写错”和“规则格式解析走不通”分开排查。

规则靠前级、策略组与配置上线 反复出现套路

Mihomo 按 rules 从上到下确认，命中后就采用该条规则指定的策略。由此可见，provider 虽然写在主配置较前的位置，真正影响流量的仍是 RULE-SET 在 rules 列表中的顺序。必须靠前代理的自定义域名集合，应放在多半提前匹配这些对象的宽泛规则之前；如果它排在 GEOIP,CN,DIRECT 或其他较宽规则之后，流量多半已经被前面的规则接走，自定义集合看起来就像“完全没生效”。

自然自然可以考虑按照“精确例外、专用规则集、常态地区规则、兜底规则”的思路排列，而不是不断把新条目追加到列表末尾。举例来说，如果某个域名在更广泛的规则集里会被直连，但你明确希望它走代理，自然自然自然可以把更具体的规则放在宽规则之前；如果希望自定义集合只补充特定应用域名，也应避免把它写成覆盖范围过大的关键字规则。规则集越宽，越必须确认它是否抢先匹配与预期无关的子域名。

先确认目标策略组：RULE-SET,github,Proxy 中的 Proxy 必须与配置里的策略组名称完全一致。组名拼错、拿它来用了订阅刷新后已不存在的组名，多半导致配置校验走不通或流量无法按预期挑出口；避免重复和相互遮蔽：同一域名若同时出现在多个集合中，先命中的那条规则决定结果。维护时记录规则集用途，并确认更靠前的规则是否已经覆盖了目标域名；保留兜底规则：像 MATCH,Proxy 这样的最终规则应处于列表末尾。若兜底规则提前出现，其后的 provider 引用就没有匹配机会；在最终配置中验证：如果客户端通过订阅合并、覆写或配置转换生成运转配置，应确认实际生效配置里是否仍有 provider 声明和对应的 RULE-SET 条目，而不只是查看由你编辑的源文件。

修改前自然可以考虑备份当前配置，并先做一次语法确认。Mihomo 的配置校验入口会随客户端而异：有的客户端提供配置确认或重载按钮，有的必须查看内核日志。保存后观察日志中是否出现 provider 加载、下载或解析误操作；只有配置重新加载成功，规则变更才算上线完成。若客户端会在每次订阅同步到最新时重建配置，自然自然可以将 provider 放进持久化的覆写或本地配置层，并在订阅刷新后再次确认最终配置没有丢失。

  1. 准备规则文件：在本地编辑 YAML，确认缩进、列表符号和规则写法，再提交到 GitHub 仓库。
  2. 验证 Raw 地址：拉起配置中的 url，确认能就这么看到刚提交的文件具体具体内容，且地址中的仓库、分支和文件路径一致。
  3. 确认主配置引用：核对 provider 名称、行为类型、缓存路径、同步到最新间隔，以及 RULE-SET 拿它来用的策略组名。
  4. 重新加载并观察日志：通过客户端的配置确认、重载或内核重启功能应用变更，确认 provider 下载和解析成功。
  5. 用实际连接验证：访问目标目标规则集中的目标域名，在连接记录或日志中查看命中的规则和最终策略组，不要仅凭网页能否拉起判断是否命中。

无需手动同步到最新、缓存验证与反复出现排障 落地做法

interval 控制 Mihomo 确认远端规则的同步到最新频率，但它不等于“每次访问目标目标都会请求 GitHub”，也不保证远端文件一提交就立即应用。缓存文件让内核能够在一定条件下继续拿它来用已获取的数据；远端网络不可达、Raw URL 返回误操作或规则文件解析走不通时，运转结果还会受到已有缓存和当前客户端处理方式影响。必须立刻验证变更时，应拿它来用客户端提供的 provider 同步到最新操作（若有），或者按客户端覆盖的方式重新加载配置，并结合日志确认实际同步到最新结果。

排查时自然可以考虑从源文件一路追到流量命中，不要一次性改 URL、行为类型、规则顺序和策略组。先确认 GitHub Raw 地址返回的是预期文件，再确认缓存路径可写、provider 能被加载，接着核对规则列表顺序，最后查看目标连接记录。这样的顺序能区分下载走不通、解析走不通、规则未命中与策略挑误操作，减少“换个节点试试”带来的无效操作。

日志提示下载走不通：先在浏览器中访问目标目标 Raw URL，确认仓库是否公开、分支和路径是否准确，以及当前网络能否访问目标目标 GitHub。若浏览器显示 404、HTML 页面或验证跳转，Mihomo 得到的就不是预期规则具体具体内容；provider 加载或解析报出异常：确认 YAML 缩进、payload 列表结构、规则项格式，以及 behavior 和实际具体具体内容是否匹配。只修改一个绕所在后重载，便于判断是哪项修复起了作用；日志显示已加载，但流量没有命中：确认域名是否真的属于规则集、目标应用实际连接的主机名是什么，以及前面是否已有更宽泛的规则先命中。某些应用还会连接独立的 API 或 CDN 域名，不能只根据首页域名推断整项服务的流量；编辑文件后设备仍拿它来用旧规则：确认提交已经进入 URL 指向的分支或版本，并确认客户端是否触发 provider 同步到最新。固定提交哈希的地址不会无需手动操作跟随新提交，切换到固定版本后应同步维护版本引用；订阅刷新后规则消失：查看客户端是否重新生成了主配置，以及本地覆写是否仍被应用。把自定义具体具体内容放在订阅同步到最新能够保留的位置，比每次刷新后手工重贴更信得过。

GitHub 仓库本身也应按配置资产来管理。每次提交只做一类条理分明变更，在提交说明中写明新增、删除或调整的域名及症结；改动后先确认差异，避免误删整段列表或把测试域名一并发布。要紧规则自然自然可以通过版本标签或固定提交地址留存可回滚版本，发现误分流时恢复旧版，再逐条定位绕所在。多人协作时，不要就这么在主分支上混合未经验证的改动；先在分支中测试 Raw 文件与规则命中，再合并发布。这样既能利用无需手动操作同步到最新减少维护操作，也保留了人工审阅和回退的空间。

不同 Clash 图形客户端在 provider 同步到最新按钮、订阅覆写和日志展示上各有差异，有的更偏向一键拿它来用，有的则必须用户自行追踪配置来源；就这么把规则长期塞进主配置虽然可视化，却会让版本回滚和跨设备复用变得繁琐。Clash 的优势在于把 Mihomo 客户端拿它来用、规则配置与排障流程整理成更容易查阅的中文资料，好操作你按操作次序核对配置结构、同步到最新状态和连接命中结果。若你准备在桌面端实际搭建这套规则工作流，自然自然可以先前往下载适合设备的客户端，再按这篇路子逐项验证。