Clash 节点超时无法连接：从订阅到 DNS 的排查顺序

先确认“超时”发生在哪一层

Clash 客户端显示 Timeout，不一定代表节点本身已经失效。订阅下载、配置载入、节点握手、DNS 查询、规则匹配、系统代理转发和 TUN 路由都可能产生相似表现。先记录故障范围，再逐项检查，通常比立即删除配置或重新安装更快。

第一步应当区分三个现象：订阅是否能够更新、节点延迟测试是否有结果、浏览器或其他应用是否能够访问目标网站。三者对应的链路并不相同。订阅更新失败多与订阅地址、网络入口或证书时间有关；所有节点延迟同时超时，常见于当前网络限制、DNS、核心未运行或测试地址不可达；只有部分节点失败，则更接近节点线路、端口或协议参数问题。

第一段：检查订阅有效性与配置载入结果

订阅是配置来源，不等同于节点本身。订阅地址过期、账号状态变化、下载返回登录页面、服务端临时错误，都会让客户端得到空内容或错误格式。此时继续测试节点没有意义，应先确认客户端确实下载到可解析的 YAML 配置。

查看更新时间与错误文字

1. 在配置或订阅页面查看最近更新时间，确认本次更新是否真正成功。
2. 如果客户端提示 HTTP 状态码，分别记录 401、403、404、429 或 5xx。不同状态代表授权、地址、频率限制或服务端故障，处理方向不同。
3. 确认订阅名称下存在代理节点和策略组，而不是只显示一个空配置。
4. 更新后重新选择一次当前配置，并确认 Clash 核心没有报告 YAML 解析错误。

配置解析失败常见于缩进、重复字段、不可识别的代理类型，或客户端核心版本不支持订阅中使用的字段。使用 Clash Meta（mihomo）配置时，应由支持相应字段的客户端载入。经典 Clash 核心与 mihomo 的功能范围不同，不能只看客户端外壳名称判断兼容性。

如果手动编辑过配置，可先切回服务端原始订阅进行对照。YAML 使用空格表示层级，Tab、错误缩进和复制时混入的符号都可能导致载入失败。对于由客户端管理的订阅，直接编辑缓存文件还可能在下次更新时被覆盖，因此自定义规则应放在客户端支持的覆写、扩展或配置合并位置。

第二段：判断节点、端口与当前网络是否可达

节点延迟测试通常会通过指定节点请求一个测试 URL，并测量响应时间。测试失败可能发生在域名解析、TCP 建连、TLS 握手、代理协议握手或目标网页响应阶段。部分客户端只显示 Timeout，需要配合日志才能找到具体位置。

先做交叉测试

• 同一订阅中选择三到五个不同地区、不同入口的节点，避免只测试一个节点。
• 在同一设备上切换家庭网络与手机热点。若热点可用而原网络全部超时，重点检查原网络的 DNS、路由、端口限制和网关设置。
• 在同一网络上使用另一台设备测试。若只有一台设备失败，问题通常位于本机权限、代理设置或防火墙。
• 如果客户端允许更换延迟测试地址，可选择稳定的 HTTPS 地址复测。单一测试站点不可达时，节点未必失效。

不要把 ping 结果直接等同于代理节点状态。服务器可能不响应 ICMP，但仍允许代理协议使用的 TCP 或 UDP 端口；反过来，能够 ping 通服务器，也不表示对应代理端口开放，更不表示认证和协议握手成功。

区分 TCP 与 UDP 问题

普通网页主要依赖 TCP 与 TLS，而部分游戏、语音、QUIC 和 DNS 场景会使用 UDP。网页能够打开但特定应用超时，可能是节点或协议未提供可用的 UDP 转发，也可能是 TUN 的 UDP 路由未生效。应先用普通 HTTPS 网页确认 TCP 代理，再单独验证需要 UDP 的应用，避免把两种问题混在一起。

若所有节点在某个网络下同时失败，而切换网络后立即恢复，通常不需要逐个删除节点。可先重启路由器、断开并重新连接网络，检查是否启用了其他 VPN、加速器或安全软件的网络过滤功能。多个工具同时创建虚拟网卡或修改路由表时，数据可能没有进入预期的 Clash 接口。

第三段：校准系统时间与证书验证环境

代理连接、订阅下载和 HTTPS 访问都可能涉及 TLS 证书验证。系统日期、时区或时间偏差过大时，证书会被判断为尚未生效或已经过期，客户端日志中可能出现 certificate、x509、handshake 等文字，也可能只表现为连接失败。

