Clash 显示节点超时，只能说明某次连接或延迟测试没有在限定时间内得到有效响应，不能直接证明节点本身失效。问题可能发生在本地网络入口、订阅配置、节点服务器、策略组选择、DNS 解析、系统代理、TUN 路由或防火墙中的任意一层。若同时修改多个设置，原始故障点会被新变量覆盖，排查时间反而更长。
建议沿连接路径逐层验证：先确认设备能直接联网，再确认配置确实更新，然后检查节点与协议，随后核对代理模式和规则命中，最后处理 DNS、TUN、端口占用及安全软件。每完成一步都保留结果，能够把“所有网站打不开”缩小为明确的网络层、配置层或转发层问题。
一、先区分超时发生在哪一层
“超时”不是单一错误。客户端界面中的延迟测试、浏览器加载失败和日志中的连接超时，可能测试的是不同路径。部分客户端使用指定的 HTTP 或 HTTPS 地址测量延迟，这类测试包含 DNS、TCP 建连、TLS 握手和 HTTP 响应过程，并不等同于 ICMP Ping。测试地址暂时不可达时，节点仍可能可以转发其他请求。
常见现象与初步判断
- 全部节点同时超时：优先检查本地网络、测试地址、客户端内核、系统时间、防火墙和网络接口，不要先逐个更换节点。
- 只有一个节点超时：更可能是节点服务器、端口、协议参数或线路状态异常，可用同订阅中的其他节点进行对照。
- 延迟测试正常但网页打不开：重点检查系统代理是否启用、浏览器是否绕过代理、策略组是否选错、规则是否命中 DIRECT，以及 DNS 是否返回异常结果。
- 浏览器可用但其他应用不可用：浏览器可能读取了系统代理，而目标应用可能直连、使用独立代理设置，或需要 TUN 模式接管。
- 域名打不开但 IP 可以访问：优先定位 DNS。需要同时检查操作系统 DNS、Clash DNS 模块、加密 DNS 可达性及 fake-ip 行为。
- 开启 TUN 后全网中断：通常与默认路由、接口识别、权限、其他 VPN、虚拟网卡或 DNS 劫持冲突有关。
还应区分客户端界面与实际内核状态。图形客户端负责配置管理和系统集成，Clash Meta（现常以 mihomo 名称维护）等内核负责规则匹配、协议连接与转发。界面仍在运行，不代表内核已经成功启动。若日志出现配置解析失败、监听端口创建失败或权限错误，应先恢复内核运行，再测试节点。
二、确认本地网络入口与系统基础状态
关闭系统代理并暂停 TUN 后，直接访问一个平时稳定的网站。如果直连也失败，Clash 不是当前唯一变量。先检查 Wi-Fi 是否完成认证、网线接口是否获得地址、移动热点是否有数据连接，以及公司或校园网络是否需要网页认证。公共网络的认证页通常要求先直连打开，代理或加密 DNS可能阻止认证页面正常出现。
- 暂时退出其他 VPN、网络加速器、抓包工具和虚拟网卡软件，避免多个程序同时修改默认路由或 DNS。
- 重新连接当前网络，确认系统获得有效的 IP 地址、默认网关和 DNS 服务器。
- 检查设备日期、时间与时区。时间偏差过大会导致 TLS 证书验证失败，表现为订阅更新失败或 HTTPS 连接异常。
- 分别测试家庭宽带和手机热点。如果同一配置在热点可用、宽带不可用，问题更接近路由器、运营商路径或局域网策略。
- 重启客户端后查看内核启动日志，确认 HTTP、SOCKS 或 mixed 监听端口已建立。
网络切换后，旧接口和旧路由可能暂时保留。尤其在设备从有线网络切到 Wi-Fi、从公司网络切到热点后，TUN 自动识别的出口接口可能尚未更新。此时先关闭 TUN，等待系统路由稳定，再重新开启。若客户端提供“重启内核”或“重载配置”，优先使用这些操作，不必反复导入同一订阅。
三、检查订阅状态与配置是否真正生效
订阅更新成功提示只代表客户端完成了某个下载动作，不一定代表下载内容是有效的 Clash 配置。订阅地址过期、服务端返回登录页、响应被网络认证页替换、订阅格式与当前客户端不兼容，都可能导致节点列表为空或继续使用旧缓存。
先查看订阅更新时间、配置文件名称和节点数量。若节点名称、策略组和规则与服务端近期变更不一致，应手动更新并查看日志。出现 YAML 解析错误时，常见原因包括缩进层级错误、冒号后缺少空格、字符串中的特殊字符未被正确引用，以及配置引用了当前内核不支持的字段。
订阅检查顺序
- 确认订阅地址仍处于有效状态，账户对应服务没有到期或被暂停。
- 使用直连网络更新一次；若直连无法更新，再在已有可用代理下尝试，判断订阅服务器的访问路径。
- 核对响应内容是否为配置文本，而不是 HTML 登录页、错误页或网关认证页面。
- 确认客户端实际激活的是刚更新的配置，而不是历史配置、示例配置或另一份本地文件。
- 重载配置后检查策略组选择，因为组内节点名称变化时，旧选择可能被重置或指向不可用项。
不要在公开日志、截图或论坛内容中展示完整订阅地址、节点密码、UUID、证书字段或访问令牌。这些字段属于连接凭据。排障时通常只需保留协议类型、服务器是否为域名、端口范围、传输方式、TLS 状态和错误类别。
如果导入后内核无法启动，可以暂时切回上一份能够加载的配置，确认客户端和网络环境仍然正常，再比较两份配置的差异。对配置文件进行大范围删改之前，应保留原始副本。规则集、代理提供器或外部资源下载失败，也可能让配置加载过程停留在错误状态。
四、验证节点、协议参数与服务器路径
确认本地网络和配置正常后，再检查具体节点。先从同一订阅中选择两到三个不同地区、不同入口的节点进行测试。如果只有某一节点失败，可暂时从策略组中排除该节点；如果同一服务器下的多个端口都失败，则可能是服务器离线、入口域名解析异常或网络路径受阻。
节点参数必须整体匹配服务端，不能只保证地址和端口正确。不同协议还可能依赖密码、UUID、加密方式、TLS、SNI、ALPN、传输层、WebSocket 路径、gRPC 服务名或 Reality 相关参数。任何一个字段不一致，都可能在 TCP 建连后继续出现握手超时或连接被关闭。
从日志关键词定位阶段
i/o timeout：连接或读写在限定时间内未完成，需要结合目标地址和前一条日志判断是节点入口还是最终目标。connection refused：目标主机明确拒绝连接，通常表示端口未监听、服务未启动或中间设备主动拒绝。network is unreachable：系统没有可用路由，常见于接口切换、TUN 路由异常或 IPv6 路径不可用。no such host：域名没有得到有效解析，检查节点服务器域名和当前 DNS 链路。TLS handshake timeout：TCP 可能已建立，但 TLS 握手未完成，应核对网络质量、SNI、系统时间和服务端状态。authentication failed：连接凭据或协议参数不匹配，应重新获取订阅配置，而不是增加超时时间。
若节点服务器地址本身是域名，Clash 必须先解析该域名才能建立代理连接。此过程使用的 DNS 不能依赖尚未建立的同一代理链路，否则会形成启动依赖。mihomo 配置中的 proxy-server-nameserver 可用于解析代理服务器域名，但具体是否需要设置，应根据当前 DNS 方案和内核版本决定。
IPv6 也需要单独验证。网络可能能够获得 IPv6 地址，却没有稳定的 IPv6 出口；DNS 返回 AAAA 记录后，连接会等待不可用路径超时。可在排障阶段临时关闭客户端 DNS 的 IPv6 返回或切换到明确支持 IPv6 的网络进行对照。确认问题后，再决定保留 IPv4 优先还是修复 IPv6 路由。
五、核对代理模式、策略组与规则命中
节点可用不等于流量一定经过该节点。Clash 的规则模式会从上到下匹配规则，命中后交给对应策略组或动作。若目标域名被前面的 DIRECT 规则命中，切换另一个代理节点不会改变结果。排查时应打开连接记录，查看目标域名、目标 IP、命中规则、出站策略和实际节点。
可以短暂切换到全局代理模式进行对照：若全局模式可用、规则模式失败，重点检查规则顺序、规则集加载和策略组选择；若两种模式都失败，问题更接近节点、DNS、系统代理或网络入口。测试结束后应恢复原模式，避免让全部流量长期偏离预期规则。
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY上例展示了基本匹配顺序：特定域名规则在前，区域 IP 规则随后，MATCH 放在末尾处理此前未命中的连接。如果将宽泛的直连规则放在特定代理规则之前，后面的规则不会再被执行。使用远程规则集时，还要确认规则集已经下载并完成解析。
策略组名称同样需要一致。规则指向的组必须存在，组内应包含当前可用节点或其他有效策略组。自动选择组通常依据周期性测试结果选择节点，但测试地址不可达时可能得到错误判断。故障排查阶段可改为手动选择一个已经通过实际访问验证的节点，以排除自动策略波动。
六、定位 DNS 解析、fake-ip 与加密 DNS
DNS 故障常表现为节点测试有结果，但访问域名持续等待；也可能是浏览器显示名称解析错误，而连接 IP 地址能够建立。Clash 的 DNS 模块可接管查询并按配置返回真实 IP 或 fake-ip。系统 DNS、浏览器安全 DNS和客户端 DNS 同时启用时，查询路径容易分叉，因此必须先确认请求实际由谁处理。
DNS 排查要点
- 查看日志中是否出现 DNS 查询超时、名称不存在或上游服务器不可达。
- 临时关闭浏览器独立的安全 DNS，让浏览器跟随系统代理和系统 DNS，减少一条额外路径。
- 确认配置中的
nameserver在当前网络可达；加密 DNS 的域名本身也需要可用的引导解析。 - 若使用 fake-ip，检查目标应用是否兼容，并确认局域网设备、系统服务和需要真实 IP 的域名是否正确处理。
- 清理操作系统和浏览器 DNS 缓存后重新测试，避免旧记录掩盖配置变化。
dns:
enable: true
enhanced-mode: fake-ip
ipv6: false
nameserver:
- 1.1.1.1
- 8.8.8.8这段配置只用于说明字段关系，不应在所有网络中直接照用。部分网络无法稳定访问示例上游，企业网络也可能要求使用内部 DNS 才能解析内网域名。实际配置应选择当前网络可达、符合使用环境的服务器。若关闭 IPv6 后恢复访问，说明需要继续检查 IPv6 路由，而不是把所有节点故障都归因于 DNS。
fake-ip 模式会从保留地址池返回映射地址，再由内核还原域名并执行规则。某些依赖局域网发现、硬编码 DNS 或特殊网络检测的程序可能需要加入过滤范围。redir-host 模式返回真实解析结果，兼容路径不同，但也更依赖上游解析质量。切换增强模式会改变缓存和连接状态，测试时应重启内核并重新发起连接。
七、检查系统代理、监听端口与防火墙
浏览器通常读取系统代理，但部分应用只支持自身的 HTTP 或 SOCKS 设置，还有一些程序完全不读取系统代理。首先确认客户端显示的监听端口与操作系统代理设置一致。例如客户端监听 mixed 端口时，系统代理不能继续指向旧配置留下的端口。
端口被其他进程占用时，内核可能启动失败或改用其他端口。日志中若出现地址已被占用，应退出占用程序或调整监听端口，再同步更新系统代理。不要同时运行两个都会接管系统代理的 Clash 客户端，它们可能反复覆盖代理地址和绕过列表。
系统防火墙或终端安全策略可能阻止新内核访问网络、禁止监听本地端口，或限制 TUN 虚拟接口。更新客户端后，内核可执行文件路径变化，旧的放行记录不一定继续匹配。应在系统安全设置中核对当前程序路径和网络权限，并通过日志确认阻断时间与测试时间一致。
八、TUN 模式开启后无法联网的处理
TUN 模式通过虚拟网络接口接管更多系统流量，适用于不读取系统代理的应用和需要透明转发的场景。它比系统代理涉及更多路由、DNS 和权限变量，因此应在普通系统代理已经可用后再开启。若系统代理模式都无法连接，直接启用 TUN 通常只会增加排查层级。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: truemihomo 常见 TUN 配置包含自动路由和出口接口检测，但字段支持情况取决于内核版本与客户端封装。开启后应检查虚拟接口是否成功创建、默认路由是否生成、出口接口是否识别正确。Windows 可能需要相应权限；macOS 可能要求批准网络扩展；Linux 则涉及 TUN 设备、能力权限和策略路由。
若开启后立即断网，先关闭 TUN 恢复基础网络，然后退出其他 VPN 和虚拟网卡程序。重新启动内核，只开启一个网络接管工具。设备休眠、网络切换或拨号重连后出现问题时，可重启 TUN 或内核，让路由基于当前接口重新生成。
还应检查局域网绕过范围。打印机、路由器管理页和本地服务通常需要直连，错误接管后可能看似“网络全坏”，实际只是私有地址被送入代理。与此同时，过宽的绕过范围又可能让目标应用完全跳过代理。应通过连接日志判断流量是否进入内核，而不是仅凭应用界面推测。
九、用最小变量完成最终验证
经过逐层检查后，使用最小测试组合验证：一份能够成功加载的配置、一个手动选择的节点、一个明确的代理模式、一个稳定目标站点，以及一种网络入口。先验证浏览器，再验证需要 TUN 的应用。每次只改变一个变量，并记录改变前后的结果。
- 关闭 TUN，仅启用系统代理，确认浏览器请求出现在连接日志中。
- 手动选择已知可用节点，避免自动策略组在测试过程中切换。
- 分别测试规则模式和全局模式，判断是否为规则命中问题。
- 查看失败请求的域名、目标地址、命中规则、策略组、出站节点和错误时间。
- 切换到另一网络重复相同测试，判断故障是否与当前宽带或局域网相关。
- 基础代理稳定后再开启 TUN，并检查虚拟接口、路由和 DNS 是否发生预期变化。
如果需要提交故障信息，应包含操作系统版本、客户端版本、mihomo 或其他内核版本、配置来源类型、网络环境、复现步骤和经过脱敏的日志片段。日志应保留错误前后的上下文，但移除订阅地址、认证信息和节点凭据。只有“节点超时”四个字通常不足以判断故障层级。
完整排查顺序可以归纳为：直连网络可用性 → 内核启动状态 → 订阅与配置加载 → 节点协议参数 → 策略组和规则命中 → DNS 查询链 → 系统代理与端口 → 防火墙与权限 → TUN 路由。按照连接链路推进，比连续重装客户端或随机切换设置更容易得到可重复的结论。