核验日期：2026-09-19。本文包含本地内核实测关联证据；真实订阅与客户端 GUI 未实测。
先回答两个不同的问题
系统代理、应用内代理和 TUN 决定流量怎样进入客户端；规则、全局、直连决定进入核心后怎样处理。打开全局模式并不保证所有应用都会进入核心。一个自己直连的命令行程序，可能完全不受这次切换影响。
Mihomo 定义 rule、global、direct 三种模式；global 还需要检查 GLOBAL 策略组当前选项。若选中的是 DIRECT，名称叫“全局”也不代表使用了远端节点。模式定义
做一次只改变模式的对照
准备一个固定测试地址和一个应用，记录当前模式、策略组选项、接管方式。关闭测试页面旧连接后重新请求，避免复用旧连接影响观察。不要在切模式时顺便换节点、改 DNS 和换 Wi-Fi，否则结果无法归因。
| 模式 | 检查什么 | 适合回答什么问题 |
|---|---|---|
| 规则 | 目标命中哪条规则、规则指向哪组、组最终选了谁 | 是否是分流配置导致异常 |
| 全局 | GLOBAL 最终选择的出口 | 暂时排除普通分流规则后是否有变化 |
| 直连 | 请求是否仍进入核心、出口是否为 DIRECT | 节点路径和本机直连路径是否存在差异 |
顺序建议：先记录规则模式结果，再临时切全局并选定节点测试，最后恢复原来的规则模式。若全局成功而规则失败，只能缩小到分流相关因素，还要核对实际出口、DNS 和目标连接；不能直接断定某一条规则错误。
本地实测：拒绝规则不等于端口关闭
2026-09-19 在 Windows x64 上以 Mihomo v1.19.31 运行独立配置：回环地址走 DIRECT，其余 MATCH,REJECT。本地 HTTP 与 SOCKS5 请求均返回 clash-lab-ok；请求文档示例地址 192.0.2.1 时，日志显示 using REJECT，HTTP 客户端收到 502；停止核心后再请求则是连接端口失败。
这说明“代理端口能连接，但规则拒绝”与“代理进程没在监听”是不同故障。502 本身不能证明规则拒绝，必须结合本次日志；其他环境的 502 也可能来自上游。完整配置、命令与证据
规则没生效时按这个顺序看
- 没有连接记录：检查接管方式及测试应用自己的代理设置。
- 有连接但目标不同：确认重定向、子域名和后台请求，别只比较地址栏域名。
- 命中了意外规则：检查规则顺序以及是否载入了新配置。
- 规则指向正确组，但结果不对：检查组里最终选择的是节点、另一组还是 DIRECT。
- 只有旧标签页异常：建立新连接再比较，记录时间对应日志。
来源与适用边界
Mihomo 路由规则用于核对规则定义；模式定义来源见上文。排查顺序和实验为本站原创。实验未测试远端节点、TUN、UDP、系统代理自动设置或路由器防火墙；不能把本地结果外推成所有模式均已实测。