浏览器提示连接失败，只给出了最后的结果，无法直接说明Mihomo的哪一层出现异常。核心可能正在运行，却没有加载你修改的配置；DNS可能已经返回答案，但远端端口拒绝连接。先记录问题开始时间、最近改动和受影响范围，再沿六层路径逐个寻找证据。
第一层与第二层：进程和活动配置
确认目标核心进程实际运行，启动日志没有在初始化后退出。检查本地监听是否按预期建立，是否存在端口占用或权限不足。Windows可只读查看 Get-NetTCPConnection -State Listen；Linux可用 ss -lntup；macOS可查看 lsof -nP -iTCP -sTCP:LISTEN。可见信息受权限影响，命令输出不是预设结论。
接着确认当前配置来源、加载时间和最近一次重载结果。桌面端和服务可能启动不同的核心实例；磁盘中的文件已保存，并不能证明运行中的进程使用了它。遇到占用时先识别进程用途，不要强制结束未知系统进程。
第三层：请求有没有进入核心
使用系统代理时，核对应用是否遵循该设置；使用TUN时，查看虚拟接口、路由表和实际出口，参考虚拟接口状态检查区分创建成功与流量进入。其他VPN、多网卡切换或防火墙策略可能改变路径，接口存在本身并非接管证据。
在明确时间发起一次目标请求，对照连接记录。没有任何相关入站时，先排入口；已有入站再向下检查。避免同时改变代理端口、TUN参数和DNS地址，否则无法判断哪项变化有效。
第四层：DNS查询在哪里完成
确认应用使用系统DNS还是自己的解析方式，查询有没有到达核心。按DNS字段分工检查监听、域名策略、上游和缓存。Fake-IP答案需要按映射理解；不要把它当作真实远端IP，也不要因看到虚拟地址就认定DNS出错。
DNS超时、没有记录、返回空AAAA和已经得到答案是不同现象。记录查询目标与类型，再判断是入口、上游可达性还是配置选择问题。解析成功后停止反复替换服务器，继续检查规则与实际连接。
第五层：规则决定了哪条路径
核对当前运行模式、命中规则及策略的实际选择。规则保存却未加载、靠前条件先匹配、RULE-SET没有正确加载，都会造成预期差异。按流量匹配路径记录目标信息和决策结果，确认这次请求进入的是哪种入站。
规则命中并不证明连接完成。策略组名称也不等于当前最终出口；需要继续看实际选择和错误。协议能力、目标端口和远端服务状态都属于后续检查范围。
第六层：远端连接为何失败
“连接拒绝”通常表明收到明确拒绝或没有服务监听；“连接超时”可能涉及丢包、路由、防火墙、远端不可达等条件，不能只凭字样确定责任方。TLS错误还需要检查系统时间、证书和目标名称，不要为了访问成功跳过验证。
比较单个目标与多个目标、单个应用与多个应用的表现，观察是否只在特定网络出口出现。延迟测试只反映被测目标和测试协议；没有实际测量时，不能推断速度提高或稳定性改善。
一次只改变一件事
保留原配置，优先读取状态，小范围调整后用同一目标复测，并记录变化。不要在缺少证据时重置整个网络、清空路由表、删除所有虚拟网卡或关闭全部防火墙。最后整理“时间—入口—解析—命中—出口—错误”的对应关系；即使问题尚未解决，这份记录也能把下一次检查限制在更小的范围内。
