Clash 节点超时无法连接:从客户端设置到本机网络的排查顺序

先判断是哪一种“超时”

Clash 显示超时，不等于问题一定发生在节点服务器。测速请求需要依次经过客户端内核、域名解析、本机网络、节点入口和测试网址，其中任何一步没有在限定时间内返回，都可能显示 Timeout。先缩小范围，再修改设置，比反复更新订阅更有效。

现象	优先怀疑	第一项检查
所有节点同时超时	内核未运行、入口域名无法解析、本机网络或防火墙拦截	检查内核状态与直连网络
只有一个节点超时	节点离线、端口关闭或单条协议参数错误	同订阅切换其他节点
测速超时但网页能打开	延迟测试地址不可达或测试超时时间过短	查看实际连接记录
浏览器可用，其他应用不可用	系统代理覆盖范围、应用绕过代理或 TUN 未接管	核对系统代理与 TUN 模式
开启 TUN 后全部断网	虚拟网卡、路由、DNS 劫持或权限问题	关闭 TUN，恢复基础代理测试

用对照测试区分节点问题与本机问题

保持当前订阅不变，连续测试至少 3 个不同地区、不同入口的节点。
关闭 Clash 的系统代理与 TUN，直接打开一个平时可访问的网站，确认基础网络正常。
重新启动 Clash 内核，只开启系统代理，再测试浏览器访问。
将同一订阅临时导入另一台设备或另一条网络，例如手机热点，比较结果。

如果同一节点在家庭宽带超时、手机热点可用，问题更可能位于本机、路由器或当前网络出口。如果多台设备、不同网络都只有同一个节点失败，而同订阅其他节点正常，通常应将范围收敛到该节点的入口、端口或协议参数。

第一步：确认客户端内核、配置与代理端口

排查全部节点超时时，先确认 Clash Meta（mihomo）内核已经成功启动。图形界面能够打开，不代表内核正在监听端口。若日志出现 address already in use、configuration file test failed 或持续重启，应先处理端口冲突和配置错误。

检查内核状态与当前配置

以 Clash Verge Rev 2.4.2 的常见界面为例，可在「设置」→「Clash 设置」查看当前内核与端口，在「订阅」中确认正在使用的配置。不同客户端的名称可能是「内核」「配置」或「Profiles」，判断标准一致：配置处于启用状态，内核状态为运行中，日志没有循环报错。

Mixed Port：常见值为 7890，同时接受 HTTP 与 SOCKS5 请求。
HTTP Port：旧配置中常见 7890。
SOCKS Port：旧配置中常见 7891。
External Controller：常见监听地址为 127.0.0.1:9090，它是控制接口，不是应用代理端口。

不要把浏览器代理填写成控制端口 9090。如果配置只声明 mixed-port: 7890，浏览器或系统代理应指向 127.0.0.1:7890。修改端口后，还要同步更新系统代理、浏览器扩展和其他手动设置。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

排除端口占用

Windows 可在 PowerShell 中检查 7890 端口是否已有进程监听：

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess

macOS 与 Linux 可使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

如果旧版 Clash、其他代理工具或残留后台进程占用同一端口，应先退出冲突程序，再重启当前客户端。不要同时让两个程序写入系统代理，否则界面显示的端口与操作系统实际使用的端口可能不一致。

第二步：从系统代理缩小到 TUN 模式

基础排查应先使用系统代理，不要一开始就开启 TUN。系统代理链路更短，便于确认节点是否能够建立连接。以 Clash Verge Rev 2.4.2 为例，进入「设置」→「系统设置」→「系统代理」，开启后检查系统代理服务器是否为 127.0.0.1，端口是否与 Mixed Port 一致。

浏览器正常但应用仍直连

系统代理只对主动读取操作系统代理设置的应用生效。部分游戏、命令行工具、虚拟机和使用自有网络栈的软件会忽略系统代理。此时浏览器可以正常访问，并不能说明所有应用都已被接管。

先在 Clash 的「连接」面板中搜索目标域名或进程。
看不到任何记录，通常表示流量没有进入 Clash。
能看到记录但状态反复为连接中，继续检查节点入口与 DNS。
记录显示 DIRECT，应检查规则命中结果，而不是更换节点。

TUN 开启后全部超时

