rule-providers 是什么：把规则内容与主配置分开维护

当 rules 越写越长，主配置会逐渐变成一份难以审阅的域名清单：应用新增了接口域名，要改本地 YAML；规则更新后，还得重新导入或同步到每台设备。rule-providers（规则提供者）解决的是规则内容的维护问题：主配置声明规则集从哪里获取、按什么格式解析、保存到哪个本地路径以及多久检查一次更新；具体匹配条目则放在独立文件中。核心加载规则集后，再由 rules 里的 RULE-SET 规则将命中的流量交给策略组。

需要区分的是，规则集本身不负责选择代理节点。它描述「哪些连接属于这一组」，而 RULE-SET,名称,策略组 的最后一个字段才决定命中后交给哪个策略组。例如，规则集识别出某个开发工具的域名后，流量可以交给你已有的 PROXY、自动测速组或专用的 AI 策略组。若规则集名称写错、策略组不存在，或规则被更早的规则截获，即使 provider 文件已经下载，结果也可能与预期不同。

规则提供者在不同 Clash 内核与客户端中的支持并不完全相同。本文示例以支持 rule-providers 的 Mihomo 内核为基准；部分较旧的 Clash 核心可能不认识 behavior、format 或新的文件格式字段。Clash Verge、Clash Verge Rev、Mihomo 等客户端通常还会在界面外管理配置文件，实际生效的 YAML 可能是订阅转换后的文件，而不是你手动打开的副本。因此，开始编辑前先确认当前配置使用的内核、活动配置文件路径，以及客户端是否会在更新订阅时覆盖本地修改。

ℹ 先记住这条链路：GitHub 提供规则文件，rule-providers 下载并解析文件，rules 中的 RULE-SET 决定匹配时使用哪个策略组。三处分别负责托管、加载和分流，排障时不要混为一谈。

用 GitHub 托管规则集：仓库结构、格式与版本控制

可以把规则文件放在公开 GitHub 仓库中，例如将主配置放在机场订阅或本机配置目录，把自维护的规则清单放到仓库的 rules 子目录。provider 的 url 必须指向可直接读取文件内容的地址，而不是 GitHub 仓库网页地址。仓库页面通常包含导航、提交记录和按钮等 HTML 内容，内核把它当作规则文件解析时会失败；应使用 raw.githubusercontent.com 提供的原始文件 URL，并在浏览器中打开该链接确认页面显示的是 YAML 或文本内容。

GitHub 分支上的文件适合日常维护：修改后提交，规则提供者下次更新时即可取到新内容。但分支内容会随提交变化，若一次错误提交把规则格式破坏，所有使用该 URL 的配置都可能在下一次更新时受到影响。对需要稳定复现的环境，可以把 URL 固定到经过审核的提交版本，或通过发布流程更新版本指向；日常维护仍保留清晰的提交记录。无论采用哪种方式，都要确保仓库公开可访问，且链接没有拼错所有者、仓库名、分支名或文件路径。

在编写规则前，先决定规则集的 behavior。domain 适合只维护域名后缀或域名条目的清单；ipcidr 用于 IP 地址段；classical 则可保存包含规则类型和参数的传统规则条目，例如域名后缀、完整域名或进程名规则。行为类型决定内核如何解释文件内容，不能只根据文件扩展名猜测。若规则源需要同时表达多种匹配条件，使用 classical 通常更直观；若仅维护一组纯域名，则采用更专用的行为有利于理解和检查。

对 YAML 规则文件，常见结构是以 payload 作为规则列表的入口，列表中每项写一条符合对应行为类型的规则。比如 classical 清单可包含 DOMAIN-SUFFIX 和 DOMAIN 等规则；纯域名行为则应按该行为支持的条目格式编写。文件内容必须与 provider 声明的 behavior、format 相互匹配。把完整主配置中的 rules: 块误当成 provider 文件，或把带规则类型前缀的条目放进只期待域名的清单，都会导致解析报错或规则无法按设想命中。

可改用的 YAML 示例：声明 provider 并接入规则顺序

下面的示例展示一个托管在 GitHub 的自定义经典规则集。请替换所有者、仓库、分支和文件路径，并确认 MY_AI 对应的策略组已经存在。示例中的本地 path 是内核缓存规则文件的位置；不同客户端的工作目录不同，建议使用稳定且可写的相对路径，并确认应用不会在配置重载时清理该目录。

Mihomo rule-provider YAML example

