分流规则怎么工作：模式、策略组与 DNS

已经选了节点，某个网站却仍然直连，先看看这次请求命中了哪个策略组。分流决定进入客户端的流量从哪里出去，节点选择只是其中一步。

规则、全局与直连模式

流量进入客户端后，模式决定怎样选择出站。这里按常见 mihomo 客户端解释规则、全局和直连；其他内核的菜单名称与行为应对照自己的文档。

常见客户端模式与实际作用
模式	主要行为	需要确认
规则	根据域名、地址、应用等条件选择对应出站或策略。	规则顺序、匹配条件、策略组选择与兜底。
全局	通常使用 GLOBAL 全局策略处理进入核心的业务连接。	GLOBAL 最终选了节点、其他策略还是直连。
直连	进入核心的业务连接直接访问目标。	接入和 DNS 设置是否仍在运行，不能等同于退出程序。

选择全局不自动让所有应用使用客户端，选直连也不一定关闭本地入口或虚拟接口。解释一条请求时，需要先知道它是否进入核心，再看模式怎样选择。

选择节点只影响对应策略组。网站命中了另一个组时，会沿那个组的当前选择出站，界面里选中的节点未必是这次请求使用的节点。

例如你在“常用节点”组选择了节点 A，但浏览器域名命中“工作网站”组，该组仍选择直连，浏览器就不会使用 A。全局模式也需要检查 GLOBAL；它指向直连时，界面中另一个组的节点选择不会替它生效。

查看连接详情时，从命中规则追到策略组，再追到最终节点，避免只看名称是否含“代理”。自动选择组则会依据自己的测试条件切换，测试目标、结果过期和可用节点列表都可能影响选择。Clash Mi 指南包含 GLOBAL 与面板的具体核对方法。

常见规则列表从前往后匹配，先命中的规则可能决定去向。把精确条件放在合适位置，最后安排兜底，能更容易解释一个目标为什么走了这条路径。

以概念上的列表为例：先匹配内部服务并直连，再匹配指定网站并交给某个策略组，最后使用默认出站。若把“所有请求都直连”的兜底提前放到可命中位置，前面的设计意图就可能被覆盖。

具体内核还可能有逻辑规则、动作、子规则或重新匹配机制。不要凭“规则越多越准确”堆叠配置；每加一条规则，选择一个具体目标检查命中结果。客户端覆写、订阅更新与规则集更新也可能改变最终列表，必要时查看运行中的配置，而不是只读原始文件。

域名解析成功后，应用可能把域名交给入口，也可能只提交解析后的 IP。内核拿到的信息不同，域名规则的匹配结果也可能不同。

DNS 请求本身还可以采用独立路径：浏览器的 DoH、系统解析器与客户端解析器可能各自工作。业务连接走了一个节点，不代表解析查询一定走同一节点。反过来，DNS 通过远端完成，也不证明业务请求没有直连。

Fake-IP、嗅探或 DNS 接管能帮助某些内核关联域名与连接，但有各自条件和兼容限制，不应把启用它们等同于没有泄露。先核对具体域名在日志中的呈现、实际解析器与命中规则，再修改配置。关于记录、缓存和加密查询，可继续读 DNS 解析说明。

TUN 让被路由的流量进入客户端，分流再为它选择出站。路由排除、分应用设置和 IPv4/IPv6 范围，需要与规则一起检查。

路由排除、分应用设置、局域网例外和系统平台限制，都可能让请求采用不同路径。客户端为避免连接回环，也需要让自己的某些连接按适当方式出去。检查时要解释是哪条业务流量、哪个应用和哪种地址族，而不是只数开关是否开启。

系统代理则依赖应用读取相应设置，不会被全局模式替代。代理与 VPN 的区别解释手机系统接口与客户端转发的区别；sing-box 指南则可用本机入口实验理解“接收请求”与“选择出站”。

先列出哪些请求应该代理、哪些应该直连。检查时把预期和连接记录对照，才能分清主动直连与意外绕过。

出口查询、DNS 和 UDP 可能采用不同路径。配置更新或切换网络后，重新检查重要应用，尤其是原先要求经过远端的请求。

选一个出问题的目标，记录当前模式和策略组，再重新发起连接。沿请求是否出现、域名是否可见、命中规则和最终出站依次往下看。

保存同一请求修改前后的结果，更新订阅后再检查关键规则。若出站正确但目标仍失败，接着看网络分层排查。

为什么选了节点 A，面板却显示另一节点？

请求可能命中不同策略组，或该组由自动选择和嵌套策略决定最终节点。沿命中规则、策略组、最终出站逐层核对。

配置文件更新后，为什么分流行为变化了？

规则集、订阅原文、应用覆写或策略组选择可能变化。查看实际加载配置，比较变更前后同一个请求，而不是仅比较节点数量。

原理和协议定义可查以下标准与官方文档。文中的流程图由 AFQKit 绘制。