Clash自定义Rule-Providers规则集：GitHub托管与进阶配置指南

先理解 rule-providers 的工作方式

rule-providers 用于把大量域名、IP 或经典规则从主配置中拆分出来，保存为独立的规则集文件，再通过 RULE-SET 规则引用。这样做的好处是主配置更容易阅读，规则可以单独更新，也能把 GitHub 上维护的公开规则与自己的分流策略组合起来。它并不会创建代理节点，也不会决定某个策略组使用哪条线路；它只负责提供“哪些目标属于某个分类”的匹配数据。

一次完整的匹配通常包含三个环节：内核按照 rule-providers 中的地址下载规则文件，将文件解析并缓存到本地；主配置中的 rules 使用 RULE-SET,提供者名称,策略 引用它；流量命中规则后，再交给指定的代理组、直连或拒绝策略处理。规则提供者名称必须与引用处完全一致，大小写、连字符和下划线都不能随意改动。

rule-providers:
  github:
    type: http
    behavior: domain
    url: https://raw.githubusercontent.com/example-org/example-rules/main/github.list
    path: ./ruleset/github.list
    interval: 86400

rules:
  - RULE-SET,github,GitHub
  - MATCH,节点选择

上面的示例中，github 是提供者名称，type: http 表示从远程 HTTP(S) 地址获取文件，behavior: domain 表示文件内容应符合域名规则格式，path 是本地缓存位置，interval: 86400 表示每 86400 秒检查一次更新。最后一条 MATCH 是兜底规则，避免没有任何规则命中时流量没有明确去向。

常用字段与格式选择

behavior 不是随意填写的标签，而是内核解析规则的依据。只有域名列表时使用 domain；只包含 IP 或 CIDR 网段时使用 ipcidr；同时含有 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等完整 Clash 规则行时，通常使用 classical。如果类型声明错误，常见结果是规则集下载成功但启动时报格式错误，或者规则可以载入却始终无法命中。

用 GitHub 托管自己的规则文件

GitHub 适合托管小型、可审查、变更频率明确的规则集。建议为每个用途建立独立文件，例如 github.list、developer.list、ai.list 和 container.list，不要把所有域名长期堆在一个几千行的文件里。文件名应体现用途，提交记录则用于追踪是谁在什么时候增加或删除了域名。

远程地址必须指向原始文件，而不是仓库主页。常见地址结构如下，实际使用时替换组织名、仓库名、分支名和文件路径：

https://raw.githubusercontent.com/组织名/仓库名/main/rules/github.list

如果仓库启用了自定义域名、镜像或 CDN，也可以使用能够直接返回文件内容的 HTTPS 地址。测试时重点观察响应头中的 Content-Type、HTTP 状态码和文件正文。浏览器打开一个网页并看到文件内容，不代表 Clash 请求到的就是同一份纯文本；某些地址会根据 User-Agent、地区或访问频率返回 HTML 验证页。

规则文件的编写原则

域名型规则建议一行一个域名，不要加入协议、路径、端口或完整 URL。大多数情况下，使用根域名和必要的子域名即可。例如 GitHub 相关服务可能分布在多个域名上，不能只写一个站点首页就假设所有下载、对象存储和 API 请求都会被覆盖。

# github.list
github.com
githubusercontent.com
githubassets.com
githubapi.com
githubcopilot.com

注释应保持简短，并使用规则文件支持的注释语法。不要把带有空格、逗号或不可见字符的复制内容直接粘贴进去。提交前可以用文本编辑器显示行尾符号，检查是否混入 Windows 与 Unix 换行、全角标点或 BOM。公开规则集还应避免把个人订阅地址、内网域名、临时测试域名和未经核实的 IP 地址提交到仓库。

GitHub 分支和文件路径一旦用于多人配置，就相当于一个公开接口。重命名文件、删除分支或强行覆盖历史，会让所有客户端在下一次更新时收到 404、旧版本内容或校验失败。更稳妥的做法是使用固定的默认分支和稳定文件路径，更新内容通过普通提交完成；如果必须更换路径，应至少保留一段兼容期，并同步修改主配置。

缓存、冷启动与离线行为

path 不只是下载后的临时文件名，它还是内核重新启动时读取规则集的本地位置。首次启动且网络不可用时，没有缓存的远程规则可能无法加载；已经成功下载过的规则通常可以继续使用缓存，具体行为取决于内核版本和客户端实现。因此，首次部署时应先在网络正常的环境中手动更新所有规则集，再测试断网启动。

路径最好使用相对配置文件的目录，例如 ./ruleset/github.list。如果在多个客户端之间复制配置，绝对路径如 Windows 的 C:\Users\... 或 macOS 的 /Users/... 很容易失效。每个提供者使用独立文件名，避免把 github 和 ai 都缓存成 rules.list，否则排查时很难判断当前文件属于哪个提供者。

创建可维护的 YAML 配置

