99吧机场

站长推荐

IPLC专线+BGP中转，不限使用设备数量，价格亲民，性价比拉满！

→

FlyBit机场

折扣优惠

IPLC专线+中转,所有线路都是1倍率，用多少算多少，很实在！

→

很多人在 Clash 中遇到问题时，第一反应往往是“换个节点”“更新订阅”或者“重装客户端”。这些操作有时确实能解决问题，但也容易把原本可定位的问题变成一团乱麻：到底是规则选错了？DNS 解析异常？节点握手失败？还是浏览器根本没有走进 Clash？

Clash 的“日志（Logs）”页面，就是回答这些问题的线索中心。它不需要你懂编程，也不要求你逐行阅读所有英文；只要掌握几个高频关键词，并按正确顺序观察，就能把大多数问题缩小到明确范围。

本文适用于 Clash Verge、Clash Meta 系客户端、Clash Party、FlClash 等常见图形界面。不同客户端的按钮名称可能略有不同，但日志信息和排查思路基本一致。

先建立正确思路：日志记录的是“发生过什么”

打开日志页后，初看通常会觉得信息滚动很快，内容也充满 IP、端口和英文。其实，一条典型的连接日志通常只包含四件事：

1. 哪个应用发起了请求：例如浏览器、Telegram、游戏平台或系统服务；
2. 它要访问哪个域名或 IP：例如某个网站域名、CDN 地址；
3. Clash 用了哪条规则处理它：走代理、直连、拦截，还是匹配到某个策略组；
4. 最终选择了什么出口以及是否成功：例如某个节点、DIRECT（直连）或 REJECT（拒绝）。

因此，排障时不应一上来就在大量旧日志里搜索错误。更高效的方法是：先清空日志，复现一次问题，再只看刚刚出现的几行。

例如，你发现某个网站打不开，就先打开 Clash 日志页，点击“清空”或垃圾桶图标，然后在浏览器中重新访问该网站。此时日志里新增的记录，就是最有价值的证据。

排查前的三个准备动作

1. 将日志级别调到 Info 或 Debug

多数 Clash 客户端提供 Silent、Error、Warning、Info、Debug 等日志级别。

• Info：适合日常排查，能看到大部分连接走向、规则匹配和基础错误；
• Debug：信息更完整，适合 DNS、规则、TUN 等复杂故障，但日志量会明显增加；
• Warning / Error：只显示警告或错误，信息太少，通常不适合判断“为什么没有走代理”。

建议先使用 Info。当你确认问题与 DNS、规则集下载或 TUN 转发有关，再临时切换到 Debug。问题解决后可调回 Info，避免日志过多影响阅读。

2. 只复现一个问题

不要一边打开多个网页、一边启动游戏、一边让后台应用同步数据。这样会产生大量无关请求，容易掩盖关键记录。

一次只做一件事，例如：

• 只访问一个打不开的网址；
• 只登录一个无法联网的应用；
• 只刷新一次规则或订阅；
• 只启动一次某个游戏客户端。

如果问题只发生在特定应用，最好先完全退出该应用，再清空日志后重新打开。

3. 记录准确的报错现象

“打不开”其实可能是完全不同的情况：

• 浏览器提示 DNS_PROBE_FINISHED_NXDOMAIN；
• 页面一直转圈，最后连接超时；
• 网站能打开，但登录、图片或视频加载失败；
• 应用提示网络不可用；
• Clash 本身显示节点延迟正常，但实际访问失败。

把应用提示、发生时间、目标域名和所用模式记下来，后面查看日志会更快。

读懂一条连接日志：重点看这四个位置

不同内核和客户端显示格式不完全一致，但你经常会看到类似含义的内容：

[TCP] 192.168.1.8:53214 --> example.com:443 match RuleSet(Proxy) using 节点-A

可以把它拆开理解：

• TCP：连接类型。网页和大部分应用常见 TCP；部分实时通信、游戏或 QUIC 流量可能显示 UDP；
• 192.168.1.8:53214：发起请求的本地设备或本机进程使用的临时端口；
• example.com:443：目标域名与端口。443 通常代表 HTTPS，80 常见于 HTTP；
• match RuleSet(Proxy)：命中了某条规则或规则集，规则的处理结果是代理；
• using 节点-A：最终实际使用的节点或策略组选择结果。

你无需特别关注随机变化的本地端口。真正值得盯住的是：目标地址、匹配规则、最终出口、错误提示。

如果日志显示：

match DomainSuffix(cn) using DIRECT

表示该域名匹配了 .cn 相关的直连规则，Clash 正在让它不经过代理直接访问。这不一定是错误；但如果你原本希望它走代理，就已经找到了问题方向：规则顺序或规则内容需要检查。

如果显示：

match Match using 节点-A

说明前面的规则都没有命中，最后落到了 MATCH 兜底规则。这个现象本身也不代表异常，但它提示你：当前域名可能没有被你预期的专用规则覆盖。