TUN 模式通过虚拟网卡和路由规则接管更多流量。Windows 通常需要管理员权限与可正常加载的虚拟网卡驱动；macOS 首次启用时需要批准网络扩展；Linux 则需要 /dev/net/tun 与相应网络管理权限。

如果关闭 TUN 后系统代理可用，说明节点本身大概率正常。此时应单独排查 TUN，而不是继续修改订阅。按以下顺序恢复：

关闭 TUN，退出客户端，确认系统网络恢复。
重新启动客户端，先验证 Mixed Port 代理可用。
以所需权限启动客户端，再开启 TUN。
检查是否同时运行 VPN、虚拟机桥接、流量过滤器或另一套 TUN 软件。
若出现域名打不开但 IP 可访问，转入 DNS 排查。

第三步：检查 DNS 与节点入口域名

节点地址既可能是 IP，也可能是域名。使用域名作为服务器地址时，Clash 必须先通过本地解析器或配置中的默认解析器获得入口 IP。如果入口域名解析失败，所有依赖同一入口的节点会一起超时，即使代理协议参数完全正确。

先在操作系统层检查解析

Windows 可执行：

nslookup node.example.com
Resolve-DnsName node.example.com

macOS 或 Linux 可执行：

dig node.example.com
nslookup node.example.com

node.example.com 应替换为配置中节点的实际 server 值。如果返回 NXDOMAIN、超时或没有 A/AAAA 记录，应先确认订阅中的入口域名是否仍有效。若多个失败节点共用一个入口域名，这项检查尤其重要。

区分入口解析与代理内 DNS

Clash 的 DNS 配置既负责应用域名解析，也可能参与节点入口解析。mihomo 配置中的 default-nameserver 主要用于解析 DNS 服务器自身及节点入口等基础目标，通常应填写可直接访问的 IP 形式 DNS 地址，避免形成“需要代理才能解析代理入口”的循环依赖。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query

这段内容只用于说明配置层级，并不表示每个网络都适合相同解析器。企业网、校园网或带有内网域名的环境，可能必须保留局域网 DNS。修改前应保存原配置，修改后重新载入，并观察日志中是否出现 lookup、no such host 或 DNS 请求超时。

如果只有 IPv6 入口失败，可暂时验证当前网络是否具备可用 IPv6 路由。解析得到 AAAA 记录不代表本机一定能连接 IPv6。不要长期依赖随意关闭 IPv6 来掩盖问题，应进一步确认路由器、运营商链路和节点入口实际支持情况。

第四步：单个节点超时时核对协议参数

只有一个节点失败，而同订阅其他节点可用时，本机系统代理和基础 DNS 通常没有大问题。重点应转向该节点的服务器地址、端口与协议字段。重新导入订阅可以排除手工编辑造成的字段丢失，但不能修复服务器离线或订阅源本身的数据错误。

协议或传输	重点字段	常见错误表现
Shadowsocks	server、port、cipher、password	加密方式或密码不一致，连接建立后立即失败
VMess	uuid、alterId、cipher、network、tls	UUID、传输层或 TLS 设置不匹配
VLESS	uuid、flow、servername、network	SNI、flow 或传输方式错误
Trojan	password、servername、skip-cert-verify	证书名称与 SNI 不一致
WebSocket	path、Host 请求头、TLS	路径或 Host 不一致，握手被拒绝
gRPC	service-name、servername、TLS	服务名不一致或中间网络不支持
Reality	servername、public-key、short-id、fingerprint	握手参数不匹配，日志出现 TLS 相关错误

不要凭经验随意切换 tls、udp 或 skip-cert-verify。这些字段必须与服务端配置对应。尤其不应把跳过证书验证当作通用修复手段；它可能让错误暂时隐藏，却无法解决 SNI、证书期限或系统时间不正确的问题。

检查本机时间

TLS 握手依赖准确时间。Windows 可进入「设置」→「时间和语言」→「日期和时间」，启用自动设置时间并执行立即同步。macOS 可进入「系统设置」→「通用」→「日期与时间」，开启自动设定。系统时间偏差数分钟就可能导致证书尚未生效或已经过期的判断。

确认节点端口能否到达

Windows PowerShell 可针对节点服务器与端口执行 TCP 探测：

