为什么「已连接」不等于「能上网」？
在 Mihomo 系 Clash 客户端里，「已连接」通常只说明本地代理栈已启动：虚拟网卡或系统代理监听端口就绪、内核加载了配置、策略组里至少有一个节点被标记为可用。它并不保证每一次 DNS 查询、每一条 TCP 连接、每一个 QUIC 会话都能顺利走完。
用户侧最直观的矛盾是：状态栏一切正常，打开任意网页却超时；或只有部分应用异常。要把问题缩小到可修复的范围，最有效的方法不是反复切换节点，而是打开日志，对照时间线，看失败发生在解析、选路、握手还是上游转发。下面的分层思路，与你在《TUN 模式完全指南》里看到的「接管流量」概念是衔接的：TUN 解决漏流，但漏流之外还有 DNS 与规则顺序问题。
先排除三类「看起来像 Clash 坏了」的情况
在深入 Clash 日志排查 之前，先用两分钟确认不是下面三类环境噪声。它们都会造成「代理开着却没网」的错觉，但修复路径与 Clash 无关或只需改系统设置。
第一类：本机或路由器出口本身故障。关闭 Clash 的系统代理与 TUN，用同一台电脑直连访问国内常用站点。若直连同样打不开，应先处理家宽、DNS 被路由器强制改写、或公司安全软件的全盘过滤。
第二类：浏览器或应用走了「固定代理 / 插件代理」。某些浏览器插件、独立版聊天软件、游戏启动器会自带代理设置，和系统代理叠加后可能出现环路或黑洞。临时禁用插件、在无痕窗口复现，能快速缩小范围。
第三类：系统时间严重漂移。TLS 握手依赖证书校验，时间错几分钟到几小时，就可能出现大面积「连上却刷不出内容」。校对系统时间后再看日志，避免误判为节点问题。
日志与面板：应该盯哪些字段？
当你遇到 Clash 已连接无法上网 时，建议同时打开两类信息源：一是客户端的实时连接 / 会话列表（通常能看到域名、进程、命中的策略与出口节点）；二是内核的文本日志（能看到解析、拨号、TLS、重置等细节）。
阅读顺序可以固定为「从前往后」：先 DNS，再规则，再 TLS，最后上游。若在日志里看到查询阶段就失败，却急着换节点，往往是在第三层才该动手的变量上浪费时间。若连接列表显示某域名命中了 DIRECT，而你的预期是走代理，那么问题在规则漏配或顺序错误，与节点带宽无关。
对规则结构与 MATCH 兜底不熟悉的读者，可先对照《自定义分流规则入门》理清「自上而下匹配」的语义，再回到日志里看每一次命中是否符合你的设计意图。
第一层：DNS 模式与解析失败
DNS 是绝大多数「能 ping 通 IP、网页却打不开」的根源之一。Clash / Mihomo 的 DNS 模式（如 fake-ip 与 redir-host）决定了域名在本地如何被缓存、如何把解析结果与后续连接关联起来。若 dns 段与 rules 段没有协同好，会出现间歇性 NXDOMAIN、解析到错误地区的 CDN、或规则永远匹配不到你以为是「那个域名」的流量。
在日志里，若你看到大量与解析相关的错误或重试，优先检查：是否仍有程序绕过 Clash 直接向运营商 DNS 发问；路由器是否开启了「强制 DNS 转发」；以及安全软件是否注入了自己的解析链。此类问题表现为「同一站点时好时坏」，与节点晚高峰无关。
一个实用的对照实验是：在保持其他配置不变的前提下，仅把日志级别调高，访问一个纯 HTTPS 的测试域名，观察从查询到建立连接的时间线是否断裂在解析阶段。若断裂点总在解析之后，再往下游排查。更多平台相关说明可在使用文档中按系统章节核对。
第二层：规则漏配、DIRECT 与 REJECT
第二层是最常见、也最容易被误判为「节点坏了」的情况：日志或连接列表清楚写着某域名走了 DIRECT，而目标站点在你所在网络环境下必须经代理才能访问。这不是内核「偷懒」，而是规则命中结果与你的真实意图不一致。
典型成因包括：规则顺序把更宽泛的直连条目放在了前面；GEOIP 或远程规则集版本过旧；把未收录的新 CDN 域名误送进直连；或 MATCH 兜底指向了错误的策略组。此类问题在日志里往往没有「握手超时」，而是直连侧立即被拒绝或长时间无响应。
另一类是 REJECT 规则命中：广告过滤、隐私列表、或手写误杀，都会让浏览器表现为「白屏转圈」。处理方式是先在连接记录里确认策略名，再回溯到对应规则文件或 Provider。若你大量使用远程规则集，维护更新节奏与合并顺序可参考《Rule Providers 规则集进阶教程》，降低「规则漏配」带来的不确定性。
第三层：TLS、SNI 与证书类报错
当 DNS 与规则都看似正常，日志却出现证书校验失败、SNI 不匹配、或 TLS 握手被中间设备重置时，问题往往落在链路与审查设备上，而不是 Clash 的「连接开关」。这类日志通常伴随明确的 TLS 相关关键字，而不是单纯的超时。
实践上建议先区分：是所有站点都 TLS 失败，还是特定域名失败。若只有特定域名失败，更可能与该域名的证书链、企业中间人检测、或上游节点对 SNI 的处理有关。若所有站点同时失败，才优先怀疑本地时间、根证书存储、或安全软件 HTTPS 扫描。
在更换节点之前，可以尝试用同一策略访问另一个主流 HTTPS 站点做交叉验证。交叉结果能把问题从「全局 TLS 环境」与「单域名 / 单节点路径」之间切开，避免一次改动动到多个变量。
第四层：节点握手、超时与 UDP
若日志显示已经根据规则选择了代理策略，且开始向上游拨号，但长时间停留在握手或反复重连，这一层才轮到评估节点质量、传输组合、UDP 是否被丢弃。晚高峰拥塞、机场线路割接、或 QUIC 被运营商干扰，都会在这一层体现为超时、连接重置、或仅 TCP 正常而 UDP 全黑。
注意：某些应用强依赖 UDP。若策略或规则把相关会话送到不合适的出口，会出现「网页能开、语音不通」的割裂体验。此时应回到连接记录核对五元组与进程，而不是只看 ICMP 延迟测试结果。
若你同时启用 TUN 与其它网络扩展，还要留心路由与栈的叠加是否导致握手包走错接口。TUN 权限、stack 选型、以及系统里残留的旧 VPN 路由，都可能让这一层的日志看起来非常「随机」。更系统的平台差异仍以《TUN 模式完全指南》为准。
可复现实测步骤：建议按顺序执行
下面是一套在真实用户环境里反复验证过的实测步骤，目标是让每一次只改变一个变量，从而能在日志里读出明确结论。
步骤一：固定场景。选定一个失败用例（例如某个固定网址、或某个应用的登录请求），关闭无关应用，清空旧日志或标记开始时间，确保后续记录可对照。
步骤二：只看解析。触发一次访问，先在日志中定位该域名是否完成解析、解析结果是否与连接目标一致。若解析阶段异常，优先处理 DNS 模式与本地劫持链。
步骤三：核对命中策略。在连接记录中找到对应会话，确认策略名与规则类型。若出现意外的 DIRECT 或 REJECT，回到规则顺序与 Provider 版本，而不是换节点。
步骤四：看 TLS 与握手。若策略正确且开始握手，记录 TLS 阶段是否有明确错误文本；与步骤一的固定用例重复三次，排除偶发抖动。
步骤五：最小化对比。在保持规则不变的前提下，仅更换一个上游节点或暂时切换 TUN 与系统代理模式，再次复现。若现象随节点而变，才进入「出口质量」维度的优化。
把以上五步当作检查表使用，能显著减少「重装客户端后好十分钟又坏」的无效循环。排错笔记也建议按时间线记录：同一域名在日志中的各阶段耗时，往往比主观感受更接近真相。
配置层面：两个常被忽略的协同点
日志读懂之后，落地修复通常落在配置协同上。下面给出一段示意性 YAML 骨架，仅用于提醒常见键位关系，实际键名与缩进请以你所用内核版本模板为准：
# Illustrative skeleton — align with your Mihomo template
dns:
enable: true
enhanced-mode: fake-ip # or redir-host: pick one and stick to it
nameserver:
- https://1.1.1.1/dns-query
rules:
- DOMAIN-SUFFIX,corp.internal,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY第一处协同是：enhanced-mode 与后续 rules 的域名类规则如何匹配；第二处协同是：nameserver 与 fallback 链是否在日志里按预期触发。修改后务必观察日志是否出现新的解析环路或重复查询，而不是只看 GUI 绿灯。
小结
Clash 已连接无法上网 的本质，是「本地代理已就绪」与「端到端路径可用」之间的缝隙。把问题拆成 DNS、规则、TLS 与上游握手四层，再用日志对齐时间线，你能更快判断该改解析、改规则，还是该换出口。
相比零散渠道获取的安装包，使用与本站文档一致的客户端版本，能减少「界面显示已开启、配置未完整加载」的隐性成本。若你希望下载来源、权限提示与内核能力一一对应，可从本站客户端下载页获取当前系统的安装包，再按本文顺序逐项自检。统一入口能降低版本错配带来的不确定性，排错日志也更易对照社区经验。
若你愿意把「分层读日志」当作长期习惯，会发现多数故障并不需要玄学式操作；它们只是某一层链条松了，而你终于看见了松在哪一环。