什么是 Clash rule-providers

在 Clash 或 Mihomo 配置中，rule-providers 用来把一组规则从主配置文件中拆分出来，作为可以单独更新、复用和维护的规则集。主配置只负责定义代理组、DNS、基础运行参数以及规则集之间的调用关系，具体的域名、IP 或进程规则则放在独立的 YAML 文件中。对于只有少量规则的个人配置，直接把规则写在 rules 下面也可以；但当你需要同时维护广告拦截、流媒体、AI 服务、开发平台和局域网地址时，继续把所有内容堆在一个文件里，很快就会变得难以检查。

rule-providers 的核心价值不只是「少写几行规则」，而是把规则内容与策略逻辑分离。比如，多个策略组都可以引用同一份代理规则，电脑、手机和路由器也可以共享一份托管在 GitHub 上的规则文件。规则文件更新后，客户端按照配置的行为重新拉取，不需要每次手动打开主配置复制粘贴。这样既能降低 YAML 缩进错误，也方便通过 Git 记录每次修改，出现问题时可以快速回退到上一个可用版本。

需要注意的是，rule-providers 通常由较新的 Clash Meta、Mihomo 及其图形客户端支持。不同客户端对字段名称、缓存目录、更新按钮和错误提示的呈现方式可能不同，因此本文使用兼容性较好的写法说明思路。若你的客户端基于较旧的 Clash 内核，导入后出现未知字段或规则集无法加载，应先查看内核版本，而不是直接判断 YAML 内容错误。

先理解类型与关键字段

一个规则提供者通常至少需要定义 type、behavior、url 和 path。其中，type 表示规则文件的来源方式，常见值是 http 和 file；behavior 表示文件内容属于域名类、IP 类还是经典规则类；url 指向远程文件；path 则是客户端保存缓存文件的位置。对于远程规则，通常还会配置 interval，用于指定自动更新间隔。

字段	常见值	用途与注意事项
`type`	`http`、`file`	`http` 用于远程托管规则，`file` 用于本地文件。
`behavior`	`domain`、`ipcidr`、`classical`	必须与规则文件实际格式匹配，否则可能下载成功但解析失败。
`url`	HTTPS 地址	建议使用稳定、可公开访问的地址，避免使用带短期令牌的临时链接。
`path`	本地 YAML 路径	不同客户端的配置目录不同，使用相对路径通常更便于迁移。
`interval`	86400、604800	单位为秒。规则不会因为设置了间隔就立刻更新，首次仍需成功下载。
`format`	`yaml`、`text`	部分 Mihomo 环境支持显式声明格式，旧内核不一定识别此字段。

behavior 是最容易被忽略的字段。domain 适合每行一个域名或域名后缀的规则，例如 DOMAIN-SUFFIX,example.com 这类规则通常不应直接声明为纯域名列表，除非托管文件本身就是对应的 domain-provider 格式。ipcidr 适合 IP 段和网段，classical 则适合完整的传统 Clash 规则行，例如 DOMAIN-KEYWORD,video、GEOIP,CN 或 PROCESS-NAME,chrome.exe。

不要只看文件扩展名判断格式。

一个名为 rules.yaml 的文件，可能实际包含完整的 classical 规则行，也可能只是简单的域名列表。确认方式是打开文件查看内容，并让 behavior 与内容结构一致。若客户端日志提示 provider 解析失败，优先检查这一项。

下面是一份适合多数 Mihomo 环境改造的基础示例。它把不同类型的规则拆成独立提供者，并为每个 provider 指定清晰的缓存文件名。实际使用时，应替换为你确认可信的 GitHub Raw 地址，不要直接复制陌生仓库中的全部配置。

rule-providers:
  streaming:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/example-user/clash-rules/main/streaming.yaml
    path: ./providers/streaming.yaml
    interval: 86400

  private:
    type: http
    behavior: domain
    url: https://raw.githubusercontent.com/example-user/clash-rules/main/private.yaml
    path: ./providers/private.yaml
    interval: 604800

  local-net:
    type: file
    behavior: classical
    path: ./providers/local-net.yaml

用 GitHub 托管规则集的正确方式

GitHub 适合托管公开、可审计、更新频率稳定的规则文件。建议为规则集建立一个独立仓库，例如按用途划分为 streaming.yaml、ai.yaml、developer.yaml 和 lan.yaml。不要把订阅链接、节点密码、访问令牌或个人隐私域名提交到公开仓库；rule-providers 只应包含规则内容，代理节点仍然放在私有配置或受信任的订阅中。