Test-NetConnection node.example.com -Port 443

macOS 或 Linux 可使用：

nc -vz node.example.com 443

TCP 测试成功只说明入口端口可建立连接，不代表 UUID、密码、TLS 或传输参数正确。测试失败则可能是服务器未监听、入口地址失效、防火墙丢弃或当前网络限制。部分 UDP 协议也不能用 TCP 探测直接判断，需要结合内核日志与其他网络对照测试。

第五步：排查防火墙、路由器与当前网络

当所有节点都失败，且配置能在另一台设备上正常使用时，应检查本机安全策略。Windows 防火墙可能允许图形界面联网，却阻止实际运行的 mihomo 内核；第三方安全软件也可能按进程路径建立规则，客户端升级后内核文件路径变化，旧放行规则不再匹配。

Windows 检查顺序

打开「Windows 安全中心」→「防火墙和网络保护」→「允许应用通过防火墙」。
确认当前 Clash 客户端与 mihomo 内核在正在使用的网络类型下获得访问权限。
进入「设置」→「网络和 Internet」→「代理」，检查是否残留失效的手动代理。
退出其他 VPN、代理与网络过滤程序，再重新启动 Clash。
使用手机热点复测，判断问题是否只出现在当前路由器或宽带。

临时关闭防火墙只能作为短时间对照测试。确认是规则导致后，应恢复防火墙并为实际内核程序建立明确规则，而不是长期保持关闭状态。

路由器与网络出口

路由器的家长控制、访客网络隔离、企业出口 ACL、公共 Wi-Fi 认证页都可能影响节点连接。先打开普通 HTTP 与 HTTPS 网站，确认认证流程已经完成。若连接手机热点立即恢复，可依次检查路由器 DNS、IPv6、MTU、访问控制和上游网络限制。

MTU 问题常表现为 TCP 能建立、TLS 或大数据包阶段卡住。TUN 环境下若小网页偶尔可开、图片和下载长期停滞，可将 MTU 作为后续检查项，但不应在没有对照结果时随意修改。先记录原值，再按客户端支持的配置逐步调整，每次变化控制在较小范围。

日志怎么读：用错误关键词定位阶段

将日志级别暂时设为 info 通常已经足够。只有需要追踪规则与握手细节时再短时使用 debug，完成后恢复，避免日志快速增长。复现问题时记录准确时间、节点名称和目标域名，再搜索同一时间附近的信息。

日志关键词	含义方向	下一步
no such host	域名解析失败	检查入口域名与 DNS
i/o timeout	限定时间内没有完成网络操作	检查入口可达性、防火墙与网络对照结果
connection refused	目标主机明确拒绝连接	检查服务器端口与节点状态
network is unreachable	本机没有对应路由	检查 IPv4、IPv6、TUN 与默认路由
certificate	TLS 证书校验异常	检查系统时间、servername 与证书状态
address already in use	本地监听端口冲突	结束占用进程或更换端口

i/o timeout 只是结果，不直接指出责任方。必须结合它前面的目标地址判断：如果超时目标是节点入口，检查节点和本机出口；如果目标是 DNS 服务器，检查解析链路；如果只在延迟测试网址出现，而其他连接正常，则应检查测速地址。

固定排查顺序与恢复标准

完整流程可以压缩成八步。按顺序执行，并在每一步记录结果：

确认直连网络：关闭系统代理与 TUN，验证基础网络正常。
确认内核运行：检查配置加载、端口监听与启动日志。
只开系统代理：使用 127.0.0.1:7890 等实际 Mixed Port 测试。
横向测试节点：比较至少 3 个节点，区分单节点与全局故障。
检查入口解析：查询节点域名，核对 IPv4、IPv6 和 DNS 日志。
核对协议字段：只针对单节点检查端口、TLS、SNI 与传输参数。
更换网络复测：使用手机热点区分本机、路由器与当前出口。
最后恢复 TUN：基础代理稳定后，再检查虚拟网卡、路由与 DNS 接管。

恢复标准不只是节点延迟出现数字。至少应同时满足：客户端内核稳定运行；网页请求出现在连接面板；规则命中符合预期；连续打开多个目标没有间歇超时；切换节点后新连接使用新的策略。若只恢复测速而实际连接仍失败，排查还没有结束。