先确认：超时发生在测速，还是实际访问
打开客户端的「代理」页，记下当前策略组和选中的节点，再到「日志」页查看一次失败请求。不同客户端可能把这两个页面命名为「代理组」和「运行日志」，以实际界面为准。先不要重装，也不要一次更改 DNS、规则和端口。
节点测速通常是让内核经指定节点请求一个测试地址，再按客户端设定计算延迟。显示 timeout，只能说明这次测试没有在限定时间内完成。测试地址不可用、DNS 查询失败、节点握手失败，都可能得到相同结果。
- 测速超时，网页能打开：先检查测试 URL 和测试超时时间，不要直接删除节点。
- 测速有延迟，某个应用打不开：优先检查分应用代理、规则命中和应用自己的网络设置。
- 所有节点超时，所有代理访问都失败：按下文顺序检查公共环节，先看本机网络，再看订阅和 DNS。
- 只有一个节点失败：先对比另一个不同服务器地址的节点，不必立即改整份配置。
第一步：停止代理，检查本机网络和 VPN 接口
先让手机在直连状态下正常联网
- 在客户端首页停止连接，确认 Android 状态栏的 VPN 标识消失。
- 打开平时可直接访问的网站。公共 Wi-Fi 若跳出认证页，先完成登录，再启动客户端。
- 断开 Wi-Fi，改用移动数据测试同一个节点。随后切回 Wi-Fi，保持其余设置不变。
- 如果只有某个 Wi-Fi 失败，记录这个差异。不要立刻把所有节点判为失效。
Android 的 VpnService 是供应用建立本机 VPN 接口的系统机制。普通个人用户环境下，同一用户通常只能有一个活动的 VPN 服务。另一个 VPN、防火墙或使用 VPN 接口的过滤应用，可能挤掉 Clash 的接口。先停止这些服务，再重新连接。
排除系统设置阻断直连
打开 Android「设置」→「网络和互联网」→「VPN」→ 当前客户端旁的设置按钮，检查「始终开启 VPN」及「阻止未使用 VPN 的连接」。部分系统把入口放在「连接与共享」中。若启用了阻断选项，停止客户端后无法联网可能是系统按设置执行，并非 Wi-Fi 本身故障。需要直连对照时，可临时关闭该选项；测试期间流量可能绕过代理，测试完再按需要恢复。
如果只在锁屏后断开，先解锁并重新启动服务，再到「设置」→「应用」→ 当前客户端 →「电池」检查后台限制。这类现象应与持续发生的节点握手超时分开记录。
第二步：确认订阅更新成功，配置确实已启用
打开「配置」页，手动更新当前订阅，查看更新时间和错误提示。订阅是取得节点与规则的配置来源；更新失败与代理连接失败不是同一件事。旧配置可能继续可用，更新成功也不代表订阅内的每台服务器都能连接。
- 确认当前启用的是刚更新的配置，而不是同名的旧导入文件。
- 进入订阅服务方的管理页面，检查到期时间、剩余流量、设备或连接数限制。
- 查看更新错误：HTTP
401或403通常涉及授权或访问策略，404表示请求的地址不存在；具体原因仍需结合响应内容判断。 - 若出现 YAML 解析错误或不支持的代理类型，先解决配置加载失败，再进行节点测速。
YAML 是 Clash 配置常用的文本格式，缩进参与结构解析。不要把订阅地址直接当作节点服务器地址，也不要把返回的登录页面保存成配置。界面显示「已下载」但随后报解析错误，往往意味着拿到的不是客户端能使用的配置内容。
第三步：区分节点域名解析和目标网站解析
DNS 是把域名转换为 IP 地址的查询过程。一次代理访问可能先解析节点服务器域名，再由本地或远端解析目标网站。两处任何一处失败，都可能被界面归为连接超时。先看日志中报错的域名属于哪一端。
| 观察到的现象 | 先查哪里 | 下一步 |
|---|---|---|
| 节点服务器域名提示找不到主机 | 启动连接前的 DNS 路径 | 确认本机能解析该域名，检查解析请求是否错误地依赖这个尚未连通的节点 |
| 节点握手成功，访问特定网站时报解析错误 | 目标域名的 DNS 与规则 | 对比另一个目标网站，查看 DNS 配置与连接日志 |
| 仅开启 Android 私人 DNS 后失败 | 系统私人 DNS 的可达性 | 临时改为自动，再用同一网络复测 |
| 切换网络后仍使用旧解析结果 | 应用与内核缓存 | 停止并重启服务，再重复一次相同请求 |
Android 可在「设置」→「网络和互联网」→「私人 DNS」查看系统设置。私人 DNS 通常使用加密的 DNS over TLS；它与配置文件中的 DNS over HTTPS 不是同一个开关。把系统私人 DNS 临时设为「自动」，只用于对照，不等于客户端内部 DNS 一定已恢复。
mihomo 是兼容 Clash 配置生态的一种代理内核。其 DNS 配置中，proxy-server-nameserver 可指定节点服务器域名的解析器，default-nameserver 用于解析 DNS 服务自身的域名等引导场景。字段是否生效要看实际内核支持，不能只按客户端外壳名称判断。不要把所有解析请求都强制送进当前无法连接的代理，否则容易形成启动依赖循环。
不要随意将节点域名改成网上找到的 IP。TLS 的服务器名称验证、SNI，以及 CDN 或负载均衡选路都可能依赖原域名。SNI 是握手时告知服务器所访问名称的字段；改成 IP 后，TCP 能接通也未必能完成正确的 TLS 握手。
第四步：校准系统时间，检查 TLS 错误
打开「设置」→「系统」→「日期和时间」，启用「自动设置时间」和「自动设置时区」。部分系统入口叫「更多设置」→「日期和时间」。确认日期、年份与当前实际时间一致，再重新启动连接。
TLS 是用于加密连接与验证服务器身份的协议。证书具有有效期，部分代理协议还对时间差敏感。日志若出现 certificate has expired or is not yet valid，应先核对本机时间，再检查服务端证书；不能仅凭这行错误断言手机时间有问题。
x509: certificate signed by unknown authority：可能是证书链不完整、自签证书，或连接被中间设备接管。- 证书名称不匹配：检查节点域名与服务方要求的服务器名称是否一致。
- 时间正确但仍有证书错误：保留日志，交由服务方检查证书部署和入口地址。
不要为了让错误消失就长期开启 skip-cert-verify。跳过证书验证会削弱服务器身份检查，既不能修复端口不通，也不能解决错误的协议参数。
第五步：核对协议、服务器端口和内核支持
在节点详情中查看协议类型、服务器地址和服务器端口，再到客户端「关于」或内核信息页记录实际内核版本。Clash 外壳与内核不是同一个版本概念；客户端能导入配置，不代表运行内核支持其中全部协议和字段。
不要混淆本地监听端口和远端端口
- 本地端口：例如配置中的
mixed-port: 7890，供本机应用接入 HTTP 或 SOCKS 代理。7890 只是常见示例，以当前配置为准。 - 服务器端口：节点详情里的
port，用于连接远端服务。它可能是 443，也可能是服务方分配的其他端口。 - 管理端口：
external-controller属于控制接口，不是供浏览器访问网站的代理入口。
把本地 7890 改成 7891，不能修复远端服务器端口被阻断的问题。若日志出现 address already in use，才应检查本地端口是否被占用、是否重复启动了服务。
按传输方式做对照
Hysteria2、TUIC 等协议依赖 UDP。某些网络对 UDP 的限制会使这类节点失败，而基于 TCP 的节点仍可工作。选一个服务方明确提供的 TCP 节点，在同一网络下对照；不要只把节点配置中的 UDP 开关关闭，就认为协议已转换成 TCP。
对使用 WebSocket 或 gRPC 的节点，还要核对传输路径、Host 或服务名称。收到 HTTP 400、404 或握手响应异常，可能是入口参数不匹配，也可能是服务器反向代理配置问题。优先重新获取兼容当前内核的订阅，不要逐字段猜改。
第六步：看实际流量有没有进入正确的策略组
打开「连接」页，再在浏览器访问一次目标网站。检查是否出现该请求，以及显示的规则、策略组和最终节点。Rule 模式按配置规则选择直连或代理；选中节点只影响对应的策略组，不会覆盖所有直连规则。
- 若请求没有出现，检查 Android 分应用代理是否排除了浏览器，并确认 VPN 服务确实在运行。
- 若请求命中
DIRECT，先检查对应规则，而不是反复切换代理组里的节点。 - 若请求进入了其他策略组，到那个组里确认实际选中项，注意组内可能仍选着
DIRECT或旧节点。 - 可短时切换 Global 模式做对照，并选择一个明确的节点。测试后恢复 Rule，避免把临时状态当作最终配置。
Global 模式用于对照代理选择，并不保证接管所有设备流量。被分应用设置排除的应用、根本没有进入代理接口的流量，不会因为切换模式自动出现。桌面端的 TUN 是虚拟网络接口接管方式，Android 客户端一般通过 VpnService 接收流量；两者都不能修复失效的服务器或错误的凭据。
桌面端辅助检查：指定本地代理端口
若同一份订阅也在电脑上使用，可以在电脑终端执行下面的命令。示例假定电脑客户端的 HTTP 或 mixed 端口确实为 7890，测试目标为 https://example.com/；该目标本身也必须可用。这不是 Android 系统自带的测试步骤。
curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/127.0.0.1 始终表示运行命令的设备本身。电脑上的命令不会自动连到手机客户端。若要让其他设备接入，还涉及局域网监听和访问控制，不建议在此次排障中额外开启。命令得到 HTTP 响应，只说明这一条测试路径可用，不能证明所有应用都已走代理。
日志报错速查：先找连接链中最早的失败
到「日志」页临时把级别调为 info；信息不足时再短时使用 debug。清楚记录一次请求的时间，复现后保留附近日志。不同内核的文字会有差异，下表用于判断排查方向，不替代完整上下文。
| 日志片段 | 通常表示 | 下一项检查 |
|---|---|---|
lookup … no such host | 域名查询未得到有效记录 | 报错的是节点域名还是目标域名，DNS 返回了什么 |
dial tcp … i/o timeout | 到指定地址的 TCP 连接未按时建立 | 服务器地址、端口、当前网络和远端状态 |
connection refused | 连接尝试收到了拒绝响应 | 目标端口是否有服务监听，防火墙是否主动拒绝 |
TLS handshake timeout | TLS 握手未在时限内完成 | 链路丢包、服务器负载、TLS 入口和名称参数 |
authentication failed | 认证未通过 | 订阅状态、密码或 UUID，以及协议要求 |
connection reset by peer | 连接被对端或链路中的设备重置 | 协议参数、服务端日志及换网络后的差异 |
EOF | 读取时连接已结束 | 前面的握手与认证错误，不能单独据此判定原因 |
例如先出现节点域名解析失败，再出现测试超时，应先处理 DNS；不要把最后一行超时当作唯一原因。完成排障后恢复常用日志级别，避免长期保留大量访问记录。
仍然全部超时：整理可复现的反馈
如果直连正常、订阅有效、时间准确，且至少两台不同服务器在 Wi-Fi 和移动数据下都失败，再把证据交给订阅服务方或客户端维护者。多条节点若共用同一个入口域名，不能算完全独立的服务器对照。
- 环境：Android 版本、客户端名称和版本、内核名称和版本，按实际界面填写。
- 时间：失败的日期、具体时分及所在时区，方便对照服务端记录。
- 范围：全部节点还是单个节点，测速失败还是实际网页失败。
- 网络差异：Wi-Fi 与移动数据各测试 3 次的结果，以及是否完成公共网络认证。
- 日志：第一次错误前后的必要行，遮住订阅令牌、认证信息和个人访问域名。
- 已经做过的检查：订阅更新结果、系统时间、DNS 对照和协议类型，避免重复试错。
排查结束时，恢复临时修改的日志级别、代理模式、私人 DNS 和系统 VPN 阻断选项。保留最终能复现问题的最少步骤，比继续叠加覆写配置更容易定位故障。