1. 打开系统的自动设置日期与时间功能。
2. 确认时区与所在地一致，尤其注意手动选择的 UTC 偏移。
3. 执行一次立即同步，然后完全退出并重新启动 Clash 客户端。
4. 如果设备由单位策略管理，确认时间同步服务能够访问，并检查系统证书存储是否正常。

双系统设备、长时间休眠的笔记本、恢复出厂设置后的手机，以及未联网较久的设备，更容易出现明显时间偏差。时间校准后，应重新更新订阅并测试节点，而不是只刷新浏览器页面。

第四段：排查 DNS 解析、Fake-IP 与污染缓存

DNS 故障常见的表现是：节点延迟偶尔正常，打开域名却超时；直接访问已知 IP 有响应，访问域名失败；日志连续出现 lookup、resolve、nameserver 或 context deadline exceeded。Clash 的 DNS 模块既可能解析代理节点服务器域名，也可能处理经过规则分流的目标域名，因此 DNS 出错会影响多个阶段。

先确认系统 DNS 能否工作

退出代理或临时关闭系统代理后，使用系统自带工具查询一个普通域名。命令只用于观察解析是否返回地址，不代表该网站一定能够完成访问。

nslookup www.example.com

如果查询本身超时，可尝试重新连接网络、刷新系统 DNS 缓存，或在路由器与设备网络设置中检查 DNS 地址。若系统查询正常而 Clash 日志中的 DNS 查询失败，再检查配置中的 dns、nameserver、fallback、proxy-server-nameserver 等字段是否受当前核心支持。

理解 Fake-IP 模式的边界

mihomo 常见的增强 DNS 模式包括 fake-ip 与 redir-host。Fake-IP 会先向应用返回保留地址，再由核心保存域名映射并完成后续分流。看到保留地址不一定是解析错误；真正需要检查的是请求是否进入 Clash、映射是否存在，以及目标域名是否按规则选择了正确出口。

某些局域网设备发现、企业内网域名、打印机地址和依赖真实 DNS 返回值的程序，不适合直接使用 Fake-IP。可以根据实际需要设置 Fake-IP 过滤规则，或对内网域名使用指定解析器。过滤范围应尽量明确，过宽的通配规则会削弱域名映射和分流效果。

节点服务器域名需要单独解析

如果代理节点的服务器字段本身是域名，核心必须先在代理通道建立前解析它。此时若配置让该查询依赖尚未连接的代理，就可能形成循环等待。mihomo 提供用于解析代理服务器域名的相关 DNS 配置能力，但具体字段需要与当前核心版本匹配。排查时可观察日志是否一直停留在节点服务器域名解析阶段。

第五段：核对系统代理、规则模式与 TUN 接管范围

节点可用但应用没有经过代理，通常是接管方式问题。Clash 的系统代理开关主要为遵循操作系统代理设置的程序提供 HTTP 或 SOCKS 入口；一些游戏、命令行程序、商店应用和自行实现网络栈的软件可能忽略系统代理。TUN 模式通过虚拟网卡与路由接管更多流量，但需要额外权限，也更容易与其他 VPN 或虚拟网卡发生冲突。

先用规则模式验证策略选择

在 Rule 模式下，流量会按配置中的规则从上到下匹配，命中后进入相应策略组。即使节点本身可用，如果规则把目标域名送往 DIRECT、REJECT 或一个未选择有效节点的策略组，访问仍会失败。打开连接记录或日志，确认目标域名命中了哪条规则、最终使用了哪个策略组和节点。

Global 模式会把大部分流量交给指定策略，但它适合诊断，不适合替代规则排查。若 Global 可用而 Rule 不可用，应检查规则顺序、规则集加载状态和策略组选择；若两种模式都失败，再回到节点、DNS 与本地端口检查。

系统代理排查顺序

1. 确认 Clash 核心处于运行状态，而不只是客户端窗口已经打开。
2. 确认系统代理开关已开启，并查看操作系统代理地址是否指向本机监听端口。
3. 确认配置中的 mixed-port、port 或 socks-port 与客户端显示一致。
4. 关闭浏览器内单独安装或配置的其他代理入口，避免请求被转发到旧端口。
5. 重启目标应用。部分程序只在启动时读取系统代理设置。

TUN 模式排查顺序

