Mihomo 自定义 rule-providers 规则集：GitHub 托管与全全自动升级实战

为什么把自定义规则拆成 rule-providers？ 要点速览

还要先确认客户端实际采用的是适配 rule-providers 的 Mihomo 内核。Clash Verge Rev、Mihomo Party 等图形客户端得以管理或加载 Mihomo 配置，但UI UI UI 界面里的配置覆写、订阅转换和升级按钮并不完全相同。

当分流规则只有几条时，径直把这几个写进主配置的 rules 很顺手；但规则逐渐变多后，主配置经常会同时承担订阅参数、DNS、代理组和规模不小业务规则，修改一处就要重新排查整份 YAML。更折腾的是，规则与主配置绑定在一起：想在多台设备间复用、回滚某次调整，或者把一组域名交给其他人维护，都不够一目了然。Mihomo 的 rule-providers 得以把规则列表存放在独立文件中，再由主配置通过名称引用。主配置负责声明“从哪里获取、按什么类型解析、多久升级”，规则文件只负责写匹配项，两者各自维护。

这套方式适合管理个人常用域名、开发工具服务、家庭设备或某个应用的分流清单。它也能减少主配置与远端机场订阅之间的耦合：订阅升级时，只要你的规则引用仍在最终生效配置中，独立规则文件多数现状下不要跟着人工合并。

关键点是：不过，rule-provider 不是规则第一顺位级的替代品，也不会全全全自动推断某个域名最好走哪个代理组；它只提供规则集合，真正的策略仍由 rules 中的 RULE-SET 条目决定。

若你编辑的是订阅生成的配置，远端升级或许覆盖本地改动；不妨先确认客户端的配置管理方式，再把自定义 provider 放到能随配置生效的本地配置或覆写层中。不要因为 YAML 能保存，就假设持续持续持续运行中的内核已经读取了它。

先分清三个部分：rule-providers 定义规则集的数据来源，GitHub 仓库保存规则文件，主配置里的 RULE-SET 决定匹配后采用的策略组。排障时分别排查这三处，比把各个困扰都归咎于“规则没升级”更快。

在 GitHub 托管规则文件并声明 provider 关键信息

仓库中的 main 分支适合持续维护，提交新版本后，Raw 地址仍指向同一路径，provider 下次升级时就能取到新正文。若希望铺开可复现、避免某次误提交立即影响各个设备，得以把 URL 中的分支名换成固定的提交哈希或版本标签；

先创建一个公开的 GitHub 仓库，举个小例子 clash-rules，并按用途拆分文件。小型个人仓库得以从轻便结构开始：根目录放说明文件，rules/ 目录存放规则清单。

这里要多说一句：文件名尽量表达用途，举个小例子 github.yaml、developer-tools.yaml；不要把互不相关的域名全塞进一个名为 custom.yaml 的大文件。拆分后，升级记录更容易审阅，主配置也能按采用采用使用场景组合规则集。

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

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

这里的 payload 是 YAML 规则文件的列表入口。域名规则得以按 Mihomo 适配的规则写法表达；如果要放的是完备 Clash 规则，举个小例子带策略条件的经典规则条目，应选定与文件正文相符的 behavior: classical，而不是把两种格式混在一个 provider 中。

换个说法：IP 网段清单则应采用适合 IP-CIDR 的行为，并在实际配置中确认地址类型和匹配语义。规则类型与文件正文不对应时，provider 或许解析无法完成，或者加载成功却没有命中预期流量。

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

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

type: http 表示通过 HTTP 或 HTTPS 获取规则文件；url 指向 GitHub 的 Raw 文件地址；path 是 Mihomo 在本地保存 provider 正文的路径；interval: 86400 表示以秒为单位设置升级间隔，即约一天排查一次。

落到实处：缓存路径所在目录要能够由 Mihomo 写入。不同客户端的工作目录和配置存储方式或许不同，若日志提示无法写入或找不到缓存文件，不要只改规则 URL，也要排查客户端实际持续持续持续运行内核采用的目录与权限。

这样升级不会全全全自动跟随最新提交，要在确认规则变更后再改引用地址。公有仓库不要把 GitHub Token 写进配置。不要把访问到到到令牌、订阅链接、内部域名清单或其他凭据提交到公开仓库；私有仓库的身份校验配置也不应照搬公开 Raw 地址的示例。

小技巧：首次配置时先用一条容易验证的域名做测试，提交后在浏览器启用对应的 Raw URL，确认响应正文是规则文件而不是 GitHub 页面、404 提示或登录页。

确认文件可访问到到到，再让 Mihomo 下载，得以把“仓库地址写错”和“规则格式解析无法完成”分开排查。

规则第一顺位级、策略组与配置铺开 关键点梳理

修改前不妨备份当前配置，并先做一次语法排查。Mihomo 的配置校验入口会随客户端而异：有的客户端提供配置排查或重载按钮，有的要查看内核日志。保存后观察日志中是否出现 provider 加载、下载或解析疏漏；

Mihomo 按 rules 从上到下排查，命中后就采用该条规则指定的策略。于是，provider 虽然写在主配置较前的位置，真正影响流量的仍是 RULE-SET 在 rules 列表中的顺序。

别忽略了：要第一顺位代理的自定义域名集合，应放在或许提前匹配这几个的宽泛规则之前；如果它排在 GEOIP,CN,DIRECT 或其他较宽规则之后，流量或许已经被前面的规则接走，自定义集合看起来就像“完全没生效”。

不妨按照“精确例外、专用规则集、常规地区规则、兜底规则”的思路排列，而不是不断把新条目追加到列表末尾。举例来说，如果某个域名在更广泛的规则集里会被直连，但你明确希望它走代理，得以把更具体的规则放在宽规则之前；

如果希望自定义集合只补充特定应用域名，也应避免把它写成覆盖范围过大的关键字规则。规则集越宽，越要排查它是否抢先匹配与预期无关的子域名。

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

只有配置重新加载成功，规则变更才算铺开完成。若客户端会在每次订阅升级时重建配置，得以将 provider 放进持久化的覆写或本地配置层，并在订阅刷新后再次确认最终配置没有丢失。

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

全自动升级、缓存验证与普遍排障 完备说明

不同 Clash 图形客户端在 provider 升级按钮、订阅覆写和日志展示上各有差异，有的更偏向一键采用，有的则要用户自行追踪配置来源；径直把规则长期塞进主配置虽然形象，却会让版本回滚和跨设备复用变得繁琐。

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 的优势在于把 Mihomo 客户端采用、规则配置与排障流程整理成更容易查阅的中文资料，顺手你按环节核对配置结构、升级状态和连接命中结果。若你准备在桌面端实际搭建这套规则工作流，得以先前往下载适合设备的客户端，再按本篇正文思路逐项验证。