Clash规则集合读不对怎么核对：behavior、format与三份内容小样

· Clash相关客户端的Mihomo规则集合 使用指南

分别阅读Mihomo规则集合的内容类型与文件形式，用domain的YAML和纯文本、classical条件列表对照，解释mrs组合限制与三种常见错配。

一份文件可以是合法YAML，却仍然不是当前规则集合需要的内容。看到客户端提示集合读取异常时，除了检查缩进，还要把rule-providers里的behavior和format拆开看：前者决定里面放哪类条件，后者决定这些条件以什么形式存放。把这两个问题混成“都是规则文件”，往往会在错误的一层反复修改。

内容类型与文件形式两项分别配对的原创规则集合封面
同样的内容可以采用不同文件形式；文件形式相同，也可以装着不同类型的条件。

先认清是规则集合，还是代理集合

Mihomo文档里的rule-providers用于规则集合，proxy-providers用于代理集合。前者的内容参与判断条件，后者提供代理来源。遇到一个下载来的文件，先看实际使用它的字段和文件说明，不凭文件名里有“订阅”“列表”就判断用途。把代理来源放进规则集合，无法通过调整几个空格变成合适的条件列表。

本文针对明确采用Mihomo内核的客户端。先在当前客户端查看内核名称与版本，再用对应文档核对；其他实现和外壳界面可能有自己的支持范围。下面的短片段都用于阅读内容差别，省略完整配置、集合路径、引用和出站安排，不用于覆盖现有文件，也不需要连接任何示例地址。

behavior回答“里面是什么条件”

当前维护者文档列出domain、ipcidr和classical三种行为。domain接收域名类内容，ipcidr接收地址段内容，classical接收带规则类型的条件。可以把它们理解为三种不同的条目格式，而不是三个随意挑选的性能档位。想处理域名时，不应因为另一个教程用了ipcidr，就把自己的字段改过去。

先从最简单的精确域名内容开始。假定一份YAML集合只保存两个示例名字，它的内容可写成下面这样。注意每个条目是名字本身，没有在前面补DOMAIN字段，也没有在末尾指定DIRECT或其他处理方向：

payload:
  - 'guide.example.net'
  - 'assets.example.net'

与之对应的是domain行为。阅读时先说出“两个域名条目”，再核对集合声明。若你准备保存的是IP地址段，就应另看ipcidr内容要求，不把数字地址当作普通域名混入这份练习。若想使用通配表达，还要遵守该集合对应的通配规则，本文两个精确名字没有演示通配范围。

format回答“这些条件怎样装进文件”

同样两个名字，以text形式保存时，直接按行排列，内容如下。它与上一份YAML有相同的练习对象，却没有payload这个外层键和列表前缀。format应与实际内容一致，改扩展名并不会替你完成内容结构转换：

guide.example.net
assets.example.net

所以一份名为lesson.txt的文件，实际可能仍装着YAML；一份名为lesson.yaml的文件，也可能只是网页下载失败后的提示页。拿到文件时先看内容和来源提供的格式说明，再与当前生效配置的声明对照。只在资源管理器里重命名后缀，原本的字节和条目写法都没有跟着改变。

维护者文档还列出mrs形式，当前仅支持domain和ipcidr行为，不能把classical与mrs随意配在一起。MRS需要按支持的转换方式生成，不能把上面的纯文本改个文件名就当成MRS。若来源只提供classical文本，先保留它真实的类型和形式，不为了统一文件后缀破坏原意。

domain和ipcidr支持三种形式而classical不配mrs的原创矩阵图
矩阵说明当前文档中的组合关系；选择有效组合以后，文件内的具体条目仍要符合所选行为。

classical里的条件行，与完整路由行不同

如果条目需要写规则类型，可另用classical内容。下面第一项是一个完整域名条件，第二项是目标端口条件；两行放在YAML的payload列表里。它们没有把最终出站方向写在每一项后面：

