切换到规则模式后，部分应用的网络走向没有变化，并不一定意味着Bettbox中的规则失效。先看请求有没有进入内核，再看它如何被处理。“谁把请求送进来”和“进来之后去哪里”，是两个不同问题。
用一条请求，分清三个层次
应用发起请求后，可能使用系统代理，也可能使用自身代理设置或直接连接。只有请求进入Mihomo内核，内核的模式与规则才有机会参与处理。因此排查时应从入口开始，而不是直接修改出站规则。
可以将路径理解为应用、代理入口、内核策略和最终连接。每一层都有独立条件。先在连接记录中寻找可复现请求，若没有记录，重点检查应用与系统设置，而非假定某条域名规则写错。
系统代理负责提供入口，不保证所有应用遵循
系统代理向支持该设置的应用告知代理地址与端口。一些程序可能忽略它，另一些程序有独立设置；终端工具也可能使用环境变量。因此开启系统代理不能被描述为自动接管所有程序流量。
修改前记录原值，确认实际监听地址与端口，再选择一个支持该设置的应用验证。虚拟网络接口是另一类入口机制，权限和影响范围不同，不应在没有明确需求时一起启用。基础关系见配置与连接状态说明。
规则模式决定已进入连接的处理方式
规则模式下，内核依据配置中的条件进行匹配，再选择对应策略。域名、IP、进程或规则集合都可能参与判断，顺序也会影响结果。这里的直连是内核选择的出站行为，不等于请求从未经过内核。
全局或直连等其他模式改变的是内核处理方式，仍不自动解决应用入口问题。排查时对照当前模式、当前活动配置与规则命中记录，不要单凭开关名称猜测整个系统的流量走向。
域名、IP与DNS，需要放在同一条路径里看
域名条件与IP条件依赖的上下文不同。DNS解析方式、请求中是否保留域名，以及资源内容，都会影响最终匹配。看到一个IP地址时，不应立刻认定所有域名规则都未生效。
先确认配置实际加载，再阅读对应日志。配置名称或引用不一致时，先按活动配置与资源引用检查核验。避免为了让单个目标走通而同时替换全部DNS与规则资源，那会丢失可比较的条件。
怎样验证调整产生了预期影响？
选择一个已知应用和目标，记录调整前的入口、规则命中与响应，再只修改一个条件，重复同样请求。注意应用可能复用旧连接，必要时在可控范围重新建立测试连接，区分新旧请求。
如果内核确实接收到请求，但没有预期响应，继续检查出站策略、DNS和远端服务。使用连接失败的分层方法缩小范围，不能把每一种网络失败都归结为系统代理或某条规则。