最简单的发布方式是把文件提交到仓库的默认分支，再使用对应文件的 Raw 地址。网页地址和 Raw 地址不是一回事：浏览器页面地址通常以 github.com 开头，Clash 下载规则时应使用可直接返回文件内容的 raw.githubusercontent.com 地址。复制链接后，最好在浏览器的隐私窗口中打开测试，确认页面显示的是纯 YAML 文本，而不是 GitHub 登录页、错误页或 HTML 页面。

GitHub 规则集发布清单

创建规则仓库，并在 README 中写清楚每个文件的用途、格式和更新记录。
按功能拆分文件，文件名使用小写英文和短横线，避免空格及特殊字符。
提交前使用 YAML 校验工具检查缩进、冒号、列表和字符串引号。
打开文件的 Raw 地址，确认返回内容与本地文件一致。
在 Clash 中先手动更新 provider，再观察日志是否出现下载和解析成功信息。
确认规则命中后，再把更新间隔设置为每天或每周，避免频繁请求 GitHub。

Git 分支和提交记录对规则维护尤其有价值。建议不要直接在主分支上大规模修改，可以先创建一个测试分支，完成语法校验和实际访问测试后再合并。每次提交信息应说明变更范围，例如「添加某平台域名」「移除失效 CDN」「修正 AI 服务规则」，不要只写「update」。当新规则导致国内站点误走代理时，可以通过提交历史定位变化，再使用回滚或恢复文件的方式快速恢复服务。

如果规则仓库由多人维护，最好规定一套格式：每行一条规则、统一使用大写规则类型、按域名或用途排序、删除重复项，并在文件开头用注释说明来源和最后审核日期。GitHub 的自动化流程还可以用于定期检查 YAML 语法、检测重复域名和生成变更报告。不过，自动更新第三方列表时要保留人工审核环节，不能因为文件能下载就默认规则安全可靠。

关于分支与链接的提示

生产环境建议固定使用经过审核的默认分支或版本标签，不要把客户端直接指向个人测试分支。若使用 GitHub 的版本发布地址，确认链接是否会长期稳定；对于频繁变化的规则，Raw 默认分支更方便，对于需要严格可复现的环境，则可以锁定特定提交或 Release 文件。

在 rules 中调用 provider 与控制优先级

定义 rule-provider 只是准备数据，真正决定流量如何处理的是 rules 区域。调用格式通常是 RULE-SET,provider-name,策略组。其中 provider 名称必须与前面定义的键完全一致，大小写和连字符都不能写错。规则匹配通常遵循从上到下的顺序，第一条命中的规则会决定后续动作，因此「更具体的规则在前、更宽泛的规则在后」是最重要的原则。

rules:
  - RULE-SET,local-net,DIRECT
  - RULE-SET,private,DIRECT
  - RULE-SET,ai,AI
  - RULE-SET,streaming,Streaming
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

这段配置中，局域网和私有地址位于最前面，防止 NAS、打印机、路由器管理页面被错误送进代理；AI 和流媒体规则放在国内地理规则之前，避免它们的域名或解析地址被 GEOIP,CN 提前判定为直连；最后的 MATCH 负责接住所有没有命中的流量。若把 MATCH,DIRECT 放在 provider 规则之前，后面的规则就几乎没有机会生效，这是排查「规则集导入成功但流量不按预期走」时最常见的错误之一。

规则优先级还会受到 DNS 模式、fake-ip、TUN 和客户端内核实现的影响。域名规则通常需要在请求仍保留域名信息时才能准确匹配；某些应用直接访问 IP，或者使用自建 DNS、QUIC、DoH 绕过系统代理时，单纯增加 domain provider 并不能解决问题。遇到命中异常时，应在连接日志中查看请求的原始域名、匹配到的规则类型、最终策略组和实际出站节点，而不是只看配置文件有没有红色报错。

场景	推荐顺序	原因
局域网设备	LAN provider → 私有地址 → 其他规则	避免管理页面、NAS 和打印机走代理。
指定应用或服务	应用专用 provider → 通用域名规则	让更具体的目标优先命中对应策略组。
国内直连	自定义例外 → GEOIP / GEOSITE → MATCH	先处理例外，再使用范围更大的地理规则。
兜底流量	MATCH 放在最后	保证没有被其他规则匹配的请求仍有明确出口。

对大型配置而言，建议为每个 provider 使用语义明确的策略组，而不是所有规则都指向同一个「Proxy」。例如，流媒体规则可以指向按地区选择的策略组，开发平台可以指向稳定性优先的节点组，AI 服务则可以单独设置故障转移。这样做虽然增加了少量配置项，却能让规则集的维护目标更加清晰，也方便在 GUI 中观察每一类流量的实际出口。

更新失败、规则不生效时如何排查