1. 确认客户端已获得创建虚拟网卡、修改路由或安装网络服务所需的系统权限。
2. 暂时退出其他 VPN、虚拟机网络工具和加速器，再重新启用 TUN。
3. 查看系统中是否出现对应虚拟网卡，并确认默认路由没有反复被其他程序覆盖。
4. 如果启用 TUN 后全网断开，先关闭 TUN 恢复网络，再检查 DNS 劫持、路由排除项和接口自动选择。
5. 局域网访问异常时，检查私有地址是否应直连，以及局域网网段是否被错误送入代理。

系统代理可用而 TUN 不可用，通常说明节点和基本代理协议没有问题，应把重点放在权限、虚拟网卡、路由与 DNS 接管。TUN 可用而系统代理不可用，则应核对本机监听端口、系统代理地址和应用是否读取代理设置。

第六段：检查本地监听端口、防火墙与端口冲突

Clash 核心需要在本机监听 HTTP、SOCKS 或 mixed 端口。若端口被另一进程占用，核心可能启动失败，也可能自动退出；若本地安全策略阻止程序监听或联网，客户端界面仍可能存在，但请求无法完成。

先在客户端日志中寻找 address already in use、bind、permission denied、connection refused 等信息。address already in use 通常表示端口冲突；connection refused 出现在访问 127.0.0.1 时，往往说明对应端口没有服务监听；远端连接出现 refused，则可能是节点端口关闭或服务器主动拒绝。

若配置使用常见的 7890 作为 mixed 端口，可用下面的请求验证本机代理入口。实际执行时必须把端口改成客户端当前显示的值。

curl -x http://127.0.0.1:7890 https://www.example.com/ -I

该请求成功，说明命令行程序能够连接本机代理端口，并完成一次 HTTPS 请求；如果浏览器仍失败，应检查浏览器代理、证书提示或扩展设置。如果请求立即提示无法连接本机端口，应先处理核心状态和端口监听，而不是继续更换远端节点。

防火墙检查要点

• 确认当前 Clash 客户端及其核心程序被允许访问当前类型的网络。
• 客户端升级后，可执行文件路径可能变化，需要重新确认系统防火墙规则。
• 单位或校园网络可能限制部分外连端口，可通过手机热点做交叉判断。
• 路由器上的家长控制、访问控制和 DNS 过滤也会影响节点服务器或订阅地址。
• 如果只在开启“允许局域网连接”后出现异常，检查监听地址与局域网防火墙规则，不要将本机代理端口暴露到不受信任网络。

第七段：用日志定位阶段，再进行最小化复测

日志的价值在于确认失败发生在哪个阶段。将日志级别临时调整到 info 或 debug 后，复现一次问题，随后恢复原级别，避免长时间产生大量记录。分享日志前应遮盖订阅地址、认证信息、节点凭据和可能包含个人访问记录的内容。

建立最小化测试路径

1. 保留一份可以正常载入的原始订阅配置。
2. 选择一个已确认可用的节点和一个稳定的 HTTPS 测试地址。
3. 先关闭 TUN，仅使用系统代理验证浏览器访问。
4. 系统代理通过后，再启用 Rule 模式并检查规则命中。
5. 最后开启 TUN，测试不读取系统代理的应用。
6. 每一步都记录日志变化，发现故障后停止增加新变量。

这套顺序能把问题分为配置来源、远端节点、域名解析、本机代理和全局接管五个范围。若最小化配置仍在多个网络下对所有节点超时，应向订阅服务提供方确认节点状态与协议参数；若只有原配置失败，则重点比较 DNS、规则、覆写和 TUN 字段。

节点超时排查清单

遇到 Clash 节点无法连接时，可按下面的固定顺序执行。前一项确认正常后再进入下一项，通常不需要反复安装客户端。

1. 确认设备本身能够直连普通网站，当前网络没有中断。
2. 确认订阅更新成功，配置中存在节点与策略组，核心载入没有 YAML 错误。
3. 测试多个节点，并用另一网络或另一设备进行交叉验证。
4. 开启自动时间与时区同步，排除 TLS 证书验证异常。
5. 分别检查系统 DNS、Clash DNS 和节点服务器域名解析。
6. 确认策略组选择、规则命中和代理模式符合预期。
7. 先验证系统代理，再单独检查 TUN 权限、虚拟网卡和路由。
8. 核对本机监听端口，处理端口占用与防火墙限制。
9. 根据日志关键词定位失败阶段，完成最小化复测。