Clash自定义规则集进阶配置：用GitHub托管rule-providers
在日常使用中，我们经常会遇到只有 PC 端开启了代理，但手机、电视盒或其他移动设备也需要科学上网的情况。通过 Clash Verge Rev 的「允许局域网连接（Allow LAN）」功能，你可以轻松地将电脑的代理网络共享给同一 Wi-Fi 下的所有设备。本文将手把手带你完成从软件开关到 Windows 防火墙策略的完整配置流程。
为什么把规则拆成 rule-providers
当配置里的分流规则不断增加，直接把所有条目写进 rules 会让主配置越来越长。AI 服务、代码托管平台、包管理站点和开发文档各自有不同的访问需求，规则混在一起后，不仅难以阅读，修改时也容易误删、重复添加，或把一条规则放到错误的位置。使用 rule-providers，可以把规则内容放在独立文件中，由 Mihomo 按需下载和更新；主配置只保留规则集名称、策略组和匹配顺序。
需要先明确兼容范围：rule-providers 是 Mihomo 等支持该功能的内核所提供的规则集机制，并不代表所有历史版 Clash 内核或所有客户端都能直接识别。Clash Verge、Clash Verge Rev 等客户端通常由其实际启用的内核解析配置，界面名称相同并不能保证内核能力相同。开始调整前，先在客户端的内核信息或日志中确认正在运行的是 Mihomo，并检查版本是否支持你打算使用的字段。
规则集和代理节点订阅也不是一回事。规则集描述「哪些流量属于某一类」，例如某些 AI 服务域名；节点或策略组决定「匹配之后怎么连接」。因此，下载规则集成功并不代表对应网站一定能访问：还要确认规则指向了可用的策略组，策略组中存在可用节点，并且没有更靠前的规则提前匹配。
适合拆分的内容
把变化较频繁、来源清楚、能够单独验证的规则放进规则集，例如 AI 服务域名、开发平台域名或自维护的少量例外规则。DNS、代理节点、监听端口等主配置内容不属于规则集，应继续放在各自对应的配置段中。
准备 GitHub 仓库与规则文件
GitHub 仓库可以作为公开规则文件的托管位置。建议使用一个专门的仓库，明确区分规则用途，并为文件和目录采用稳定、容易理解的名称。规则文件一旦被主配置引用，就相当于一个外部依赖；随意改名、移动目录或删除旧文件，都会使客户端下一次更新失败。
仓库组织建议
- 按用途划分文件，例如
rules/ai.yaml、rules/development.yaml，避免一个文件混合无关规则。 - 使用明确的分支名与路径，例如固定使用
main分支，避免引用会频繁变动的临时分支。 - 提交前检查 YAML 缩进、重复域名和规则类型；需要回滚时，保留 Git 历史记录，方便定位变更。
- 公开仓库不要提交订阅链接、访问令牌、个人账号信息或其他敏感数据。
仓库公开后，可以使用 GitHub 提供的原始文件地址访问规则内容。打开目标文件，确认内容可公开读取，再从文件页面复制 Raw 地址。通常地址会包含仓库名、分支名和文件路径。复制后建议在浏览器中单独打开该 URL：如果看到的是 GitHub 页面而不是规则文件内容，通常复制的不是 Raw 地址；如果返回 404，则应检查仓库是否公开、路径大小写是否一致，以及文件是否确实存在。
私有仓库的访问方式要格外谨慎。不要把个人访问令牌直接拼进公开配置 URL，也不要把带令牌的配置分享给他人或提交到公共仓库。令牌一旦泄露，可能造成仓库或账号被未授权访问。对于需要认证的规则托管，应先评估客户端是否支持安全的认证配置，并遵循服务平台的权限最小化原则；不确定时，使用不含秘密信息的公开规则文件，或改用受控的私有托管方案。
避免把默认分支当作永久地址保证
Raw 文件 URL 依赖仓库、分支和路径。仓库改名、文件移动或分支变更，都可能造成更新失败。正式使用前先固定一套路径，并在仓库变更时同步检查主配置中的 URL。
配置 rule-providers 与规则优先级
rule-providers 的每个条目至少要明确规则集类型、匹配行为、文件格式、本地缓存路径、远程 URL 和更新间隔。下面示例使用 Mihomo 常见的 HTTP 规则集写法；实际可用字段会随内核版本变化，部署前请以所用版本的 Mihomo 文档为准。示例中的仓库地址需要替换为你自己的公开 Raw 文件地址，策略组名称也必须与主配置中已有的名称一致。
rule-providers:
ai-services:
type: http
behavior: domain
format: yaml
path: ./ruleset/ai-services.yaml
url: https://raw.githubusercontent.com/example/clash-rules/main/rules/ai.yaml
interval: 86400
development-tools:
type: http
behavior: classical
format: yaml
path: ./ruleset/development-tools.yaml
url: https://raw.githubusercontent.com/example/clash-rules/main/rules/development.yaml
interval: 86400
rules:
- RULE-SET,ai-services,AI
- RULE-SET,development-tools,PROXY
- MATCH,DIRECTtype: http 表示由内核通过 HTTP 或 HTTPS 获取规则集；path 是本地缓存位置，通常应使用便于管理的独立目录；interval 以秒计，示例中的 86400 代表约一天检查一次。频繁更新并不总是更好：规则文件变化不大时，较短间隔只会增加请求次数；如果规则变化较快，可根据更新节奏调整。客户端可能会在启动时更新，也可能按间隔检查，具体行为受内核版本和客户端管理方式影响。
behavior 必须与规则文件内容相匹配。domain 适合只包含域名类匹配项的规则集；ipcidr 用于 IP 网段；classical 适合包含多种传统规则类型的集合。若选择 format: yaml，规则文件通常以 payload 列表组织，例如：
payload:
- DOMAIN-SUFFIX,example.ai
- DOMAIN,api.example.dev
- DOMAIN-KEYWORD,developer如果规则文件采用纯文本格式，则需要根据 Mihomo 支持的格式和行为类型编写对应内容。不要只因为文件扩展名是 .txt 就假定它会被自动正确解析；文件实际语法、format 与 behavior 必须彼此匹配。尤其是将多种规则类型混在一个集合时，应选择能够表达这些类型的行为，并在本地先验证文件，而不是等客户端启动后再根据报错猜测。
rules 列表按从上到下的顺序匹配，通常第一条匹配到的规则决定最终策略。因此，规则集引用要放在可能提前覆盖它的宽泛规则之前。例如，若一条较宽的域名规则已经将相关站点送往 DIRECT，之后再写 AI 规则集就不会获得预期效果。另一方面，若将某个宽泛规则集放得过前，可能会把本来需要直连的域名送入代理。调整顺序时要围绕实际域名逐条确认，并保留最后的 MATCH 兜底规则。
不要猜策略组名称
RULE-SET,ai-services,AI 中的 AI 必须是当前配置里真实存在的策略组名称。若订阅更新后策略组改名，规则仍可能成功加载，但使用时会出现配置校验错误或无法按预期分流。先检查 proxy-groups，再填写规则目标。
校验配置、更新与故障排查
建议先用小范围规则集验证完整流程，再逐步扩大内容。第一次设置时只加入一两个不敏感、容易测试的域名，确认远程文件可访问、本地缓存能生成、内核能解析，并且连接日志显示命中了预期规则。完成这一轮后，再加入更多 AI 和开发工具规则。这样遇到问题时，可以快速判断是托管地址、文件格式、规则匹配还是策略组配置导致，而不是面对一大批新规则逐项排查。
- 先检查远程文件。在浏览器中打开 Raw URL，确认没有 404、权限页面、HTML 错误页或空内容。若规则托管服务暂时不可达，先确认本机网络和 DNS，再确认客户端是否能连接 GitHub。
- 再检查 YAML 与字段。核对缩进、冒号、列表层级和字段名称；留意
behavior与文件内容是否对应。不要把规则文件中的payload层级误放到主配置的rules中。 - 检查规则集是否被引用。
rule-providers只定义和加载集合，不会自动让其中的规则生效；还必须在rules中添加对应的RULE-SET条目。 - 检查优先级和策略组。从上到下查看可能先于目标规则命中的条目，并确认规则目标名称与策略组实际名称完全一致。
- 最后查看内核日志。重新加载配置后，搜索 provider 名称、URL、下载失败、解析失败或策略组不存在等提示。根据日志修正后再重新加载，不要一次同时改动多个部分。
更新间隔只是检查远程文件的周期，不等于每次 GitHub 提交后所有客户端都会立即同步。客户端可能仍在使用本地缓存，重新载入配置、手动触发更新或等待下一次检查，才能取到新内容。若希望快速验证更新，可临时调整规则文件中的一条测试项，更新后观察连接面板中的匹配结果；验证完应移除测试项，并恢复合理的更新间隔。
排错时还要区分「规则没下载」与「规则下载了但没命中」。前者多关注 Raw URL、网络连通性、证书和更新日志；后者则检查域名是否真的符合该规则、规则集行为是否正确、匹配项是否被更早的规则截走。测试时尽量用目标应用实际访问的主机名，而不是只凭服务品牌名判断；一个产品可能使用多个 API、静态资源和登录域名，规则集未必覆盖所有关联域名。
与把所有规则手动复制到主配置相比，GitHub 规则集更容易审阅变更、复用和回滚；与完全依赖黑盒订阅或单一图形工具自动生成相比，它也提供了更清楚的文件来源和更新路径。不过，外部规则源仍可能失效，规则覆盖范围也需要维护。Mihomo 将规则集、策略组和匹配顺序拆开管理，便于逐项排查和按需调整。如果你希望在熟悉配置的同时使用支持 Mihomo 的客户端，不妨先查看适合自己平台的版本，再结合本文从小型公开规则集开始实践：免费下载 Clash，立即体验。