Clash 日志怎么看？从错误提示快速判断问题方向

一、先别急着看全部日志，先看出问题的时间

实际排查时，可以先回忆一个动作：你是在什么时候打开网页、切换节点、更新订阅或启动某个软件的？然后在日志里找到对应时间附近的几行。

很多新手会从日志第一行看到最后一行，结果越看越迷糊。正确做法是只看问题发生前后的内容。比如你 10:30 打开某个网页失败，就重点看 10:29 到 10:31 之间的日志。时间对上了，后面的域名、规则和错误提示才有意义。

如果日志里持续滚动很多内容，也不用紧张。Clash 本来就会记录大量连接、规则匹配和 DNS 请求，不是每一条都代表故障。

二、再看目标域名，确认是不是你正在访问的服务

日志里通常会出现域名、IP 或连接目标。新手排查时，可以先看看日志中是否出现了你刚刚访问的网站或应用相关域名。

如果你打开的是某个网页，但日志里完全没有相关请求，可能说明这个浏览器或软件并没有把流量交给 Clash。常见原因包括系统代理没开、软件不读取系统代理、端口配置不一致，或者应用本身使用了独立网络设置。

如果日志里出现了相关域名，说明请求至少已经进入 Clash。接下来就可以继续看它匹配了什么规则、走了哪个策略组，以及最后失败的原因是什么。

三、timeout：最常见，但不一定最严重

timeout 是很多人最常见到的日志关键词。它的意思通常是连接等待超时，目标没有在规定时间内响应。很多人一看到 timeout 就以为配置彻底坏了，其实不一定。

如果只有某一个节点出现 timeout，而换其他节点正常，可能是该节点当前状态不稳定、线路拥堵或暂时不可用。如果所有节点都 timeout，就要回头检查本地网络、订阅是否过期、系统代理是否正常，或者 DNS 是否解析异常。

实际排查时可以先做两步：换一个节点测试，再关闭 Clash 直接检查本地网络。如果本地网络本身也慢，日志里的 timeout 可能只是网络波动的结果。

四、connection refused：对方拒绝连接，方向更明确

connection refused 通常表示连接被拒绝。它和 timeout 不一样，timeout 是等不到回应，refused 则更像是对方明确拒绝了连接。

这个提示可能出现在几种场景里：本地代理端口没有正确启动，目标服务不接受连接，节点端服务异常，或者配置里的端口、协议不匹配。新手看到这个提示时，不要马上去改规则，应该先确认 Clash 是否正常运行、系统代理端口是否一致、节点是否可用。

如果日志中显示本地 127.0.0.1 某个端口 refused，就更要关注本地端口和客户端状态；如果是远程连接 refused，则更可能与节点或目标服务有关。

五、DNS failed：问题可能还没到连接阶段

DNS failed、lookup failed、no such host 这类提示，通常说明域名解析出现问题。通俗说，就是还没真正连接到目标服务，第一步“把域名翻译成 IP 地址”就失败了。

很多人会误以为网页打不开一定是节点问题，但如果日志里反复出现 DNS 相关错误，就应该优先看 DNS 设置、订阅配置和当前网络环境。尤其是在开启 TUN 模式后，DNS 配置不合适更容易导致部分网页打不开、应用加载失败。

新手不建议一看到 DNS failed 就复制网上一整段 DNS 配置。更稳妥的做法是先更新订阅、重启客户端，再观察是否恢复；如果最近改过 DNS 或 TUN 设置，可以先恢复到修改前的配置。

六、rule match：这通常不是报错，而是在告诉你走哪条规则

日志里的 rule match 很容易被新手误解成错误。其实它多数时候只是提示：当前请求匹配到了哪条规则，接下来会走 DIRECT、PROXY、REJECT 或某个策略组。

比如你访问一个本地服务，日志显示匹配 DIRECT，这通常是正常的；访问某个服务时匹配到了 REJECT，就可能导致页面元素加载失败或连接被拦截。这里要结合实际现象判断。

如果某个网站打不开，但日志显示它被分到了你不希望的策略，比如本该直连却走了代理，或者本该放行却被 REJECT，就说明问题可能在规则分流。此时可以临时切换模式测试，但不要盲目大改规则。

七、proxy group：关注当前到底选了哪个策略

proxy group 相关日志通常和策略组选择有关。Clash 不一定直接把请求交给某个具体节点，而是先交给一个策略组，比如“节点选择”“自动选择”“故障转移”等。

如果日志显示请求进入了某个 proxy group，但最终连接失败，就要看这个策略组当前选择的是哪个节点。很多人以为自己换了节点，实际上策略组里选中的还是旧节点，或者自动选择没有及时更新。

实际排查时，可以打开客户端的策略组页面，看当前选中的节点是否符合预期。必要时手动切换一个稳定节点，再重新访问测试。

八、connect error：要结合后面的具体原因看

connect error 是一个比较泛的提示，意思是连接过程出错。但它本身不够具体，关键要看后面跟着什么内容。

如果后面是 timeout，就按超时方向排查；如果是 refused，就看端口、节点或服务是否拒绝；如果伴随 DNS failed，就先查解析；如果只在某个目标域名出现，可能是目标服务响应问题或规则匹配问题。

新手看到 connect error 时，不需要紧张，也不要只截这一行去求助。最好连同前后几行一起看：目标是什么，匹配了什么规则，走了哪个策略组，最后是什么错误类型。

九、哪些日志不用过度紧张？

并不是所有 error 都意味着严重故障。比如短时间的 timeout、单个节点测速失败、某些无关域名连接失败、广告或统计请求被 REJECT，都不一定影响正常使用。

很多应用后台会不断请求各种服务，其中一部分失败很正常。只要你实际访问的网站和软件功能正常，就不需要因为日志里有几条失败记录而反复调整配置。

真正需要重点关注的是：同一个错误连续大量出现；所有节点都连接失败；DNS failed 反复刷屏；本地端口启动失败；系统代理开启后没有任何请求进入 Clash；或者日志显示核心配置加载失败。

十、新手看日志的实用顺序

实际排查时可以按一个简单顺序来：先看时间，确认是不是问题发生时的日志；再看目标域名，确认请求有没有进入 Clash；然后看 rule match，判断它走了哪条规则；接着看 proxy group，确认当前使用哪个策略或节点；最后看错误关键词，是 timeout、DNS failed、connection refused，还是 connect error。

按照这个顺序看，日志就不再是一堆混乱文字，而是一条连接过程的记录。它告诉你：请求来了没有，匹配了什么，交给了谁，最后失败在哪里。