高频场景一：日志里根本没有目标网站的记录

当你访问一个网站或打开一个应用，却在 Clash 日志中完全找不到相关域名、IP 或连接记录，通常意味着流量没有进入 Clash。

优先检查以下几项。

系统代理是否已开启

对于浏览器、桌面应用等主要依赖系统代理的软件，先检查 Clash 客户端中的“系统代理”开关是否已打开。Windows 和 macOS 的系统网络代理设置也应指向 Clash 的本地监听端口。

如果你关闭了系统代理，又没有在浏览器扩展、应用内部或系统中手动填写代理地址，流量自然不会进入 Clash，日志也不会出现记录。

是否使用了不兼容系统代理的应用

部分游戏、命令行工具、下载器或旧版软件不读取系统代理。有些应用只支持 SOCKS5，有些只支持 HTTP 代理，还有些根本没有代理设置。

此时可以根据应用支持情况，填写 Clash 的本地代理地址。若客户端提供 Mixed Port，通常可优先使用它；但应以你当前 Clash 配置中实际监听的端口为准。不要照搬网上常见端口数字，更不要把“控制面板端口”误认为代理端口。

TUN 模式是否需要开启

对于不遵循系统代理的流量，TUN 模式可以让系统层面的更多连接进入 Clash。但 TUN 会改变网络转发路径，配置不完整时也可能引发局域网、虚拟网卡或 DNS 异常。

如果你只是浏览网页，不要把开启 TUN 当作默认解决方案。只有确认应用不走系统代理，或确实需要接管更多流量时，再结合客户端说明启用它。

高频场景二：日志显示 DIRECT，但你希望走代理

这是规则问题最常见、也最容易判断的一类情况。日志已经明确告诉你：请求进入了 Clash，但被分配为直连。

先确认目标域名。很多服务并不只使用一个主域名，例如网页主体、登录接口、验证码、图片资源、视频资源可能分属不同域名。你打开首页时看见走代理，并不等于后续所有请求都走代理。

接着检查规则顺序。Clash 的规则通常从上到下匹配，先匹配到的规则会优先执行。如果你在一条较宽泛的直连规则后面，又新增一条更精确的代理规则，后面的规则可能永远没有机会生效。

排查时可以按这个顺序进行：

1. 在日志中复制实际访问的域名；
2. 在当前配置、覆写配置或规则集内容中搜索该域名；
3. 找出最先命中的规则；
4. 判断它是否应当改为代理、是否需要调整规则顺序；
5. 修改后重新加载配置，再清空日志复测。

不要仅凭网站名称猜测域名，也不要为了打开一个页面把所有流量长期切换到全局代理。后者虽然能帮助验证“是否为分流问题”，但不利于长期使用，也会让局域网和国内服务的访问路径变复杂。

高频场景三：日志显示走了节点，但连接超时

如果日志显示请求已使用某个节点，却伴随 timeout、i/o timeout、context deadline exceeded 等提示，说明请求大概率已进入代理链路，但在连接或等待响应阶段失败。

这时要避免一个误区：节点延迟测试有结果，不等于所有网站和应用都一定可正常访问。 延迟测试通常只验证有限的探测目标和短暂连接；真实访问还涉及目标站点、DNS、协议、路由、出口 IP 状态以及应用本身的连接方式。

可以依次做以下判断：

• 同一节点能否访问其他网站；
• 切换同一策略组中的另一个节点后，问题是否变化；
• 同一个目标在规则模式与全局模式下是否表现不同；
• 更换网络环境后是否仍然出现；
• 报错是立即发生，还是等待较长时间后才超时。

如果只有一个节点异常，优先把它视为节点或路径问题；如果同一目标在多个节点上都异常，而其他网站正常，则更可能与目标服务、域名分流或该服务使用的额外域名有关。

常见相关关键词包括：

connect timeout
handshake timeout
i/o timeout
context deadline exceeded
connection reset
EOF

其中 connection reset 表示连接被对端或中间网络重置；EOF 通常表示连接在预期完成前结束。它们只能说明故障发生在连接过程中，不能仅凭一条日志就断定具体原因。应结合“是否仅某节点出现”“是否仅某域名出现”来缩小范围。

高频场景四：DNS 相关报错该怎么看

域名访问的第一步通常是 DNS 解析。若域名无法正确解析，后面的代理连接自然也无法正常建立。

日志中比较常见的 DNS 关键词有：

DNS
resolve
lookup
NXDOMAIN
SERVFAIL
no such host

它们大致可这样理解：

• NXDOMAIN：DNS 服务器认为该域名不存在；
• SERVFAIL：DNS 服务器处理请求失败；
• no such host：系统或程序未能解析出目标主机；
• resolve / lookup：正在执行域名解析，不一定代表报错。

遇到 DNS 问题时，不建议立刻随意复制一大段“万能 DNS 配置”。不同网络、不同 Clash 内核版本、不同 TUN 设置之间的兼容性并不完全相同。更稳妥的做法是先确认问题范围：

