分流规则误命中？域名后缀、关键词与顺序怎么选

域名分流走错出口，先看三件事：规则写的是完整域名、后缀还是关键词，最终列表里哪一条排在前面，以及这次连接实际提供了什么目标信息。反复切换机场节点，通常不能修正匹配范围写错的问题。

作者：小六｜资料核对日期：2026年10月17日

本文以使用 Mihomo 内核的客户端为例，讨论已经进入客户端、准备按规则处理的新连接。其他内核的语法和匹配方式需要另查对应文档。

先把域名从完整网址里分出来

假设页面地址是 https://files.example.com/docs/start?lang=zh，这里要核对的域名是 files.example.com，不包含协议、路径和查询参数。示例地址只用于解释格式，不是推荐访问的服务。

把整串网址填进普通域名规则，或者把 /docs/ 当作域名的一部分，都会让排查方向跑偏。MDN 的 hostname 说明展示了主机名与完整 URL 的区别。

还要确认失败的是哪个请求。首页、图片、登录和下载可能使用不同域名；地址栏显示的名字，不一定就是失败请求的目标。

下面都用 example.com 一类示意名称解释，实际配置应按自己的目标填写。

规则类型	匹配内容示例	覆盖范围
`DOMAIN`	`example.com`	只匹配这个完整域名
`DOMAIN-SUFFIX`	`example.com`	匹配它本身，以及 `files.example.com` 等子域名
`DOMAIN-KEYWORD`	`example`	匹配域名中包含这段文字的目标，范围可能更宽

例如，后缀 example.com 不会因为名字相似，就匹配 other-example.com；关键词 example 却可能匹配后者。相关定义见 Mihomo 路由规则文档。

只需要调整一个明确入口时，先考虑完整域名。确认一组子域名确实都要采用相同策略，再考虑后缀。关键词适合你确实需要的文字范围，不宜仅因为写起来短就采用。

后缀匹配处理的是域名层级，不能识别网站属于谁。一个服务可能把资源放在另一个域名下，也可能使用公共托管域名。不要为了补齐一个下载请求，就把整个公共后缀或一大批无关站点都改走同一个出口。

Mihomo 从上向下检查规则，不会自动把你写得更具体的那一行提到最前。下面是一个 TCP 连接的示意片段，假设配置中已经有“常用节点”策略组：

rules:
  - DOMAIN,files.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,常用节点
  - MATCH,DIRECT

这表示先为文件子域保留一个直连例外，再处理该后缀的其他域名，最后处理剩余目标。如果把后缀规则移到第一行，文件子域就可能先被它接住；放在兜底 MATCH 后面的普通例外，也无法按预期覆盖前面的结果。

这里解释的是顺序，不是要求所有人采用这套出口。官方文档还说明，UDP 请求遇到不支持 UDP 的代理时可能继续向下匹配，不能把所有场景简化成一句“看到第一条就结束”。

不要把示例直接覆盖整份规则，也不要新增第二个顶层 rules。个人规则的保存位置，可以参考本站自定义规则覆写与备份方法。

先确认运行模式。Mihomo 的规则、全局和直连模式作用不同，见官方运行模式说明。测试域名规则时，应确认当前确实在使用规则模式，以及编辑内容已经成为生效配置。

再看对应新连接的记录。按客户端能提供的信息，核对目标域名、命中规则、策略组和最终节点。没有对应连接时，先查应用的代理入口；命中规则正确而节点不同，则应继续看策略组的实际选择。

如果记录只有 IP，不能仅凭这一项就认定域名规则一定写错。需要核对内核获得了哪些域名信息、DNS 处理方式，以及客户端是否只显示部分字段。

Mihomo 提供域名嗅探选项，但它有协议、端口和排除等条件，不能保证为任意连接还原域名。先保存现状并检查对应条件，不要把开启全部嗅探当成通用答案。

验证通过后，再补查同一页面的其他必要请求。这样既能发现遗漏的资源域名，也能避免为了一个小问题扩大分流范围。

普通 DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD 匹配的是域名，不负责区分网页路径。若目标只是同站点的不同页面，继续增加这三类规则并不能实现按路径选择。

想交流规则误命中，可以提供脱敏后的目标域名、相关规则顺序和实际出口，不需要发送完整订阅：Telegram 联系我