Clash自定义规则集怎么写？Rule Providers托管与进阶配置

先理解 Rule Providers 的职责与匹配顺序

rule-providers 用来把一组规则存放在独立文件中，再由主配置按名称引用。它适合维护较长、需要多人协作或需要定期更新的域名与 IP 列表。主配置保留代理策略、策略组和规则顺序，规则文件则只保存匹配条件；之后更新站点列表时，不必每次都修改整份配置。

规则提供者本身不会决定流量走直连还是代理。它只提供匹配项，真正的出站策略由主配置里的 RULE-SET 规则指定。例如，RULE-SET,developer-sites,Developer 表示命中 developer-sites 规则集的流量交给名为 Developer 的策略组处理。若该策略组不存在，或组内引用了不存在的节点，配置就无法按预期工作。

常见字段各自承担不同职责：type 指定规则来源方式，远程文件通常使用 http；behavior 声明规则类型；format 指定文件格式；url 是远程文件地址；path 是本地缓存位置；interval 是更新间隔，单位为秒。behavior 必须与文件内容相符，不能把域名列表声明成 IP 规则，也不能把完整的 Clash 规则行当作普通域名列表。

domain：用于域名及域名后缀，适合 GitHub、npm、Docker Hub 等站点的域名集合。
ipcidr：用于 IPv4 或 IPv6 CIDR 网段，例如 203.0.113.0/24。不要把域名写进这类文件。
classical：用于传统规则行，例如 DOMAIN-SUFFIX,example.com、IP-CIDR,203.0.113.0/24。此类规则文件通常使用纯文本格式。

编写 GitHub、npm 与 Docker Hub 域名规则

下面的例子将开发相关站点放进一个 YAML 规则文件。它使用域名后缀匹配，覆盖 GitHub 常见页面与下载域名、npm 注册表以及 Docker Hub 的认证和镜像服务。实际站点可能使用第三方 CDN、对象存储或区域性域名，因此这份列表是维护起点，不是所有请求的完整清单。

payload:
  - '+.github.com'
  - '+.githubusercontent.com'
  - '+.githubassets.com'
  - '+.npmjs.com'
  - '+.npmjs.org'
  - '+.docker.com'
  - '+.docker.io'
  - '+.dockerusercontent.com'

将文件保存为仓库中的 rules/developer-sites.yaml。这里的 +. 表示域名及其子域名，例如 +.github.com 可覆盖 github.com 和 api.github.com。如果只希望匹配一个精确主机名，也可以直接写主机名；规则范围越宽，越要确认它不会意外覆盖不相关服务。

主配置中加入提供者、策略组和规则。以下片段可以合并到现有配置：其中 Developer 组当前只包含 DIRECT，用于展示结构；如果目标是让开发站点走代理，应把它替换为配置里真实存在的代理节点或代理策略组。不要照抄一个未定义的策略名称。

mode: rule

proxy-groups:
  - name: Developer
    type: select
    proxies:
      - DIRECT

rule-providers:
  developer-sites:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/your-name/your-rules/main/rules/developer-sites.yaml
    path: ./rules/developer-sites.yaml
    interval: 86400

rules:
  - RULE-SET,developer-sites,Developer
  - MATCH,DIRECT

将示例中的 your-name/your-rules 换成自己的 GitHub 用户名与仓库名；分支名、目录名和文件名都必须与仓库实际路径一致。interval: 86400 表示约每 24 小时检查更新一次。修改成更短的间隔不会让规则匹配更准确，反而可能增加远程请求次数；一般个人规则集每天更新一次已经足够，变化较少的规则也可以设置更长间隔。

通过 GitHub 仓库托管规则文件

创建一个公开仓库，例如 your-rules，并在仓库中建立 rules 目录。
添加 developer-sites.yaml，先确认缩进使用空格，根字段为 payload。
提交文件后打开仓库中的文件页面，检查分支、路径和文件内容，再按 Raw 文件地址的结构填写 url。
将同一文件路径写入 path，作为 mihomo 下载后的本地缓存位置。
把主配置中的 RULE-SET 放到希望它优先匹配的位置，并确认目标策略组已经定义。

托管仓库只需要提供规则文件，不必把主配置或订阅凭据放进仓库。公开仓库中的规则内容任何人都可以查看；订阅令牌、私有代理地址、控制接口密钥等敏感信息不应提交。若使用私有仓库，还要考虑内核如何进行认证，以及客户端更新时能否访问；对个人规则集而言，公开仓库通常更容易部署和排错。

规则文件更新后，mihomo 会在本地缓存路径保存获取到的内容，并根据 interval 定期检查远端变化。配置启动时首次下载失败、仓库路径写错、文件尚未提交或网络无法访问 Raw 地址，都可能导致规则集不可用。托管端返回 404 时，先核对仓库是否公开、分支是否正确、文件路径大小写是否一致；Git 路径通常区分大小写。