payload:
  - 'DOMAIN,guide.example.net'
  - 'DST-PORT,8443'

把第一份domain内容直接搬来，再把behavior改为classical，漏掉条目需要的规则类型，就没有表达相同的结构；反过来，把这份带DOMAIN前缀的内容塞入domain集合，也不符合原本的条目形式。选择behavior时，需要同时看声明和文件里的每一项，而不是只改主配置里一个词。

引用集合时，主路由规则可以通过RULE-SET写集合名称及处理方向。例如单独的示意行RULE-SET,lesson-conditions,DIRECT，其中lesson-conditions指向相应集合；这与在集合每个条件后再加DIRECT是两种位置。文档说明classical支持路由条件类型，但排除RULE-SET和SUB-RULE，不能把完整路由列表不加检查地当作classical内容。

这种分开保存的方式，能让维护者分别检查“哪些对象属于这一类”和“这一类应怎样处理”。交接一份条件清单时，先说明里面记录了什么；需要改变处理方向，则查看使用该集合的位置。若在集合条目后随手追加结果词，另一位维护者会难以判断这是来源内容发生变化，还是误把主路由行粘了进去。整理时保留两处各自的用途，后续更换文件形式也不必重新猜测每行原意。

最后做一道反向阅读题：若要求把上面的两个域名从YAML形式整理为纯文本，变化的是去掉外层结构、按行保存名字；目标名字仍然相同，行为也不因此变成classical。能说清哪些内容保留、哪些结构改变，才算读懂了这次转换，而不是只记住一个新的文件后缀。

三份待交接材料，怎样判断该问谁

看到的材料先核对的对象有用的下一句提问
声明domain，条目却是DOMAIN,名字行为与条目写法来源究竟提供domain还是classical内容？
声明text，文件仍有payload外层文件形式与实际结构这次下载的是YAML版还是纯文本版？
声明classical与mrs当前文档允许的组合能否保留来源提供的yaml或text形式？

对第一种情况，先读来源说明，再决定是换正确的资源，还是由维护者按真实内容调整行为。不要只删逗号把一份复杂条件表强行凑成域名列表，其中可能还包含端口或地址段条件。第二种情况要解决容器结构，没必要改变条目想表达的对象。第三种情况要先解决组合支持，再检查具体内容；继续改缩进不能使不支持的组合获得支持。

准备交接时，用集合代号、behavior、format、文件前几行以及错误类别就能表达这类问题。完整配置或请求头可能有凭据，通常无需一起发送。拿不到资源内容时，就明确缺少这项证据，请提供方确认格式，不依据链接的结尾猜测已经下载了正确文件。

读取成功之后，才进入规则使用检查

将核对顺序写清楚，处理会更集中：先确认资源是所需文件，再确认文件形式和行为对应，随后确认集合内容被接受，最后才看主路由如何引用它。如果错误是文本层级无法解析，转到本站YAML缩进、符号和重复键练习；如果集合已经可读，却总被更早的规则处理，再看规则顺序与首个命中的阅读例题。两个阶段分别处理，不在一次试改中同时移动规则、换来源和改格式。

一个明确的完成记录可以写：“lesson资源说明为domain/YAML；声明与内容一致；之前将其标为text，现已在获准副本中修正；记录集合是否被接受；实际请求判断留给后续检查。”按自己的真实观察填写最后两项，若只做过纸上阅读，就停在“配对关系已核对”，不补写不存在的加载结果。

域名网络卡与文本条卡分别放在档案袋旁的原创静物图
把内容样本与文件说明一起保存，后续更换资源时才有完整的配对依据。

本文于2026年10月29日核对维护者的规则集合字段说明、规则集合内容示例以及路由规则说明。文件片段、条件名称和配图为教学材料，没有导入真实配置或执行连接测试。它们用于理解格式与内容，具体部署应由有权限的维护者结合当前内核处理。