1. 先区分测速失败与实际连接失败
Clash 客户端里的延迟测试，通常是让内核通过指定节点请求一个测试 URL，再根据请求耗时显示结果。它不是单纯的 ICMP ping，也不等于下载速度测试。列表全部显示 timeout，只能说明这些测试没有在限定时间内完成，不能直接推断所有服务器同时离线。
测试地址不可达、节点域名解析失败、TLS 握手失败，以及认证参数错误，都可能在界面上呈现类似结果。第一步应保留当前配置，选定一个节点，查看对应时间段的内核日志，再用同一节点发起一次实际网页请求。
- 记录当前订阅名称、选中的节点、测试时间，以及客户端显示的内核名称与版本。
- 暂停自动切换，临时在可手动选择的策略组中固定一个节点；确认浏览器请求实际命中了这个节点。
- 只触发一次测速和一次网页访问，在连接记录中核对规则、策略组与出站链路。
- 如果网页可正常访问而测速失败，优先检查测试 URL、测试超时和测试请求是否被服务端限制，不要先重装客户端。
2. 核对订阅有效期、流量与当前配置
订阅能够更新，不代表账号仍有可用流量；反过来，订阅更新失败也不代表本地缓存的所有节点已经失效。订阅下载接口和节点连接是两条不同链路，需要分别核对。
按这个顺序检查服务端与本地状态
- 账号状态：进入服务提供方的账户页面，检查套餐到期时间、剩余流量、设备或并发限制，以及维护公告。客户端展示的订阅用量可能是上次更新时的缓存。
- 更新结果：查看订阅更新日志和最后成功时间。HTTP
401或403提示认证或访问受到限制，具体原因需要结合服务方说明，不能仅凭状态码断言套餐过期。 - 响应内容：HTTP
200仍可能返回登录页或错误文本。配置解析成功、节点数量正常、配置确实被激活，才说明内容至少进入了内核加载流程。 - 配置来源：确认当前使用的不是旧的本地副本。使用
proxy-providers时，还要检查对应提供器是否更新成功，不能只看主配置文件的更新时间。
如果服务方更换了服务器地址、端口或认证信息，而客户端一直保留旧缓存，所有旧节点可能一起失败。先成功更新，再核对当前生效配置中的节点信息；不要只在订阅列表里看到“更新完成”就结束检查。
3. 校准系统时间，再判断 TLS 与认证错误
系统日期错误会影响证书有效期判断。日志中的 certificate has expired or is not yet valid，既可能来自服务器证书，也可能来自本机时钟偏差；部分带时间校验的认证流程同样依赖准确时钟。先对齐时间，可以避免把本机问题误判成节点协议故障。
| 平台 | 检查方式 | 核对重点 |
|---|---|---|
| Windows 11 | 「设置」→「时间和语言」→「日期和时间」→「立即同步」 | 开启自动设置时间，查看同步是否成功 |
| macOS | 「系统设置」→「通用」→「日期与时间」 | 启用自动设置日期与时间，核对时间服务器 |
| 使用 systemd 的 Linux | timedatectl status |
检查系统时钟同步状态和 NTP 服务状态 |
Windows 还可以运行下面的只读命令，查看时间服务状态与同步来源。若服务没有运行，命令可能报错，应回到系统设置处理，而不是把报错当作节点故障。
w32tm /query /status时区影响本地时间的显示，TLS 判断则依据实际时间点；仅把时区改为其他地区，并不能修复错误的系统时钟。校时后重新触发连接。若仍然报证书错误，再检查服务器证书、节点的 SNI 和是否存在网络证书拦截。
不建议把 skip-cert-verify 设为 true 来掩盖问题。关闭证书验证会失去服务器身份校验，也无法解决过期账号、错误密码或传输协议不兼容。
4. 确认实际内核，而不是只看客户端名称
客户端负责界面、配置管理和系统代理，真正建立连接的是内核。原版 Clash 与 Clash Meta（现称 mihomo）的协议支持范围不同，同一个客户端也可能允许切换或更新内核。因此，“配置能导入”不代表其中每种协议都能被当前运行的内核处理。
从加载日志核对三类信息
- 内核身份：在客户端的内核信息页面或启动日志中确认名称与版本，并记录当前实际运行的内核，不只记录安装包版本。
- 节点类型：查看配置中的
type。例如 Hysteria2、TUIC、VLESS 与 REALITY 相关配置，需要使用支持相应功能的内核及版本，不能套用旧版原版 Clash 的兼容预期。 - 完整参数：核对服务器地址、端口、密码或 UUID、传输方式、TLS、SNI 和协议专用字段。协议名称相同，也不意味着所有扩展选项都可互换。
出现 unsupported proxy type、未知加密方法或配置解析错误时，应先解决兼容与配置问题。这类错误往往发生在节点真正发起网络连接之前，延长测速超时没有帮助。日志原文会随内核版本变化，判断时应看字段和上下文，而不是只搜索某一句固定报错。
Shadowsocks 的 cipher 必须与服务器一致；VMess 与 VLESS 的用户标识不能互相替用；使用 WebSocket 的节点还要核对路径和 Host。带 REALITY 的节点应核对服务方提供的公钥、短 ID 与服务器名称等参数。转换订阅时若丢失这些字段，换节点名称或重新测速不会补回参数。
5. 用日志区分 DNS、端口与握手故障
订阅、时间与兼容性确认后，再看请求停在哪一层。不要同时改 DNS、TUN、端口和规则，否则即使恢复也很难知道原因。可以临时提高日志级别，重现一次问题后恢复原设置；不同客户端可能通过配置覆写控制此字段，应确认最终生效配置。
log-level: debug| 日志线索 | 常见含义 | 下一步 |
|---|---|---|
no such host |
节点域名解析未得到可用结果 | 核对节点域名及内核用于解析节点的 DNS 路径 |
connection refused |
连接被目标或中间设备明确拒绝 | 核对地址、端口与服务端监听状态 |
i/o timeout |
某个读写步骤在限定时间内未完成 | 结合上下文区分拨号超时与握手后超时 |
x509 相关错误 |
证书验证未通过 | 核对系统时间、服务器名称与证书链 |
| 认证失败或握手被关闭 | 可能涉及凭据、传输参数或服务端策略 | 对照订阅原始参数与服务端日志进一步确认 |
节点服务器域名的解析，与网页目标域名的解析是两个环节。在 mihomo 中，如果配置了 proxy-server-nameserver，应检查它对代理节点域名的解析是否可用；只改浏览器 DNS，未必影响内核连接节点时使用的解析路径。
TCP 端口检查可以辅助缩小范围。例如在 Windows PowerShell 中，下面的命令会检查 example.com 的 TCP 443 端口。该域名仅用于演示语法，实际排查应替换成订阅里的服务器与端口；演示结果不代表节点状态。
Test-NetConnection -ComputerName example.com -Port 443即使 TCP 检查成功，也只能说明 TCP 连接建立了，不能证明代理认证和 TLS 握手成功。Hysteria2、TUIC 等基于 QUIC 的连接依赖 UDP，TCP 测试更不能证明其服务可用。不要因为 TCP 443 可达，就排除当前网络限制 UDP 的可能。
6. 分离系统代理、TUN 与当前网络的影响
内核内置的节点测试与浏览器访问，入口可能不同。浏览器受系统代理、扩展和应用自身设置影响；TUN 则涉及虚拟网卡、路由与 DNS 接管。若内核本身连节点都超时，反复切换浏览器代理通常不能修复；若节点测试正常而网页失败，才更应检查应用流量是否进入内核。
先做显式本地代理测试
如果实际混合端口是 7890，可以用下面的命令绕开系统代理设置，显式向本地 HTTP 代理发送请求。端口不是 7890 时必须改为当前监听值。Windows 使用 curl.exe 可避免部分 PowerShell 环境中的同名别名干扰。
curl --verbose --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/这条命令仍然遵循内核规则，不会自动强制选择某个节点。需要在连接记录里确认目标请求经过了预定的代理组，而不是 DIRECT。命令中的 10 秒和 20 秒分别限制连接阶段与整个请求，不是节点性能结论；失败时保留错误阶段，而非只记录“打不开”。
再做同设备、不同网络对照
- 在同一设备、同一配置、同一节点下，对比家庭网络与手机热点，避免同时引入多个变量。
- 若仅一个网络失败，检查该网络的登录认证、UDP 限制、路由或防火墙策略，不要立即重新导入订阅。
- 如果启用了其他 VPN 或网络过滤工具，记录其状态，在允许的环境中逐一停用并测试；不要直接关闭所有安全防护。
- 检查日志中的拨号目标是 IPv4 还是 IPv6。只有在确认对应地址族不可达后，再做单项配置测试，避免全局关闭 IPv6 掩盖其他问题。
显式本地代理测试可用、开启 TUN 后却失败时，应进一步检查 TUN 路由、DNS 劫持设置和其他虚拟网卡冲突。修改前保存配置，测试后恢复；基础操作可参考使用教程，不要把 TUN 当作所有超时问题的默认修复开关。
7. 用最少变量复测，并整理可复现记录
完成一项修复后，用最初选定的节点、相同测试地址重新验证。若只是提高超时阈值后偶尔成功，说明请求可能受到延迟或丢包影响，还需要观察实际访问是否稳定；不能把列表出现一个延迟数字当作排查结束。
- 订阅层：确认账号有效、流量可用，当前节点来自最近一次成功更新并已生效。
- 本机层：确认系统时钟已同步，记录内核名称与版本，排除配置加载错误。
- 连接层：核对节点域名解析、目标地址与端口，找到日志中最早出现的失败环节。
- 请求层：验证测试 URL 和实际网页，查看连接记录是否选择了预期节点。
- 环境层：必要时对比另一网络，分别记录系统代理与 TUN 的状态，而不是同时修改。
向服务提供方或客户端维护者反馈时，附上系统版本、客户端与内核版本、复现时间及所在时区、节点协议类型、脱敏错误片段，以及换网络后的对照结果。服务方更适合核对账号权限和服务端监听，客户端维护者更适合检查配置解析、内核调用与路由接管。把问题交给对应环节，比只发送一张“全部 timeout”的截图更容易定位。
排查完成后恢复临时调整的日志级别，清理包含敏感信息的调试文件，并保留可用配置备份。后续再遇到同类故障时，沿用“订阅与凭据 → 系统时间 → 内核兼容 → 解析与连接 → 应用入口”的顺序，通常比逐个盲试节点更容易找到共同原因。