1. 是所有域名都无法解析，还是只有一个域名异常；
2. 切换节点后是否变化；
3. 暂时关闭 TUN 后是否恢复；
4. 使用系统默认 DNS 与 Clash 内置 DNS 时表现是否不同；
5. 配置中是否同时存在多个互相覆盖的 DNS 覆写项。

尤其在导入订阅、使用覆写配置、切换不同客户端之后，要警惕 DNS 设置被重复写入。配置里同时出现多个 nameserver、fallback、fake-ip-filter 或增强模式相关配置时，最终行为可能与预期不同。

高频场景五：看到 REJECT、REJECT-DROP 不要误以为节点坏了

REJECT 表示 Clash 按规则主动拒绝了请求，REJECT-DROP 则通常表示静默丢弃。它们常用于广告域名、追踪域名、恶意域名或你自己设置的拦截规则。

例如：

match RuleSet(AdBlock) using REJECT

这说明不是网络不通，也不是节点失效，而是广告拦截规则生效了。

如果某个应用无法登录、支付页面空白、图片验证码加载不出来，而日志恰好显示相关域名被 REJECT，就应考虑拦截规则误伤。处理原则是：

• 先确认域名是否确实属于当前应用的必要服务；
• 只为明确的必要域名添加更精确的放行规则；
• 放行规则应位于拦截规则之前；
• 不要为了一个应用直接关闭全部广告拦截。

这样既能恢复功能，也不会让所有拦截规则失效。

高频场景六：订阅、规则集更新失败时看什么

当 Clash 更新订阅、下载规则集或拉取外部资源失败，日志中常见的不是“节点连接记录”，而是 HTTP 请求、下载地址、证书或解析相关的错误。

可重点留意：

failed to fetch
HTTP 401
HTTP 403
HTTP 404
x509
certificate
TLS handshake

含义通常如下：

• 401：资源需要认证，订阅凭据可能无效或缺失；
• 403：服务器拒绝访问，可能与权限、访问策略或请求条件有关；
• 404：请求地址不存在，链接可能已变更；
• x509、certificate：证书验证相关问题，应先检查系统时间、系统证书环境和网络拦截情况；
• TLS handshake：TLS 握手失败，可能涉及时间、证书、网络链路或服务端配置，不能简单等同于“节点坏了”。

订阅链接属于敏感凭据，日志截图和求助时务必打码。不要公开完整订阅地址、令牌参数、邮箱、设备标识或本地 IP 信息。很多订阅链接一旦泄露，可能被他人使用、滥用或导致原链接被重置。

一个通用的日志排障流程

当某个网站或应用无法使用时，可以按下面的顺序操作：

1. 确认 Clash 已运行，当前配置已启用。
2. 把日志级别设为 Info，清空旧日志。
3. 只复现一次故障操作。
4. 在新日志中找目标域名、目标 IP 或时间相近的记录。
5. **先判断有没有记录。**没有记录，优先检查系统代理、应用代理设置或 TUN；有记录，再继续。
6. **看最终出口。**是 DIRECT、节点名称，还是 REJECT？
7. **看规则命中。**确认是哪个规则集或哪条规则作出的决定。
8. **看错误关键词。**重点区分 DNS、超时、连接重置、证书与下载失败。
9. **一次只改一个变量。**例如只切一个节点、只调整一条规则、只临时关闭 TUN，然后重新清空日志测试。
10. **确认修复后再收尾。**恢复不必要的测试设置，避免长期保留全局模式、调试日志或过于宽泛的规则。

这个流程的核心是“用证据缩小范围”，而不是连续尝试十几种设置。每次改动后都重新观察日志，才能知道是哪一步真正改变了结果。

分享日志截图时，哪些内容必须打码

向他人求助时，一张包含关键几行的日志截图往往比“就是打不开”更有效，但隐私保护同样重要。建议遮挡以下信息：

• 完整订阅链接、令牌和认证参数；
• 节点服务器地址、用户名、UUID、密码、公钥等配置内容；
• 本机公网 IP、局域网 IP、设备名称；
• 邮箱地址、账号 ID、订单信息；
• 访问记录中可能出现的私人域名、公司内部域名或 NAS 地址。

通常保留“报错关键词、目标域名的必要部分、规则命中结果、最终出口类型”就足够让别人协助判断。安全的求助信息应当最小化披露，而不是把整个配置文件或完整日志直接发出去。

结语：把日志当作导航，而不是错误清单

Clash 日志并不会自动替你修复网络，但它能告诉你问题到底在哪一段：流量有没有进入客户端、规则是否命中、DNS 是否正常、节点是否建立连接、请求是否被主动拦截。

当你养成“清空日志—复现问题—看域名、规则和出口—一次只改一项”的习惯后，许多看似复杂的故障都会变得可解释。比起频繁重装客户端或盲目更换配置，读懂关键日志更能让你的代理环境保持稳定、可控，也更容易保护自己的配置与隐私。