前言：把分流规则做成可维护的规则集
日常使用 Clash 时，规则往往散落在主配置的 rules 列表里。刚开始只有几条域名规则，看起来很直观；但随着 AI 服务、代码托管平台、包管理器和开发工具不断增加，主配置就可能变得冗长，更新一组域名还得手动编辑并检查整份文件。更麻烦的是，订阅更新可能覆盖本地修改，规则遗漏或顺序变化也不容易及时发现。
rule-providers 可以把一组规则单独保存为规则集，再由主配置通过 RULE-SET 引用。这样，规则内容与策略组、节点和其他主配置逻辑分开管理，既便于复用，也适合用 Git 记录每次变更。本文以 AI 服务与开发工具分流为例，介绍规则集文件格式、加载方式、匹配顺序和常见故障排查方法。
配置目标
将规则维护在独立 YAML 文件中，由主配置指定规则集行为类型，并把命中的流量送入已存在的策略组；更新规则时保留可审查、可回退的变更记录。
1理解 rule-providers 的加载与匹配机制
规则提供者本身只负责提供一组匹配条件，并不决定最终使用哪个节点。完整链路可以理解为：内核加载规则集文件，主配置中的 RULE-SET 规则引用该规则集，再把命中的连接交给指定策略组。例如，RULE-SET,AI-Services,AI-Proxy 表示匹配 AI-Services 规则集的流量交由 AI-Proxy 策略组处理。策略组需要在主配置的 proxy-groups 中提前定义；规则集不会自动创建策略组，也不会替用户选择节点。
规则提供者常见的 type 有 http 和 file。前者从 URL 下载规则文件，可配置更新间隔；后者读取本地文件，适合手动维护或与配置仓库一起部署。behavior 用来说明规则集内容如何解释，常见值包括 domain、ipcidr 和 classical。域名列表适合按域名后缀或关键词管理；IP 地址段使用 ipcidr；包含完整规则类型的传统规则列表则使用 classical。
规则提供者的匹配仍然遵循主配置 rules 的先后顺序。Clash 通常从上往下匹配，命中第一条适用规则后就确定处理方式。因此，不能只检查规则集是否写对，还要确认引用它的 RULE-SET 没有被更早的宽泛规则截走。末尾的 MATCH 一般作为兜底规则，应该放在需要精细分流的规则之后。
先确认内核兼容性
不同客户端可能搭载不同版本或分支的 Clash 内核。本文示例面向支持规则提供者及 YAML 格式的 Mihomo 配置；如果启动日志提示未知字段或解析失败，请先查看客户端当前使用的内核及其版本，再核对对应配置文档。
2编写 YAML 规则集并在主配置中引用
建议先把规则集内容放在独立文件中，再在主配置声明提供者。下面示例使用本地文件，规则对象按域名匹配。文件路径相对于内核的工作目录解析；不同客户端、配置存储方式和启动方式可能使用不同工作目录，因此应确认文件实际放在内核能够读取的位置。
第一步：创建域名规则文件
例如新建 ruleset/ai-services.yaml。使用 domain 行为时，文件采用带有 payload 的 YAML 结构，列表中填写域名或域名后缀，不要添加策略组名称，也不要在列表项前写完整的 DOMAIN-SUFFIX 规则类型。
这里的条目只是演示格式，实际维护时应根据所需服务添加或删减域名。开发工具可能依赖多个域名提供登录、更新、API 和静态资源，不要只凭首页域名就推断所有请求都已覆盖。与此同时，规则范围也不宜无限扩大：为了让某个 AI 服务走代理而把所有常见云服务域名一并加入，可能会使原本应该直连的业务流量也被导入代理。
第二步：在主配置声明规则提供者
在主配置的顶层加入 rule-providers，并确保缩进与其他顶层配置一致。format: yaml 表明规则文件采用 YAML 格式，interval 对本地文件没有定时下载作用，通常只为远程 HTTP 提供者配置。
如果改用远程文件，可以将 type 设为 http，并配置 url、path 和更新间隔。URL 应指向可直接访问的规则文件，而不是代码仓库的网页预览页；path 则是内核保存下载副本的位置。远程源不可用、返回网页错误内容或更新路径无写入权限，都可能导致规则集无法载入。不要把需要登录才能访问的私有仓库链接直接当成公开下载地址。
第三步：设置策略组并引用规则集
下面的策略组名称只是配置示例，请替换为你自己的有效名称。将对应策略组写入主配置的 proxy-groups，然后在 rules 中引用规则集。规则集名称必须与 rule-providers 下的键名完全一致。
实际配置中，节点选择也必须是已存在的策略组或节点名称，否则内核可能报告策略目标无效。若主配置前面已经有覆盖范围很大的域名规则、IP 规则或其他规则集，需评估它们是否会先于 AI-Services 命中。调整时尽量只改变需要的顺序，并在修改后逐项验证，而不是盲目把所有规则都移到最前面。
3用 Git 管理变更并验证规则效果
把规则文件纳入 Git 仓库，可以清楚回答“哪条规则何时加入、为什么修改、改动后出现了什么影响”。推荐将规则集、配置说明和变更记录放在同一个私有或受控仓库中；提交前检查内容里是否包含订阅链接、访问令牌、私人域名等敏感信息。Git 负责记录文件变化，并不会自动让 Clash 加载新规则，修改后仍需通过客户端重新载入配置，或按当前客户端支持的方式更新规则提供者。
在规则文件所在的配置仓库中，可以使用以下基本流程记录变更：
每次提交尽量围绕一个目的，例如“补充代码托管域名”或“移除已停用域名”，避免把大量无关改动塞进同一提交。若更新后出现异常，可先用 git diff 找到最近变更，再通过版本控制恢复规则文件，并重新验证配置。
按顺序验证配置是否生效
- 检查 YAML 结构： 确认冒号后有空格、同一层级缩进一致，列表项以连字符和空格开头。不要使用 Tab 缩进，也不要把多个顶层字段意外缩进到同一个字段里。
- 检查名称引用： 对照核实
rule-providers的键名、RULE-SET中的规则集名称、策略组名称和节点名称；它们应与定义完全对应。 - 查看内核日志： 重新载入后检查配置解析错误、文件路径错误、远程下载失败和规则集更新失败等信息。若日志提示文件不存在，应先排查工作目录和实际文件路径。
- 用连接记录确认命中： 访问目标服务后查看客户端连接列表或日志，确认请求使用了预期的规则集和策略组。浏览器缓存、应用已有长连接或规则未覆盖的关联域名，都可能让单次测试结果产生误判。
- 逐项回归： 分别测试目标 AI 服务、代码托管平台，以及本应直连的常用网站。确认新增规则达到分流目标，同时没有把不相关流量一并送入代理。
避免把“已加载”误认为“已命中”
规则集下载成功或配置通过语法检查，只能说明文件可以被读取，不能证明目标连接实际匹配该规则。最终应结合连接日志中的规则类型、规则集名称和策略组判断，并检查是否存在更早命中的规则。
4常见问题排查与配置优化
自定义规则集的故障通常集中在格式、路径、规则顺序和策略组引用这几个方面。建议一次只检查一个环节：先确保文件可解析，再确认提供者已加载，最后验证连接是否命中并走向正确策略。这样比同时改动多个字段更容易定位原因。
- 启动时报 YAML 解析错误： 检查
rule-providers是否位于顶层，键值之间是否有冒号，缩进是否统一。规则文件应符合所声明的behavior和format；如果文件是纯文本规则列表，却按带payload的 YAML 加载，就需要统一文件格式与提供者声明。 - 提示规则文件不存在： 核对
path相对于哪个工作目录解析，并确认客户端实际加载的是你刚刚编辑的配置，而不是另一份订阅配置或临时生成配置。对于远程提供者，还要检查下载副本目录是否可写。 - 规则加载正常但连接未命中： 先看请求的实际域名是否在规则集覆盖范围内，再检查更靠前的规则是否已经匹配。某些服务会将网页、API、登录和静态资源放在不同域名下，单条主域名规则未必足够覆盖完整功能。
- 命中规则却没有按预期代理： 检查
RULE-SET第三个参数是否指向正确策略组，以及该策略组中是否包含可用节点。若策略组名称拼写不同，或节点已失效，规则匹配成功也不能保证连接正常。 - 远程规则更新失败： 检查 URL 是否能直接返回规则文件、网络是否可达、更新间隔设置是否合理，并查看日志中的 HTTP 状态或文件写入错误。远程更新失败时，不要默认本地缓存一定是最新版本；需要确认当前实际使用的规则文件内容。
日常维护可以采用“小步提交、先验证再启用”的流程：编辑规则文件，检查差异，重新载入配置，查看日志和连接记录，再进行回归测试。规则集名称尽量保持稳定，避免没有必要地改名；如果确实需要重命名，记得同步修改主配置中的所有引用。对关键分流规则保留简短说明，注明添加原因、适用服务和核验日期，能显著降低后续维护成本。
常见问题 FAQ
修改规则文件后需要重启 Clash 吗？
不一定。规则是否能动态更新取决于内核和客户端提供的加载方式。远程 HTTP 规则集通常可按配置的间隔更新，但本地文件变更后，客户端可能需要更新提供者或重新载入配置。不要仅凭界面仍显示已启用就判断新内容已经生效，应查看日志并用连接记录验证。
domain 和 classical 应该如何选择？
如果维护内容主要是域名、域名后缀或关键词匹配，优先选择 domain，并按对应格式编写规则文件。如果需要把多种完整规则类型放在同一规则集，例如域名规则与 IP 规则混合，则根据内核支持情况使用 classical，并在文件中写入完整规则项。行为类型与文件内容不匹配时，可能报错或无法按预期解析。
为什么有了 rule-providers 还要写 RULE-SET？
rule-providers 负责定义规则集从哪里来、如何读取及如何更新；RULE-SET 则负责在主规则链中引用它，并指定命中后交给哪个策略组。两者分工不同，缺少引用规则时，提供者即使成功加载，也不会自动参与流量分流。
把规则写进订阅配置安全吗？
如果客户端会定期覆盖订阅配置，直接编辑订阅文件容易导致改动丢失。更稳妥的做法是使用客户端支持的配置合并功能或独立本地配置管理自定义规则，并先确认合并结果中的规则顺序和提供者定义。无论采用哪种方式，都不要公开包含个人订阅凭据或私有访问令牌的配置文件。