规则集真正发挥作用，必须与策略组和规则顺序配合。下面是一份适合 mihomo 的结构示例。组名只是示例，实际名称必须与配置中的代理节点或策略组一致；如果订阅已经提供了“节点选择”，可直接复用，不必重复创建同名策略。

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

  - name: GitHub
    type: select
    proxies:
      - 节点选择
      - DIRECT

  - name: 开发工具
    type: select
    proxies:
      - 节点选择
      - DIRECT

  - name: AI 服务
    type: select
    proxies:
      - 节点选择

  - name: 容器服务
    type: select
    proxies:
      - 节点选择
      - DIRECT

rule-providers:
  github:
    type: http
    behavior: domain
    format: text
    url: https://raw.githubusercontent.com/example-org/example-rules/main/github.list
    path: ./ruleset/github.list
    interval: 86400

  developer:
    type: http
    behavior: domain
    format: text
    url: https://raw.githubusercontent.com/example-org/example-rules/main/developer.list
    path: ./ruleset/developer.list
    interval: 86400

  ai:
    type: http
    behavior: domain
    format: text
    url: https://raw.githubusercontent.com/example-org/example-rules/main/ai.list
    path: ./ruleset/ai.list
    interval: 43200

  container:
    type: http
    behavior: domain
    format: text
    url: https://raw.githubusercontent.com/example-org/example-rules/main/container.list
    path: ./ruleset/container.list
    interval: 86400

rules:
  - RULE-SET,github,GitHub
  - RULE-SET,developer,开发工具
  - RULE-SET,ai,AI 服务
  - RULE-SET,container,容器服务
  - DOMAIN-SUFFIX,npmjs.org,开发工具
  - DOMAIN-SUFFIX,pypi.org,开发工具
  - DOMAIN-SUFFIX,pythonhosted.org,开发工具
  - MATCH,节点选择

这里把不同用途拆成四个策略组，便于在客户端中单独切换。例如 GitHub 代码浏览可以走代理，而某些企业内网开发域名仍然直连；AI 服务通常不应简单套用普通开发工具策略，因为它可能包含单独的 API 域名、登录域名和静态资源域名。分组的价值在于减少“一刀切”，而不是增加越多组越好。

规则顺序决定最终结果

Clash 规则按从上到下的顺序匹配，先命中的规则会停止继续检查。因此，特定的规则集应放在宽泛规则之前。若把 GEOIP,CN,DIRECT、MATCH,DIRECT 或某个覆盖范围很大的规则集放在前面，后面的 GitHub、AI 或容器规则可能永远不会执行。

rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - RULE-SET,github,GitHub
  - RULE-SET,ai,AI 服务
  - RULE-SET,container,容器服务
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

上例先排除明确的内网域名，再处理自定义规则集，最后才使用地理位置和兜底规则。若同一个域名同时出现在 GitHub 和开发工具两个列表中，最终策略由哪条 RULE-SET 位于前面决定。规则文件之间应尽量保持边界清晰，必要时把更具体的服务域名放入专用列表，而不是让多个列表大量重叠。

为 GitHub、npm、pip、Docker Hub 与 AI 服务分流

GitHub：不要只收录主站域名

GitHub 的网页、API、Release 下载、Raw 文件和大型文件存储可能使用不同域名。若规则集只包含 github.com，代码浏览可能正常，但 Release 资源、Raw 文件或某些扩展功能仍可能直连失败。建议根据实际日志逐步增加域名，并先用域名规则覆盖，再考虑是否需要更复杂的 IP 规则。

# github.list
github.com
api.github.com
raw.githubusercontent.com
objects.githubusercontent.com
codeload.github.com
githubassets.com
githubusercontent.com

不建议把所有 GitHub 相关流量永久固定到同一策略。企业组织的私有域名、内部 Git 服务和某些镜像地址可能需要直连。可以在 GitHub 规则前添加明确的企业域名直连规则，或者把企业域名单独放入 internal.list，让规则优先级表达真实需求。

npm 与 pip：区分注册表、镜像和项目资源

npm 常见的公共注册表域名包括 registry.npmjs.org，包的静态资源还可能由其他 CDN 提供。pip 常见的公共索引域名包括 pypi.org 与 pythonhosted.org。如果团队使用内部 npm registry 或 Python 私有源，不应把所有相关域名都送入同一个代理组，否则可能绕过内网访问策略。

# developer.list
registry.npmjs.org
npmjs.org
pypi.org
pythonhosted.org
files.pythonhosted.org
nodejs.org
python.org

命令行工具是否遵循系统代理，取决于工具自身的代理环境变量和实现。即使 Clash 规则已经正确命中，npm、pip 仍可能因为没有读取系统代理而直连。需要单独检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 以及工具的镜像配置。不要为了修复命令行下载问题而盲目修改规则集，先确认请求是否真的进入 mihomo。

Docker Hub：登录与镜像层可能不是同一域名

