先固定一次失败请求

FlClash 的日志通常来自 Clash Meta（mihomo）内核和客户端自身。日志页出现 warning，不等于整个代理已经失效；后台应用、节点健康检查、订阅更新和浏览器请求可能同时产生日志。有效排查的起点，是把一条失败记录与一次实际操作对应起来。

  1. 记下当前配置名称、出站模式、策略组所选节点，以及系统代理和 TUN 模式的开关状态。
  2. 打开 FlClash 的日志页，暂停其他下载，只访问一个可以稳定复现问题的地址。
  3. 记录操作时间，保留前后约 10 秒的日志。重点看目标域名、目标端口、匹配规则、策略组和最终出站。
  4. 每次只修改一个条件，再用相同地址重试。例如先换节点，不同时改 DNS 和 TUN 栈。

以下日志是用于解释字段的示意，不是某次实测结果。不同内核版本的字段顺序和措辞可能不同。示例中的 192.0.2.10 属于文档示例地址，不可作为可连接节点；127.0.0.1:7890 也只是本地端口示例，应替换成当前配置实际监听的端口。

日志级别：先看请求，再看严重程度

mihomo 的 log-level 常用值包括 debug、info、warning、error 和 silent。级别决定输出范围，不是故障原因：一条 warning 可能是健康检查失败，一条 info 则可能揭示目标请求走错了出站。

级别主要用途处理方式
debug补充解析、连接等细节短时启用，复现后恢复
info观察规则与出站路径作为日常排查起点
warning连接、解析等异常提示核对是否对应失败请求
error配置或运行中的错误优先查看具体错误上下文
silent抑制内核日志输出排查期间改用 info 或 debug

需要更多细节时，可在客户端提供的日志级别设置中临时调整；若编辑配置，则检查最终生效配置里的 log-level: debug。不要只改订阅缓存文件，客户端重新生成配置或更新订阅后，修改可能被覆盖。完成排查后恢复 info，减少持续记录的请求信息。

dial tcp 超时：确认正在连接谁

dial tcp 192.0.2.10:443: i/o timeout
dial tcp 127.0.0.1:7890: connect: connection refused

dial tcp 表示建立 TCP 连接。关键不只是后面的 timeout，而是前面的地址究竟属于代理节点、直连目标，还是本地代理服务。走代理时，错误里可能出现节点服务器地址；走 DIRECT 时，则可能是目标网站地址。仅凭这一行不能断言“网站被阻断”或“订阅失效”。

i/o timeout 与 connection refused 的区别

  • i/o timeout：连接或相关网络操作在期限内没有完成。节点不可达、丢包、路由异常或防火墙静默丢弃，都可能导致超时。
  • connection refused：收到拒绝连接的结果。常见于端口没有服务监听、服务器端口配置不符，或设备明确拒绝连接。
  • network is unreachable：当前系统缺少到目标网络的可用路由。若只出现在 IPv6 地址，需单独检查本机 IPv6 连通性。

用两个对照缩小范围

先保持网络不变，手动选择另一个节点，再创建新的请求。如果仅一个节点持续超时，优先检查该节点的服务器地址、端口和服务状态。再保持节点不变，将 Wi-Fi 换成手机热点测试；若只有原网络失败，本地出口或运营商路径更值得检查。这些对照只能缩小范围，不能单独证明具体设备发生故障。

节点延迟测试成功也不代表全部网站都能打开。测试通常只覆盖指定探测地址和一条连接路径，不能代替实际业务请求。策略组切换后，已有长连接还可能沿用原出站，应重新加载页面或重新建立连接后再判断。

DNS 解析失败：区分节点域名与网站域名

lookup example.com: no such host
dns resolve failed: context deadline exceeded

no such host 通常表示解析路径报告该名称不存在或没有得到可用地址；context deadline exceeded 表示相关操作超出期限。后者不是 DNS 专属错误，必须结合附近的 DNS 字段判断。先确认失败域名属于节点服务器还是访问目标，两者影响范围不同。

节点服务器域名失败

节点地址本身需要先解析，才能建立代理连接。如果解析它的 DNS 上游又被配置成必须经过这个节点，就可能形成依赖循环。检查有效配置中的 proxy-server-nameserver 等节点域名解析设置，以及相关 DNS 上游是否存在可达的启动路径。不要把所有解析请求盲目强制送入尚未建立的代理。

目标网站域名失败

检查 dns 段中的 nameserver、nameserver-policy，以及使用时的 fallback。若启用了 respect-rules，还要检查 DNS 请求所走的规则路径。DoH 地址通过 HTTPS 请求工作，配置成 https:// 并不意味着它在当前网络里一定可达。

  • 仅某个域名失败：核对拼写、域名定向解析策略与上游返回结果。
  • 所有目标域名失败，但节点可连接：优先检查目标域名解析链路与 DNS 上游。
  • 开启 TUN 后才失败：检查 DNS 劫持、系统解析器和其他网络软件的接管关系。

握手失败：分清证书、协议与断连

tls: failed to verify certificate: x509: certificate has expired or is not yet valid
tls: first record does not look like a TLS handshake
EOF

