先分清两类失败：「本机没把门打开」和「出门后走不通」
很多用户一看到浏览器转圈，就急着换节点、重装客户端。实际上，Clash 已经把失败原因拆成两类信号：一类是在本机绑定监听端口失败（常见是 mixed-port、port、socks-port 与系统里其它程序抢端口，或同一配置里端口写重复）；另一类是已经出了本机，正在对远端地址做 dial，日志里会出现 dial tcp、握手或读写出错、i/o timeout、context deadline exceeded 等字样。前者修的是「入口」，后者修的是「出口与链路」。
本文只做一件事：教你对着日志关键词做对照，把问题先归到正确的桶里，再决定是改端口、关冲突程序、核对 YAML，还是换节点、换协议、检查防火墙与 DNS。若你刚换过内核或 GUI，也建议先扫一眼《Clash Meta（Mihomo）升级完整指南》，避免字段名与行为已经和旧版不一致，却在日志里误判成「节点坏了」。
看日志之前：把日志级别与输出位置找对
不同桌面客户端把日志藏在不同面板，但内核侧逻辑类似：需要能看到 ERROR / WARNING 与连接轨迹。若长期停在静默级别，你会错过「监听失败」这种一启动就出现的短日志。建议在复现问题的那几分钟内，临时把日志级别调高（具体入口因客户端而异），复现后立即保存一段完整片段再去分析。
抓取时尽量带上时间顺序：从「启动内核」到「浏览器第一次访问失败」之间的几十行，往往比单条报错更有价值。若你同时开了 TUN，日志里还可能混入虚拟网卡与路由相关提示，可与《Windows 上 Clash TUN 与 Wintun 排错》对照，避免把系统层问题全算在节点头上。
第一类：本机端口与监听相关（mixed-port / socks-port / bind）
当你在配置里声明了 mixed-port（或分别声明 port 与 socks-port）时，内核会尝试在本机指定地址上监听。若日志出现 address already in use、bind: address already in use、或在中文环境里被翻译成「地址已被使用」一类描述，基本可以直接判定：该端口已被其它进程占用，或你同时起了两个 Clash 实例指向同一组端口。
另一类常见写法是明确标出端口号，例如提示无法监听 127.0.0.1:7890 或 0.0.0.0:7891。这时请按顺序做三件事：第一，用系统工具查看该端口归属（各操作系统都有现成命令或资源监视器）；第二，检查是否还有旧进程、托盘里第二个客户端、IDE 内置代理、其它梯子软件占着同一端口；第三，打开你的 YAML，确认 mixed-port 与 socks-port、以及某些发行版额外暴露的 redir-port、tproxy-port 等没有两两撞车。只要监听起不来，浏览器里往往表现为「完全不走代理」或「偶发连本地代理失败」，这与远端节点超时在体感上可能相似，但日志指向完全不同。
若你显式配置了 bind-address，还要留意是否绑到了错误的网卡地址：例如只绑在某一虚拟网卡或容器网段上，导致本机应用连不上「你以为的」那个入口。此类问题仍会落在「本机入口」范畴，优先核对地址与防火墙放行，而不是盲目换机场线路。
第二类：对外 dial tcp——已经出了本机，正在连远端
当你看到日志里出现 dial tcp 并带上远端 IP 或域名与端口，含义是：内核正尝试通过当前策略，向该目标建立 TCP 连接。注意，这不等于「一定是节点坏了」——它只说明「这一跳在尝试连出去」。若后面紧跟 TLS 握手、WebSocket 升级或协议层日志，说明 TCP 路径上至少有一部分在推进；若长时间停在这一行没有后续成功记录，就要结合超时类信息一起看。
把 dial tcp 当作路标：它告诉你「当前这条连接打算去哪」。若你怀疑规则把流量送到了错误策略，可以对照同一时间点的策略命中日志（若客户端提供），看是不是误走了直连、或误走了某个慢策略组。更系统的分流与 DNS 对齐思路，可参考《Clash DNS 防泄漏配置指南》，避免「解析与规则各说各话」造成的假超时。
「连接超时」在日志里长什么样
不同版本与底层网络栈的措辞略有差异，但下列关键词在 Mihomo / Clash 系日志里非常常见，且多指向链路在限定时间内没有完成你期待的阶段（建连、握手、首包等）：
i/o timeout：读写或等待对端响应超时，常见于弱网、丢包、被中间设备黑洞、或远端根本不可达。context deadline exceeded：上下文截止时间到了仍未完成操作，本质仍是超时类失败的一种表达。TLS handshake timeout：TCP 已尝试建立，但 TLS 层在时限内没完成，可能与 SNI、证书链、协议不匹配或链路抖动有关。EOF、connection reset：不一定是「超时」，但常和「对端提前断开」一起出现；若频繁发生在同一节点，同样要怀疑线路或服务端策略。
当这些词出现在 dial tcp 之后、且目标是你订阅里的节点地址时，优先怀疑节点池、出口网络、当地运营商 QoS、或协议与端口被干扰。此时改本机 mixed-port 通常无济于事，更有效的是：换同组内其它节点、换传输方式、错峰测速，或按《Clash 提速与稳连技巧》里关于 URL-Test、订阅健康与 DNS 的章节做一次「对照实验」。
一页对照：先扫这条，再决定下钻方向
下面这张表不是绝对真理，但能帮你在三十秒内把大方向摆正：
- 启动阶段即报错，且含 already in use / bind → 本机端口占用或配置冲突；先空出端口、关重复进程、核对 YAML 多端口是否重复。
- 能启动，访问时才有
dial tcp，随后超时或握手超时 → 更偏远端与链路；换节点、换协议、检查本机防火墙出方向与路由器 DNS，而不是先折腾监听端口。 - 仅个别域名失败、同节点访问其它站正常 → 可能是规则、DNS 回落顺序或目标站策略；用最小规则集复现，避免一条 MATCH 把所有问题糊成「超时」。
- 间歇性、集中在晚高峰 → 更像容量与 QoS；日志会呈现批量超时尖峰，可与测速记录交叉验证。
日志长什么样（示意）
真实日志会因版本与客户端不同而略有出入，下面仅示意该留意的片段形态，便于你在自己的日志里搜索关键词：
listen tcp 127.0.0.1:7890: bind: address already in usedial tcp 198.51.100.10:443: i/o timeout第一行请立刻回到「端口与监听」排查链；第二行请回到「节点与出口链路」排查链。把两类示例记在脑子里，比记任何玄学参数都管用。
几个容易误判的点
有时客户端升级后会自动改默认本地端口，而浏览器或系统代理仍指向旧端口，你会感觉「全挂了」，但日志里可能只有大量连接失败到旧端口——这类问题本质是应用配置与当前监听不一致，既不是节点超时，也不一定是端口被占用，而是「连错了门」。
又如：某些环境同时启用系统代理与 TUN，若规则再叠加「绕过局域网」，可能出现部分应用走隧道、部分走直连的混杂状态，日志看起来像随机超时。此时不要只盯一条 dial tcp，而要问「这条连接当时应该走哪条策略」。分层理清比单点换节点更能节省时间。
合规与边界
本文仅讨论开源代理客户端的一般排障方法，不构成对任何地区法律法规的规避建议。请在你所在地法律允许的范围内使用网络技术，并尊重服务提供商条款与他人权益。
小结
对着 Clash 日志排错，核心是先回答两个问题：本机的 mixed-port / socks-port 是否成功监听，以及 dial tcp 之后是握手失败、超时，还是被对端重置。前者把问题锁在端口占用、重复实例与 YAML 端口冲突；后者把问题引向节点、线路、DNS 与规则命中。把这两类信号分开，你就不会再把「换端口」和「换节点」随机试错。
相比在论坛碎片信息里碰运气，一款与 Mihomo 同步迭代、日志可读性好、又能平滑升级的 Clash 发行版，往往能让这类对照排查事半功倍。若你希望从稳定客户端与清晰日志视图开始，可先前往本站下载页获取适合自己系统的版本，用小流量复现并保存日志后再逐项处理。→ 立即免费下载 Clash，开启流畅上网新体验