rule-providers 的问题通常可以分为下载失败、格式解析失败、规则未命中和策略组行为异常四类。排查时不要一次修改多个部分，否则即使问题消失，也很难知道真正起作用的是哪一项。建议先在客户端的配置或规则提供者页面手动点击更新，然后查看日志中的 HTTP 状态码、响应大小和解析结果。一个返回 200 的请求不代表规则可用，因为服务器可能返回了登录页、限流提示或 GitHub 的错误 HTML。

检查地址：确认使用的是 Raw 地址，URL 中没有多余空格、中文字符或失效分支名称。用浏览器打开后，应看到规则文本而不是网页布局。
检查网络：如果 GitHub 在当前网络不可达，provider 会一直使用旧缓存，直到缓存不存在或被清除。可以暂时使用可访问的镜像，但必须评估镜像是否可信以及同步延迟。
检查类型：逐行查看规则内容，判断它是 domain、ipcidr 还是 classical。类型不匹配时，下载可能成功但加载失败。
检查路径：确认 path 所在目录可写，多个 provider 不要共用同一个缓存文件，否则会相互覆盖。
检查名称：比较 rule-providers 中的键与 RULE-SET 调用名称，特别留意下划线、连字符和大小写。
检查顺序：查看 provider 规则是否被前面的 GEOIP、DOMAIN 或其他宽泛规则抢先匹配，确认 MATCH 没有提前出现。

不要通过关闭证书校验来掩盖下载问题。

如果 HTTPS 证书错误，优先检查设备时间、系统证书、网络劫持和托管站点配置。长期启用忽略证书验证会增加被中间人替换规则文件的风险。规则文件一旦被篡改，可能把大量流量导向错误策略，甚至影响隐私和账号安全。

规则缓存也经常造成误判。你已经在 GitHub 修改了文件，但客户端可能仍在使用本地旧版本，尤其是只点击了「重载配置」而没有更新 provider 的情况。正确的验证顺序是：先在浏览器确认远程文件内容，再在客户端手动更新对应 provider，最后重载配置或重启内核。若仍然不生效，可以临时删除该 provider 的缓存文件后重新启动，但删除前应备份配置，并确认客户端不会因此丢失其他设置。

为了降低维护成本，可以给规则集建立一份简单的变更记录，记录新增域名、删除原因、影响的策略组以及测试结果。每次更新后至少测试国内常用站点、目标海外服务、局域网管理页和一个不应代理的应用。对于路由器或多设备部署，先在桌面端验证，再逐步推送到其他设备，避免一次更新让全家网络同时出现故障。

一套可长期维护的工程化流程

适合个人和小型团队的做法，是把主配置、规则提供者和节点订阅分成三个层次。主配置保存稳定的运行参数和策略组；GitHub 仓库存放公开且可审计的规则集；节点订阅由服务商维护，不与自定义规则混在一起。这样更新某个应用的域名时，不必重新生成整份节点配置，也不会因为订阅刷新而覆盖自己的规则逻辑。

在命名方面，provider 键应体现用途，例如 ai-services、streaming-global、lan-direct，避免使用 rule1、new-list 这类过一段时间就无法理解的名称。缓存路径也应保持一致，统一放在 ./providers/ 目录下。规则文件内部尽量使用短注释说明来源，但不要把敏感的订阅信息、用户标识和内部 IP 暴露到公开仓库。

更新频率不宜设置得过短。广告域名或高频变化的列表可以每天更新，稳定的开发平台和局域网规则每周甚至更久更新一次即可。过短的 interval 不会让规则匹配更快，反而可能触发 GitHub 限流、增加启动时等待，并在远程文件临时异常时频繁替换本地缓存。对于追求稳定的环境，应该优先保证版本可追踪，而不是盲目追求「永远最新」。

上线前的最小验证流程

使用 YAML 校验器检查主配置和所有规则文件。
逐个打开 Raw 地址，确认返回内容不是 HTML 错误页。
在测试客户端更新 provider，查看日志中的下载状态与文件大小。
用连接日志验证一条应代理规则、一条应直连规则和一条局域网规则。
确认 MATCH 的最终策略符合预期，再发布到其他设备。
把验证通过的提交号、日期和变更说明写入 Git 提交记录。

与把大量规则直接粘贴进客户端的做法相比，rule-providers 配合 GitHub 托管更适合长期维护：规则可以独立更新，错误可以回滚，多个设备能够复用同一套经过审核的内容。部分简单代理工具虽然上手更快，但通常缺少 provider 缓存、规则优先级可视化或 Git 版本管理能力，遇到分流异常时只能反复重建整份配置。Clash 的优势正在于它把规则、策略组、日志和更新机制放在同一套可检查的配置体系中；如果你希望把多应用分流从临时修改变成可追踪、可复用的工作流，不妨免费下载 Clash，立即体验。