TCP 能连接，只说明传输层入口可达。节点协议、TLS、身份验证和目标网站连接仍可能在后续阶段失败。日志中的 TLS 错误可能来自代理传输，也可能来自 DNS 上游或其他 HTTPS 请求，需先确定报错对象。

  • 证书过期或尚未生效：先检查系统日期、时间和时区，再检查服务端证书有效期。设备时间偏差也会触发验证失败。
  • 证书名称不匹配：检查节点的 servername、实际服务端证书与订阅参数是否一致，不要随意用服务器 IP 替代要求的域名。
  • 首个记录不像 TLS：可能连接到了非 TLS 服务，或中间设备返回了其他内容。核对端口与 TLS 开关，不能仅凭此句认定密码错误。
  • EOF 或 connection reset by peer：表示对端关闭连接或连接被重置。它们不直接说明关闭原因，需要结合握手前后的记录与服务端状态。

如果订阅刚更新后所有同类节点都失败，先确认客户端所带内核支持该协议及其参数，再核对订阅来源提供的配置要求。不要把 skip-cert-verify: true 当成通用修复；跳过证书验证会降低身份校验强度，也解决不了端口、认证或传输类型不匹配。

规则未命中：先看模式，再看最终出站

“规则未命中”经常是用户对现象的描述，并不是固定的内核错误。规则模式下，规则通常按顺序匹配，命中后使用对应策略；GLOBAL 与 DIRECT 模式则不按普通规则列表执行分流。应先确认当前模式，再读连接记录中的匹配类型和策略链。

proxy-groups:
  - name: Web
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Web
  - MATCH,DIRECT

这段是规则关系示例，不是完整可用订阅。访问 www.example.com 会命中 DOMAIN-SUFFIX 并进入 Web 策略组，但该组此处只有 DIRECT，所以最终仍是直连。由此可见，“命中代理组”不等于“通过远端代理节点”。真实排查要继续查看策略组当前选择，而不是停在规则名称。

  • 日志命中 MATCH：检查更前面的规则是否覆盖该域名，外部规则集是否成功加载，以及应用连接时是否保留了域名信息。
  • 域名规则未触发：应用可能直接连接 IP；嗅探也不是所有协议都能恢复域名，不宜把嗅探视为必然补救。
  • 规则指向 REJECT：确认是否是主动拦截。此类失败应回到规则意图处理，不必先换节点。
  • 修改后仍走旧路径：确认正在运行的是刚修改的 Profile，并使用新连接复测。

需要梳理引用关系时，可查看本站进阶配置中的规则说明。修改订阅规则前先确认持久化方式，避免订阅更新覆盖本地改动。

TUN 与端口异常：定位本机入口

listen tcp 127.0.0.1:7890: bind: address already in use
operation not permitted

address already in use 说明监听地址和端口发生冲突。先退出其他代理客户端，检查旧进程是否仍在运行，再核对 FlClash 的实际端口。如果改了监听端口，还需同步检查系统代理和手动填写代理地址的应用，不能只改配置中的一个数字。

operation not permitted 出现在创建虚拟网卡或修改路由附近时，通常应优先检查权限。桌面系统的 TUN 操作可能需要管理员授权或客户端配套服务；Android 通常需要授予 VPN 连接权限。其他 VPN 或安全软件也可能参与网络接管。

  1. 记录当前状态，暂时关闭其他 VPN 与代理客户端。
  2. 关闭 TUN，仅用系统代理测试浏览器，判断节点与基本代理入口是否正常。
  3. 再单独启用 TUN，观察是否出现网卡、权限或路由错误。
  4. 如果只有 TUN 失败，优先检查本机接管链路，不要立即重置全部订阅和 DNS。

系统代理测试成功，只能证明参与该测试的应用路径正常，不能证明所有 UDP、游戏或后台程序都能通过。TUN 栈选择应结合操作系统和内核支持情况逐项比较，不存在对所有设备都最优的固定选项。

提交排查信息：保留上下文，隐藏凭据

有效反馈应能复现问题，而不只是附上一屏 error。建议提供操作系统与架构、FlClash 版本、内核版本、当前模式、TUN 状态、错误发生时间，以及“换节点”和“换网络”的对照结果。版本信息以客户端实际显示为准，不要把文章日期当成版本依据。

  • 操作：例如“打开同一 HTTPS 地址，新建连接后约 10 秒失败”。这里的秒数应填写实际观察结果。
  • 范围：一个节点失败还是全部节点失败；一个网站失败还是多数网站失败。
  • 日志：保留故障前后相关片段，包括规则、出站与最终错误，避免只截最后一行。
  • 隐私：隐藏订阅链接、令牌、密码、UUID 和敏感域名。不要公开完整订阅配置。

最后按链路归类：没有请求记录，查流量入口；节点域名解析失败，查启动解析路径；节点 TCP 超时，查节点和网络；握手失败，查协议与证书；出站与预期不同，查模式、规则和策略组。沿着同一次请求逐层确认，比同时切换多个开关更容易得到可重复的结论。