Clash自定义规则集进阶配置：rule-providers编写与GitHub托管

为什么要用 rule-providers 管理自定义规则？ 详解

当配置文件里只有几条个人规则时，直接把 DOMAIN-SUFFIX 或 IP-CIDR 写进 rules 最直观。但规则逐渐累积后，主配置会越来越长：临时测试项、应用分流和长期维护的域名清单混在一起，既难审阅，也容易在订阅更新或手动调整时误删。rule-providers 的作用，是把一组规则独立成可加载、可更新的规则集，再由主配置中的 RULE-SET 引用。这样主配置负责决定匹配顺序与策略，规则集负责维护具体条目。

需要先分清两个层次：规则集文件本身只描述「哪些目标属于这一组」，并不决定这些流量最终走代理还是直连。实际策略由 rules 中引用该规则集时指定，例如 RULE-SET,work-sites,PROXY。因此，规则集可以单独复用在不同配置里，而同一个规则集也能在不同设备上指向不同策略组。排障时要分别检查「规则集有没有成功加载」和「加载后命中了哪条规则」，不能只看到客户端显示已更新，就认定分流结果一定正确。

下文以 Mihomo 常见配置为例。不同客户端的按钮名称和配置覆写方式可能不同，但底层字段仍取决于实际运行的内核版本。较旧的 Clash 内核可能不认识较新的字段或规则集格式；导入配置前应确认客户端使用 Mihomo，或核对该内核对应版本的文档。不要仅凭配置编辑器能保存 YAML，就推断运行时也支持其中的语法。

先看最终配置：部分客户端会把订阅、覆写和本地补丁合并后再交给内核。若界面中的文件与运行时配置不同，应以客户端生成的最终配置和连接日志为准；直接修改订阅原文，也可能在下次更新时被覆盖。

rule-providers 字段怎么写：类型、行为与文件格式 全面解析

在 Mihomo 配置中，rule-providers 是一个映射表，每个提供者使用自定义名称作为键。下面的示例创建一个托管在 GitHub 上的域名规则集，文件路径和仓库名称仅作示范，实际使用时要替换为自己仓库中确实存在的地址：

rule-providers:
  work-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/example-user/clash-rules/v1.0/work-sites.yaml"
    path: ./rule-providers/work-sites.yaml
    interval: 86400

rules:
  - RULE-SET,work-sites,PROXY
  - MATCH,DIRECT

type: http 表示由内核通过 HTTP(S) 获取规则文件；behavior 声明规则集的语义，常见值为 domain、ipcidr 和 classical。它们不是可以互换的标签：域名集用于域名类规则，IP 集用于网段匹配，classical 则适合放置多种规则类型的传统规则列表。把域名规则声明成 ipcidr，或把一组混合规则声明成不匹配的行为类型，可能导致配置校验失败或规则无法按预期匹配。

format 表示规则文件的序列化格式。使用 yaml 时，文件通常包含 payload 列表，例如域名规则集可以写成：

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,login.example.net
  - DOMAIN-KEYWORD,workportal

若选用 text，则按照对应内核支持的文本规则格式逐行编写，不要再套一层 YAML 的 payload 结构。不同 behavior 对允许的规则内容有约束；规则文件格式、行为类型和实际条目必须彼此匹配。维护前可先只放一条规则，通过配置校验和连接日志确认加载成功，再逐步扩充，避免一次引入大量条目后难以定位问题。

path 是本地缓存或下载文件的保存位置，不是 GitHub 上的 URL。建议集中放在独立目录，并给文件起稳定、易辨认的名称。客户端若使用订阅配置的临时目录或只读目录，手工指定路径可能导致写入失败；应按客户端文档确认最终配置所在位置及其对相对路径的解析方式。迁移设备时，也别假设相对路径一定相对于当前工作目录，最好通过客户端配置目录和运行日志核实。

字段 用途 配置时要核对
type 指定规则集的获取方式 远程托管常用 http；确认内核支持该类型
behavior 声明规则集内容属于哪类匹配规则 内容要与 domain、ipcidr 或 classical 对应
format 说明文件是 YAML 还是文本格式 YAML 通常有 payload；文本文件不要额外套 YAML 结构
url 规则源的远程地址 检查地址可访问、文件路径和分支或版本名正确
path 下载文件在本机的保存位置 确认目录可写，并确认客户端如何解析相对路径
interval 远程规则的更新间隔，单位为秒 按实际变更频率设置，不要误当成每次启动都立即更新

RULE-SET 匹配顺序：为什么规则写对了仍然没走对策略 一次讲透

Clash 系配置按 rules 列表从上到下匹配，通常在命中第一条适用规则后就决定目标策略。因此，规则集已经成功下载，不代表它必然有机会生效：如果它前面已有更宽泛的规则先命中，请求就不会继续检查后面的 RULE-SET。例如，把某个工作域名集放在通用的国内直连规则之后，域名如果先被前面的规则覆盖，后面的策略就不会起作用。

实际整理时，可以把需要优先处理的自定义规则放在兜底规则之前，再依照配置的整体结构安排广告、地区规则、局域网和最终匹配项。具体位置要结合现有规则逐条判断，不建议把任何网上抄来的排序模板不加检查地插入订阅。MATCH 通常是兜底项，应位于列表末尾；若它前面已经有兜底规则，排在它后面的规则一般也就没有匹配机会。