Docker 拉取镜像时通常涉及 Registry API、认证服务和内容分发网络。只把 docker.com 加入规则集并不能覆盖全部请求。常见相关域名包括 docker.io、registry-1.docker.io、auth.docker.io 和内容分发域名，但实际请求会随 Docker 版本、镜像源和地区变化。

# container.list
docker.com
docker.io
registry-1.docker.io
auth.docker.io
hub.docker.com

Docker Engine 在 Linux 上通常不是普通桌面应用，它可能运行在 systemd 服务、虚拟机或 WSL 环境中。桌面端的系统代理开关不一定会自动传递给 Engine。配置完成后应分别测试镜像搜索、登录和拉取，并查看 mihomo 连接日志。如果完全看不到 Docker 请求，问题多半在 Docker 的代理设置、虚拟机网络或服务重启，而不是 rule-providers。

AI 服务：按域名与功能拆分

AI 服务往往包含网页主站、API、登录认证、静态资源和实时连接。只配置一个主域名可能导致页面能打开但 API 请求失败，或者登录页面可以显示但模型请求超时。建议先从连接日志中记录实际访问的域名，再建立专用规则集。不同服务的域名会变化，规则文件需要设置合理的更新周期并定期复核。

# ai.list
openai.com
api.openai.com
chatgpt.com
oaistatic.com
anthropic.com
claude.ai
ai.google.dev
generativelanguage.googleapis.com

AI 流量通常不适合在策略组中默认加入 DIRECT，因为误切换后可能出现地区限制、证书链路差异或 API 超时。但如果所在网络已经提供合规且稳定的本地服务，仍可以保留直连选项。更重要的是不要把认证令牌写入规则文件、YAML 或公开仓库；规则集只应包含匹配域名，不应包含 API Key、Cookie 和订阅凭据。

更新、验证与故障排查流程

完成配置后，先不要立即启用 TUN 或把所有服务切换到新规则。建议采用“语法检查、手动更新、命中验证、断网验证、长期观察”的顺序。这样可以区分 YAML 解析错误、远程文件下载失败、规则格式错误和策略组连接失败，避免多个变量同时变化。

1. 检查 YAML 缩进：键名使用半角字符，层级使用空格，不要用 Tab。确认 rule-providers、rules 和策略组位于正确层级。
2. 验证远程文件：使用浏览器或 curl 检查状态码、文件大小和正文格式。响应应是规则文本，而不是 HTML 错误页。
3. 手动更新提供者：在 FlClash 或其他 mihomo 客户端的规则集、Providers 或配置详情页面逐项更新，记录失败的提供者名称。
4. 查看缓存文件：检查 path 对应文件是否生成，内容是否为最新提交，文件大小是否突然变成几十字节。
5. 观察连接日志：访问目标服务时确认请求域名、命中的规则和最终策略组，不能只依据网页是否打开判断。
6. 逐项恢复配置：若多个规则集同时失败，先保留一个最小规则集测试，再逐个加入其他提供者。

curl -L --connect-timeout 10 --max-time 30 \
  -A "mihomo" \
  -o github.list \
  -w "HTTP=%{http_code} SIZE=%{size_download} TYPE=%{content_type}\n" \
  "https://example.invalid/rules/github.list"

长期维护与安全边界

自定义规则集不是一次配置后永久不变的清单。服务商会更换 CDN，GitHub 会增加新的资源域名，AI 服务也可能把网页、API 和认证请求迁移到不同主机。建议每月检查一次规则集的提交记录和连接日志；规则更新频繁的项目可以设置 12 小时检查一次，个人维护且变化较少的文件使用 24 小时或更长间隔更合适。

• 保持单一职责：一个文件服务一个清晰用途，避免把 AI、代码托管和容器仓库混成无法审查的大列表。
• 控制规则数量：能用域名后缀表达的内容，不必复制大量单独子域名；但涉及不同策略时必须拆分。
• 固定审核流程：公开仓库开启合并请求或至少保留提交说明，删除域名前先确认是否仍被客户端使用。
• 保护隐私信息：规则文件、YAML、日志和 Git 提交中不得出现订阅令牌、Cookie、私钥或 API Key。
• 准备本地副本：重要规则集可以在客户端缓存之外保存一份经过验证的本地文件，用于源站暂时不可用时恢复。
• 记录实际效果：以连接日志中的命中规则和策略为准，不要只看规则文件是否下载成功。

如果规则集数量较多，可以先在一个单独配置中验证，再合并到日常订阅。每次只引入一个提供者，确认客户端能够启动、规则集能够更新、目标域名能够命中后再继续。FlClash 使用 mihomo 内核时，应同时参考当前客户端界面显示的内核版本，因为不同版本对规则格式、MRS 文件和扩展字段的支持范围可能存在差异。

最终配置应满足三个条件：远程文件来源稳定且可审查，规则格式与 behavior、format 一致，规则顺序能够准确表达直连、代理和拒绝策略。做到这三点后，GitHub 托管的自定义规则集就不再只是“复制一份域名列表”，而是成为可更新、可回滚、可按服务拆分的配置组件。