安排规则顺序与开发流量策略

Clash 规则按 rules 中的顺序从上到下匹配，遇到第一条匹配项后就使用对应目标。因此，规则集的位置会直接影响最终路线。若 RULE-SET,developer-sites,Developer 放在 MATCH,DIRECT 之后，它永远不会被执行；若前面已有覆盖范围更广的规则，也可能先被那条规则截获。

一个便于维护的排列方式是：局域网与明确直连规则在前，特定业务规则集放在中间，兜底规则放在最后。实际配置可能还包含广告拦截、流媒体或地区规则，不能机械套用固定顺序；应检查每一条规则的覆盖范围，并决定它与开发站点规则之间谁拥有优先权。

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,developer-sites,Developer
  - GEOIP,private,DIRECT
  - MATCH,节点选择

以上顺序只作结构示例。若使用 GEOIP,private,DIRECT，应确认所用内核支持该规则及对应数据库；如果已有规则集规则，则把示例替换为现有配置中真实有效的规则。特别要注意，某些开发站点会解析到共享 CDN 或云服务地址。只按域名分流通常比把整个云厂商 IP 段送入同一策略更精准。

使用策略组而非写死节点：Developer 可以指向节点选择组，让需要切换线路时只改组内选择，不必重写每条规则。
保留必要的直连入口：若开发站点主要用于下载依赖，可在测试后决定哪些域名需要代理，不要默认把整个规则列表都强制代理。
避免重复维护：同一个域名同时出现在多个规则集时，前面的规则可能已经决定路线。重复条目不会自动合并成多个策略。
按用途拆分：规则数量增长后，可把代码托管、软件包注册表和容器镜像分别维护，再在主配置中按不同策略引用。

以 npm 为例，网页、注册表 API 和包文件可能分别由不同主机名提供；Docker Hub 也涉及账户认证、镜像清单和实际镜像层下载。遇到“登录成功但拉取镜像失败”时，应从连接日志中查看实际请求的目标域名，再决定是否补入规则，而不是一开始就把整个 CDN 或云厂商的地址范围加入规则集。

校验规则、确认更新并排查失效

发布规则前先检查两层内容：规则文件本身是否符合声明的格式，主配置是否能解析并引用正确的提供者名称。远程地址可用 curl 查看 HTTP 状态与返回内容；确认地址只获取预期的 YAML，而不是 GitHub 网页、登录页或错误提示。不要把带有访问令牌的私有 URL 粘贴到公开日志或问题截图中。

curl -L --connect-timeout 10 --max-time 30 \
  -o developer-sites.yaml \
  -w "HTTP=%{http_code} SIZE=%{size_download}\n" \
  "https://raw.githubusercontent.com/your-name/your-rules/main/rules/developer-sites.yaml"

成功下载通常应看到 HTTP=200，文件大小也应大于零。随后使用所运行的 mihomo 内核检查主配置，例如在桌面系统终端执行：

mihomo -t -f ./config.yaml

具体命令参数可能因内核版本和客户端封装方式而不同；如果客户端提供“检查配置”或“重载配置”功能，也可以使用该入口。语法检查通过不代表远程规则一定能访问，因此还要查看内核日志中的规则提供者加载记录，并确认规则集没有出现超时、状态码错误或格式解析失败。

提示找不到规则提供者：核对名称拼写。RULE-SET 中的名称必须与 rule-providers 下的键一致。
提示策略组不存在：检查规则目标名称，并确认 proxy-groups 中存在对应策略组。
HTTP 404：检查仓库名、分支、文件夹和文件名，尤其是大小写及文件是否已提交。
HTTP 403 或请求超时：确认当前网络能否访问托管地址；更换网络测试时，避免同时修改 DNS、代理和 URL，方便定位原因。
文件下载成功但加载失败：检查 behavior 与文件结构是否匹配，并确认 YAML 缩进、引号和列表格式正确。
规则集已加载但路线不对：检查规则先后顺序、目标策略组当前选择，以及更早规则是否已经匹配。

最后进行一次真实请求验证：在客户端连接记录中找到 GitHub、npm 或 Docker Hub 请求，查看命中的规则名称与出站策略。测试时先清除可能造成误判的旧连接，再访问对应服务或拉取一个测试依赖；不同请求可能使用不同域名，单看首页能打开并不能证明注册表或镜像下载也走了预期路线。

把规则从主配置拆出后，维护成本会下降，但远程托管也带来地址可用性、缓存更新与格式校验等新责任。保持域名列表范围明确、更新间隔合理、规则顺序可读，并在提交后用实际连接记录验证路线，才能让自定义规则集长期稳定运行。