还要注意，规则集命名和策略名称是两个概念：work-sites 是 rule-providers 下的键，PROXY 是实际存在的策略组或策略名称。RULE-SET 引用的名称必须和键完全一致，策略也必须能在当前配置里解析。采用大小写或连字符不一致的名称，或者引用了订阅中不存在的策略，都会让配置校验报错或造成预期外的回退。

先小范围验证：添加规则集后，选一个你能明确识别的测试域名访问，在连接列表中查看目标域名、命中规则和最终策略。比起只看配置页面里有没有红色报错，这种验证能同时确认规则已加载、排序有效且策略组可用。

把规则集托管到 GitHub：稳定链接与版本管理 深入理解

GitHub 适合保存可审阅、可回滚的规则文本，但仓库地址的选择会直接影响更新稳定性。使用 raw.githubusercontent.com 提供的文件链接时，应该核对用户名、仓库名、分支或标签以及文件路径；文件移动、仓库改名、分支重命名，都会让远程地址失效。公开仓库中的规则对所有人可见，不要把订阅链接、访问令牌、内网域名清单等敏感信息写入公开文件，也不要把包含凭据的 URL 填入配置。

直接引用可变的主分支路径，配置最省事，但每次提交都可能改变客户端下一次获取到的内容。对于希望可审计的个人或团队配置，更稳妥的做法是用 Git 标签或固定提交版本提供文件，并在确认内容后再升级引用版本。这样能够复现某一次配置的行为，出现意外变化时也比较容易回退。采用固定版本后，更新规则就需要主动修改 URL 或版本引用；这属于稳定性与自动追新之间的取舍，而不是配置错误。

interval 以秒计，适合设置为与规则变化频率相符的周期。更新间隔设得很短，不代表 GitHub 上的内容一定立刻可见，也可能增加远程请求；设得过长，则新修正规则要等更久才会同步。初次排障时，可在客户端提供的规则集管理界面手动更新，或重载配置，再查看内核日志中的请求结果。需要记住，定时更新只影响远程文件的获取频率，不会自动修复错误的 URL、格式或匹配顺序。

建议把规则仓库按用途拆分，而不是把所有例外都塞进一个不断膨胀的文件。每个规则集保持单一职责，提交信息写明改动原因，并在合并前检查新增规则是否重复、是否误覆盖其他服务，以及删除规则是否仍有使用场景。对于需要多人维护的仓库，可以通过 Pull Request 留下审核记录；对个人仓库，也可以利用 Git 历史查看某条域名何时加入、为什么调整。规则集越容易审阅，出现异常时越不需要靠猜测回滚。

常见加载错误与可复现的排查顺序 详解

排查时先区分「配置解析失败」「远程获取失败」「文件格式不符」和「匹配顺序不符合预期」。这几类问题的表象都可能是规则没有按预期工作，但修复位置完全不同。不要一上来同时改 URL、路径、行为类型和规则顺序，否则即使问题消失，也很难确认真正原因。

现象 优先检查 处理方法
配置保存或载入时报字段错误 内核版本、缩进、字段名称 用当前 Mihomo 版本支持的字段，并检查 YAML 缩进与冒号
规则集请求失败或下载超时 远程 URL、网络连通性、TLS 与仓库可见性 在浏览器验证文件地址，并确认客户端运行环境能访问该地址
文件下载成功但解析失败 format、behavior 与文件内容 核对 YAML 是否有正确的 payload，并确认条目符合行为类型
日志显示规则集已加载但策略不对 rules 的顺序、规则名称、策略名称 检查是否被更靠前的规则先匹配，并在连接详情中确认命中项
手动修改后重启又恢复旧内容 客户端订阅更新、覆写层与缓存文件路径 确认修改的是实际生效的文件，并将持久化改动放到正确的覆写位置

一个实用的最小排查流程是先单独验证 URL 能否返回预期规则文件，再检查客户端日志是否报告下载成功；接着确认本地路径可写、文件格式和行为类型相符；最后用一条可识别的测试规则核对 RULE-SET 是否位于有效位置。若通过 GitHub 网页能打开仓库文件，但原始文件地址返回 404，通常是 URL 路径、分支名或大小写不正确。若地址返回的不是规则文本，而是 GitHub 的错误页面或访问限制提示，内核也无法把它当作有效规则集解析。

定期清理失效域名和重复规则，并记录规则集对应的用途、来源与最后验证时间。对团队配置而言，这些说明最好放在仓库的 README 或提交记录中，而不是写成内核不认识的 YAML 字段。遇到更新失败时，先保留上一份已验证的本地规则文件和可回退的 Git 版本，再逐项检查日志；这样既能恢复可用配置，也能避免为了追一个加载错误而把整份订阅改乱。

与把规则散落在多个客户端配置、靠手工复制粘贴维护相比，GitHub 规则集更便于查看差异、追踪修改和复用，不过也要求你认真管理仓库地址、版本和规则顺序。Clash 将 Clash 客户端相关的下载入口与配置教程集中整理，方便你在核对内核兼容性、导入配置和排查规则时找到对应资料；如果你也想把客户端选择和配置维护流程放在一起，不妨前往下载，再按本文的步骤逐项验证自己的规则集。