全局、规则、直连分别是什么意思？
它们主要决定流量进入客户端之后怎样选择出站。下面以常见 mihomo 客户端的模式命名解释，其他内核或客户端应核对自己的文档，不能直接照搬菜单名。
| 模式 | 主要行为 | 需要确认 |
|---|---|---|
| 规则 | 根据域名、地址、应用等条件选择对应出站或策略。 | 规则顺序、匹配条件、策略组选择与兜底。 |
| 全局 | 通常使用 GLOBAL 全局策略处理进入核心的业务连接。 | GLOBAL 最终选了节点、其他策略还是直连。 |
| 直连 | 进入核心的业务连接直接访问目标。 | 接入和 DNS 设置是否仍在运行，不能等同于退出程序。 |
选择全局不自动让所有应用使用客户端，选直连也不一定关闭本地入口或虚拟接口。解释一条请求时，需要先知道它是否进入核心，再看模式怎样选择。
我已经选了节点，为什么请求还是直连？
节点选择可能只改变了一个策略组，真正命中的策略却是另一个。策略组是把多个节点、直连或其他策略组织起来的选择入口。规则引用策略组时，最终出站还取决于这个组当前的选择。
例如你在“常用节点”组选择了节点 A，但浏览器域名命中“工作网站”组，该组仍选择直连，浏览器就不会使用 A。全局模式也需要检查 GLOBAL；它指向直连时，界面中另一个组的节点选择不会替它生效。
查看连接详情时，从命中规则追到策略组，再追到最终节点，避免只看名称是否含“代理”。自动选择组则会依据自己的测试条件切换，测试目标、结果过期和可用节点列表都可能影响选择。Clash Mi 指南包含 GLOBAL 与面板的具体核对方法。
规则顺序和兜底为什么会影响同一个网站？
常见规则列表按顺序处理，较早匹配的条件可能决定结果。宽泛规则放在前面时，后面的精确域名规则可能没有机会生效。没有任何具体条件命中时，还要查看兜底选择。
以概念上的列表为例：先匹配内部服务并直连，再匹配指定网站并交给某个策略组，最后使用默认出站。若把“所有请求都直连”的兜底提前放到可命中位置，前面的设计意图就可能被覆盖。
具体内核还可能有逻辑规则、动作、子规则或重新匹配机制。不要凭“规则越多越准确”堆叠配置；每加一条规则，选择一个具体目标检查命中结果。客户端覆写、订阅更新与规则集更新也可能改变最终列表，必要时查看运行中的配置，而不是只读原始文件。
DNS 都解析出来了，为什么域名规则仍不生效？
解析成功只说明得到了记录，不能证明核心看到了用于匹配的域名。应用可能把域名交给代理，也可能先自行解析后只连接 IP；客户端识别请求时掌握的信息不同，规则行为也可能不同。
DNS 请求本身还可以采用独立路径：浏览器的 DoH、系统解析器与客户端解析器可能各自工作。业务连接走了一个节点，不代表解析查询一定走同一节点。反过来，DNS 通过远端完成，也不证明业务请求没有直连。
Fake-IP、嗅探或 DNS 接管能帮助某些内核关联域名与连接，但有各自条件和兼容限制，不应把启用它们等同于没有泄露。先核对具体域名在日志中的呈现、实际解析器与命中规则，再修改配置。关于记录、缓存和加密查询，可继续读 DNS 问答。
开了 TUN，为什么还需要规则和接入范围？
TUN 负责让流量进入处理路径，规则负责选择进入之后的出站。两者作用不同。TUN 可以通过虚拟接口接收网络包，但不自动保证所有目的地址、IPv4/IPv6 和所有应用都被覆盖。
路由排除、分应用设置、局域网例外和系统平台限制，都可能让请求采用不同路径。客户端为避免连接回环，也需要让自己的某些连接按适当方式出去。检查时要解释是哪条业务流量、哪个应用和哪种地址族，而不是只数开关是否开启。
系统代理则依赖应用读取相应设置，不会被全局模式替代。代理与 VPN 问答解释手机系统接口与客户端转发的区别；sing-box 指南则可用本机入口实验理解“接收请求”与“选择出站”。
使用规则模式或全局模式能保证没有泄露吗？
不能只凭模式名称作出保证，必须先明确希望哪些信息走哪条路径。规则模式中的直连通常是主动设计；若本来要求该请求经过远端，它意外直连才是需要排查的偏差。
- 检查目标应用是否进入核心，是否存在分应用或目的网段排除。
- 分别检查 IPv4 与 IPv6，避免只验收一个地址族。
- 确认 DNS 路径与业务路径，不将出口查询当成全部请求的证明。
- 确认客户端停止、网络切换或配置更新时的行为，必要时对关键请求重复验证。
看到一个预期出口只能支持那个请求的结论。程序自己的 DNS、UDP 连接、未接入应用和异常回退仍可能有其他路径。使用“绝对无泄露”描述一个未经完整验证的规则文件，会掩盖真正需要检查的条件。
应该怎样排查一次错误分流？
固定一个目标和一套设置，从连接记录逐层追踪。先备份原配置，记录应用版本、模式和策略组选择，再发起一次没有依赖缓存的请求。
- 没有连接记录：先检查系统代理、TUN 路由、应用范围与请求是否真的发出。
- 有记录但缺少预期域名：检查应用解析方式与核心能够获得的信息。
- 命中错误规则：核对顺序、条件和当前加载的规则集，只修改相关项目。
- 命中正确策略却出站不对：查看策略组当前选择、嵌套策略与自动选择状态。
- 出站正确仍访问失败：继续检查远端连接、TLS 和目标应用，而不是把所有故障归为分流。
保存改动前后的同一请求结果，升级或更新订阅后重新验证关键规则。需要完整检查路径时可使用 故障排查入口；能解释日志中的选择，才算确认了这次分流行为。
常见问题
全局模式是不是等于全设备所有流量都走代理？
不是。全局主要影响进入核心后的出站选择，应用是否接入、TUN 路由与排除项仍可能影响范围，GLOBAL 也需要确认实际选择。
规则模式有直连请求就说明规则失败吗？
不一定。直连可能是规则明确指定的结果。应先判断目标请求原本需要采用什么路径，再对照命中规则和最终出站。
为什么选了节点 A，面板却显示另一节点？
请求可能命中不同策略组，或该组由自动选择和嵌套策略决定最终节点。沿命中规则、策略组、最终出站逐层核对。
开启 TUN 后是否可以删掉全部规则？
TUN 解决接收流量的问题，规则解决选择出站的问题。是否需要具体规则取决于用途，删掉规则可能让请求采用兜底路径。
DNS 查询走远端，网页也一定走远端吗？
不一定。DNS 和业务连接可以有不同路由，浏览器和客户端也可能使用独立解析设置，应分别查看查询与连接证据。
配置文件更新后，为什么分流行为变化了？
规则集、订阅原文、应用覆写或策略组选择可能变化。查看实际加载配置，比较变更前后同一个请求，而不是仅比较节点数量。
官方来源与核对
本文依据以下标准与官方资料整理，资料核对日期为 2026.10.02。概念说明与具体软件实现有区别，实际设置仍需对照对应版本文档。