Karing规则分流没有按预期生效？理解域名匹配、规则顺序与最终兜底

精确匹配与后缀匹配的范围不同

在Mihomo常见规则语法中，DOMAIN匹配完整域名，DOMAIN-SUFFIX匹配域名本身及其子域。比如docs.example.com既符合针对自身的精确规则，也符合example.com后缀规则。哪个生效，还取决于规则引擎与排列。

IP-CIDR根据地址网段判断；GEOIP依赖相应IP数据；GEOSITE属于域名分类数据的概念。数据来源、版本和实现支持范围都需要单独确认。规则分流指南将匹配条件与出站目标分开整理，便于逐项检查。

在首次命中的系统里，把例外放在宽泛规则前

Mihomo路由规则按自上而下的顺序匹配，通常将更具体的例外放在宽泛规则前。下面的片段仅演示这一体系，不能推断所有规则引擎都采用完全一样的处理机制，也不代表Karing的内置规则顺序。

rules:
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,demo-select
  - IP-CIDR,192.0.2.0/24,REJECT
  - MATCH,demo-select

DIRECT表示直连，REJECT表示拒绝；demo-select是演示策略组名，必须另行定义。这里的默认兜底放在末尾，否则可能提前承接流量，导致后续规则没有机会参与选择。

规则命中之后，还要核对目标对象

规则选中的策略组应当真实存在，组内还需要有有效成员。规则命中了正确的组，但组里的当前选择变化，也可能改变最终连接。因此应把命中规则、目标组、实际出站作为连续的检查链。可结合节点组与线路选择确认引用。

Clash生态的MATCH与sing-box的route.final都能涉及默认路径，但二者不是同一段配置语法。sing-box还存在随版本变化的规则动作结构。具体引用方式可见sing-box出站标签与选择器，不要把一行Clash规则直接粘贴进JSON数组。

保留原配置，用非敏感目标验证

1. 先备份当前规则，记下希望例外处理的目标和预期策略。
2. 使用example.com等文档保留域名做逻辑推演，不包含真实账号或节点信息。
3. 检查访问时是否具备域名信息；IP规则可能涉及解析及no-resolve等实现选项。
4. 在应用提供的日志中核对实际命中规则、组和出站，分享前脱敏。
5. 每次只调整一个有依据的条件，再确认普通访问没有受到过宽规则影响。

演示域名用于理解逻辑，并不保证提供某项实际服务。不要一次删除全部已有规则；宽泛拒绝或代理规则可能影响正常访问。若规则、组引用和连接分别记录，恢复与比较就更有依据。