前言：为什么要使用自定义 rule-providers？
当你的 Clash 配置只包含少量规则时，直接把规则写在 rules 列表中十分方便。但随着使用场景增加，AI 服务、代码托管平台、容器镜像仓库、包管理器以及公司内部工具往往需要不同的代理策略。如果所有内容都堆在主配置文件里，配置会越来越长，排查顺序也会变得困难，订阅更新时还可能覆盖自己的修改。
rule-providers 可以把规则拆分成独立的 YAML 文件，再通过主配置中的提供者声明统一引用。你可以为 AI 服务建立一组规则，为开发工具建立另一组规则，还可以把个人维护的规则放在 Git 仓库中，通过 URL 定期更新。这样做的优势不只是“文件更整齐”，更重要的是能够明确控制规则边界、复用相同模块，并在出现问题时快速定位。
本文目标
从规则匹配顺序和 YAML 结构出发，搭建 AI 与开发工具的自定义 rule-providers，接入 Git 版本管理，并掌握规则未命中、域名走错策略组等常见问题的排查方法。
本文示例以支持 Mihomo 的客户端为主，包括 Clash Verge、Clash Verge Rev 以及其他兼容 Mihomo 配置格式的客户端。不同版本的界面名称可能略有差异，但配置文件中的核心字段基本一致。开始前建议先备份当前配置，尤其是订阅配置不要直接覆盖原文件。
1理解匹配原理：规则不是越多越好
Clash 在规则模式下会按照 rules 列表从上到下进行匹配。一个请求一旦命中某条规则，Clash 就会把它交给该规则末尾指定的策略组，不会继续向下寻找“更合适”的规则。因此，规则顺序比规则数量更加重要。
规则顺序与策略组
例如，下面的配置希望让 ChatGPT 走 AI 策略组，让国内地址直连：
这里的 RULE-SET 是引用 rule-provider 的规则类型，ai-services 与 dev-tools 是提供者名称，最后的 AI 和 Developer 是策略组名称。策略组必须已经在 proxy-groups 中定义，否则配置可能无法启动，或者请求无法按照预期转发。
通常建议把自定义的 AI 和开发工具规则放在通用规则之前，把 GEOIP,CN,DIRECT 放在后面，把 MATCH,PROXY 作为最后的兜底规则。若把 MATCH,PROXY 提前，后续所有规则都会失效；若把国内直连规则放在 AI 规则前面，某些使用国内 CDN 或共享域名的服务也可能被提前判定为直连。
选择正确的规则格式
rule-provider 常见的行为类型有 domain、classical 和 ipcidr。domain 文件通常只保存域名或域名后缀，适合维护站点域名；classical 文件保存完整的 Clash 规则，例如 DOMAIN-SUFFIX、DOMAIN-KEYWORD 或 IP-CIDR；ipcidr 则专门用于 IP 网段。
- domain：文件内容简洁，适合按域名后缀匹配，维护 AI 网站和开发平台时最容易阅读。
- classical：表达能力最完整，可以把不同类型的规则放在同一个文件中，但每一行都要带规则类型和参数。
- ipcidr：适合明确的地址段，不能用来替代域名规则；很多云服务 IP 会变化，不建议只依赖静态网段。
实用建议
优先使用 DOMAIN-SUFFIX 覆盖一个服务的主域名，再为确实需要的 API、登录和静态资源补充独立域名。不要大量使用宽泛的 DOMAIN-KEYWORD，否则容易把无关网站一并送入代理。
2编写 YAML：拆分 AI 与开发工具规则
一个完整的 rule-provider 声明通常包含四个核心字段：type 表示来源类型，behavior 表示规则文件格式，url 指向远程文件，path 表示下载后在本地保存的位置。interval 用于指定自动更新间隔，单位是秒。
AI 服务规则提供者
下面是一个适合个人维护的 AI 规则示例。这里采用 classical 格式，便于同时写入域名后缀和关键字规则：
对应的 ai-services.yaml 内容可以写成：
这里的列表只代表域名匹配，不代表任何服务一定能够访问。实际效果还取决于节点所在地、服务的账户区域、DNS 设置以及客户端内核版本。对于 OpenAI、Claude 等服务，建议把登录、接口和静态资源域名统一交给同一个稳定的 AI 策略组，避免页面通过代理打开，但 API 请求却误走直连。
开发工具规则提供者
开发工作流通常不只是访问 GitHub。代码编辑器、插件市场、Docker 镜像、语言包管理器和文档站点可能使用完全不同的域名。可以单独建立 dev-tools，让这些流量进入一个稳定的开发策略组：
规则文件示例：
如果你主要使用 Git、npm 或 Docker，建议观察实际请求后再添加域名。以 Docker 为例，登录服务、镜像索引和具体仓库可能不在同一个域名下，只写 docker.com 并不一定能够完成拉取。相反，直接把所有包含 docker 的域名都加入规则，也可能造成不必要的代理流量。
本地文件与远程文件的取舍
如果规则变化不频繁，可以把文件放在本地配置目录，通过 type: file 引用。远程 HTTP 提供者适合多人共享或需要自动更新的场景，但必须考虑链接稳定性和供应链风险。生产环境中不要无条件信任陌生规则仓库，下载后应检查每一行内容，确认没有过度宽泛的匹配项。
安全提醒
不要把订阅链接、私有仓库令牌或带有身份信息的 URL 提交到公开 Git 仓库。规则文件通常不需要任何密码；如果某个“规则下载地址”要求上传订阅凭据，应立即停止使用。
3用 Git 管理规则：让更新可追踪、可回滚
将 AI 和开发工具规则放入 Git 仓库后，每次新增域名、删除失效规则或调整匹配方式，都可以通过提交记录留下原因。对于经常切换设备的用户，Git 还可以作为规则文件的同步中心，再由 Clash 通过 raw 文件地址定期拉取。
推荐的仓库结构
每次修改前先通过浏览器或命令行确认 YAML 能够正常解析，再提交到仓库。提交信息应写清楚变更原因，例如“补充 Gemini API 域名”或“移除已停用的镜像地址”，不要只使用“update”这类无法帮助排查的描述。
更新间隔与回滚策略
interval: 86400 表示 Clash 每 24 小时检查一次远程文件。规则库变化较少时，86400 或 604800 都比较合适；不建议设置成几分钟一次，因为这会增加请求频率，也可能触发代码托管平台的限制。修改后可以在客户端的规则提供者页面手动点击更新，确认没有错误后再等待自动更新。
如果更新后某个服务突然无法访问，先查看提供者的更新时间，再在 Git 中回退到上一个稳定提交。也可以临时把该服务的规则复制到本地文件，确认问题来源后再重新发布远程版本。不要在故障时同时更改 DNS、策略组和规则文件，否则很难判断究竟是哪一层造成了问题。
- 提供者名称只使用字母、数字和连字符，且与
RULE-SET中的名称完全一致。 - YAML 缩进统一使用空格，不要混用 Tab；字段名后的冒号必须正确。
- 远程 URL 能够直接返回规则文件，而不是登录页面、重定向页面或 JSON 错误信息。
path目录可写，客户端有权限保存下载的规则文件。- 策略组名称与规则末尾的目标名称一致，例如都使用
Developer。
4系统排查：规则未命中或域名走错怎么办？
遇到“规则明明写了但没有生效”时，不要立刻增加更多域名。首先打开客户端的连接记录或规则命中详情，查看请求的实际域名、匹配规则和最终策略组。浏览器地址栏显示的站点名称，往往不是后台真正发起请求的域名。
提供者没有加载
如果客户端提示 rule-provider 下载失败，先单独在浏览器中打开 url，确认文件可以访问。若文件内容为空、返回 404、出现 GitHub HTML 页面，或仓库设置为私有，Clash 都无法将其作为规则文件解析。接着检查 behavior 与文件内容是否对应：带有 payload: 和完整规则类型的文件通常使用 classical，只包含域名列表的文件则应按实际格式配置。
规则未命中
常见原因包括拼写错误、规则没有放入 rules 列表、规则提供者名称不一致，以及前面已有更宽泛的规则提前命中。例如 DOMAIN-KEYWORD,google,DIRECT 放在 AI 规则之前，可能会让某些 Google AI 请求先走直连。把专用规则移动到通用规则之前，并重新发起请求，通常可以快速验证顺序问题。
域名命中但策略错误
如果日志显示已经命中 ai-services，但最终仍然使用了错误节点，应检查规则末尾的策略组名称，而不是继续修改域名。策略组名称区分大小写，AI、Ai 和 ai 可能被视为不同名称。还要确认当前客户端运行的是 Rule 模式，而不是 Global 或 Direct 模式。
- 页面可以打开但接口失败：检查 API 域名、WebSocket 请求以及静态资源是否使用同一个策略组。
- GitHub 页面正常但 Clone 失败：检查 Git 使用的代理端口，命令行流量不一定自动继承系统代理。
- Docker 登录成功但拉取失败：查看镜像仓库实际域名，并为 registry 与认证服务补充规则。
- 更新规则后客户端报错：回滚最近一次提交，检查 YAML 缩进、特殊字符和不可见的全角标点。
排查顺序建议
按照“运行模式 → 提供者下载状态 → 文件格式 → rules 引用 → 规则顺序 → 策略组名称 → DNS 与节点质量”的顺序检查。这样可以先排除配置层面的错误，再判断是否属于节点或服务本身的问题。
常见问题
一个服务应该使用 DOMAIN-SUFFIX 还是 DOMAIN-KEYWORD？
优先使用 DOMAIN-SUFFIX。它只匹配指定域名及其子域名，范围更清晰。例如 DOMAIN-SUFFIX,github.com 不会误伤包含“github”字符串的其他域名。只有当服务的域名结构不固定，或者你确认关键词不会带来误匹配时，才考虑使用 DOMAIN-KEYWORD。
为什么规则文件有 payload，但仍然加载失败？
需要同时检查 format 与 behavior。如果文件是 YAML，应设置 format: yaml；如果文件只是纯文本列表，不要强行按 YAML 读取。还要确认顶层字段拼写为 payload，每个列表项前有一个短横线，并且缩进使用空格。
修改 Git 文件后，Clash 为什么没有立即更新？
rule-provider 会按照 interval 定期检查，Git 推送完成不等于客户端马上下载。可以在客户端的规则提供者页面手动执行更新，或暂时降低间隔进行测试。确认新版本生效后，再恢复为每天或每周更新，避免产生不必要的请求。
Clash Verge 与 Mihomo 客户端的配置是否完全相同？
核心字段大多相同，但不同客户端捆绑的内核版本、配置校验方式和界面入口可能不同。若某个字段无法识别，应先查看当前内核版本和官方文档，不要把其他代理工具的规则格式直接复制过来。使用配置检查功能验证通过后，再开启 TUN 或系统代理进行实际测试。
rule-providers 的价值在于把复杂分流拆成可维护的模块。只要保持规则范围明确、引用名称一致、提交记录清晰，并结合连接日志验证实际命中结果，就能为 AI 服务和开发工具建立一套稳定、可持续更新的 Clash 配置。