rule-providers:
  MY_AI:
    type: http
    behavior: classical
    format: yaml
    url: "https://raw.githubusercontent.com/OWNER/REPO/main/rules/my-ai.yaml"
    path: ./rule-providers/my-ai.yaml
    interval: 86400

rules:
  - RULE-SET,MY_AI,MY_AI
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

对应的规则文件可以按如下方式编写；域名只是示例，应以你实际连接日志中看到的主机名为依据，不要把猜测出的域名当成权威清单。

GitHub hosted rule file

payload:
  - DOMAIN-SUFFIX,example.dev
  - DOMAIN,api.example.dev

示例里的 interval: 86400 表示按秒计算的检查间隔，即大约每天检查一次。频率不必越高越好：规则仓库短时间内没有变化时，过于频繁地请求只会增加无用访问；若规则每日会变更，可以按维护节奏缩短间隔。首次加载时，内核需要能够访问原始文件地址；之后本地缓存可帮助配置在短时网络波动时继续使用已保存的规则，但缓存不能代替有效的远程 URL，也不能保证每次失败更新都能自动修复。

rules 的先后顺序尤其重要：通常按从上到下依次匹配，先命中的规则决定后续处理。若在 RULE-SET,MY_AI,MY_AI 之前已有更宽泛的域名规则或通用规则，流量可能先被前一条接走，根本不会到达自定义规则集。通常应将需要优先处理的特定规则放在较宽泛的规则之前，并把兜底用的 MATCH 放在末尾。增加 provider 后，不能只看它在配置文件中存在，还要检查这条 RULE-SET 在实际规则序列中的位置。

如果希望规则文件更新可追溯，建议在提交说明中记录新增、删除和修改的条目，并尽量一次提交一类变更。发布前先用当前使用的内核加载配置，确认没有 YAML 缩进错误、重复规则或无效规则类型，再观察连接日志中的匹配结果。多人维护时，可先在测试配置中验证，再将经过检查的提交用于日常配置；这样出现误分流时可以比较最近的提交，而不必在一份不断变化的长文件中盲目寻找差异。

更新参数、匹配验证与常见故障定位

配置保存后，先在客户端确认实际运行的核心已成功重载。部分界面会把配置编辑、配置保存与核心重启分成不同操作，保存文件不一定意味着内存中的规则已经刷新。更新 provider 后，可观察内核日志或客户端的配置提示，确认远程文件请求成功、规则集解析完成；再打开连接记录，访问一个确实应当命中清单的域名，核对请求的主机名、匹配规则名称和最终出站策略。仅凭网页能够打开，无法判断它是通过规则集命中、其他规则接管，还是因为当前节点本身能够访问。

path 也值得单独检查：配置目录变更、客户端迁移或权限收紧后，原有缓存路径可能不存在或不可写。日志若显示创建文件失败，应先确认目录由当前运行用户访问，再决定是否调整路径；不要把缓存路径与 GitHub URL 混为一谈。前者是本地文件位置，后者是远程下载来源。若同一配置在两台设备表现不同，还应比较实际加载的配置文件、核心版本、缓存状态和客户端是否执行了订阅覆写，而不是假定两边正在运行完全相同的 YAML。

长期维护时，把规则集拆分成职责明确的小文件通常比维护一个巨大列表更可靠，例如将开发服务、媒体域名和本地例外分开；命名要能说明用途，避免多个 provider 使用相似名称而难以从日志辨认。规则集也不宜追求「收录越多越好」：宽泛的关键字或过大的 IP 段容易把无关业务一并导入，反而让分流结果难以预测。每增加一条规则，都应能说明它匹配什么请求、为什么使用该策略组，以及如何在日志中验证。

与把所有域名直接堆进主配置相比，GitHub 托管的 rule-providers 更便于审阅变更、复用清单和回滚版本；但它也增加了远程访问、文件格式与本地缓存等需要管理的环节。某些图形客户端的规则编辑入口看起来更简单，却未必能清楚呈现订阅更新后的覆盖关系；手工维护长 YAML 虽然直观，却容易在多设备间产生版本分叉。若你希望同时管理规则、策略组与运行日志，可以使用 Clash V.CORE 的兼容客户端工作流来减少来回核对；开始配置前先备份当前文件，再前往下载并按本文示例验证自己的 GitHub 规则集。最后以连接日志中真实显示的命中规则和出站策略为准，而不要只凭配置文本推断流量已经按预期分流。