一、先区分节点超时、订阅失败与流量未接管

看到 Timeout，先不要重装客户端。节点延迟测试失败，只能说明一次测试未在指定时间内完成；订阅无法更新、浏览器没有使用代理、远端节点不可达，是三条不同的故障链。把症状分清，后面的修改才有依据。

先暂停其他代理或 VPN，记录正在使用的客户端名称、客户端版本、内核版本和当前配置名称。Clash 是一类代理内核及其配置生态的常见称呼；不少当前客户端使用的是 mihomo，也就是原 Clash.Meta 延续发展的内核。不同内核支持的协议和字段不同，不能把某个客户端的菜单或配置能力当作所有产品的共同标准。

看到的现象先查哪里判断依据
更新订阅返回 401、403服务方账户与订阅权限请求被拒绝，不等于节点服务器超时
所有节点测试均为 Timeout配置是否加载、网络、DNS共同依赖项出错的可能性较高
只有一个节点超时该节点地址、端口及服务状态其他节点在同一设备上可以使用
节点有延迟，浏览器打不开系统代理、规则与连接记录测试成功不代表应用流量已进入内核
网页能打开，延迟测试失败测试 URL 与测试超时时间测试目标可能不可达或受到限制

二、确认本机联网、系统时间与订阅状态

先排除网络登录页与时间偏差

  1. 暂时关闭客户端的系统代理和 TUN，再测试本来就能直接访问的网站。校园网、酒店或公共 Wi-Fi 若要求网页登录，先完成认证。
  2. Windows 11 打开「设置」→「时间和语言」→「日期和时间」，检查「自动设置时间」，点击「立即同步」。macOS 打开「系统设置」→「通用」→「日期与时间」，核对自动设置日期与时间。
  3. 用手机热点替换当前 Wi-Fi，保持配置和节点不变，再测试一次。只有换网络后恢复，才更支持本地网络路径或网络策略有问题。

系统时间明显错误可能导致 TLS 证书校验失败，也可能影响依赖时间的认证。日志若包含 certificate has expired 或 certificate is not yet valid，先核对设备时间与证书有效期；不要用跳过证书验证来掩盖问题。connection refused 通常表示连接被主动拒绝，与一直等待的超时也不是同一回事。

确认订阅更新成功，而且已经启用

以 Clash Verge Rev 的常见界面为例，打开「订阅」，找到当前订阅卡片，执行更新；随后确认该配置处于选中状态。不同版本的按钮位置可能变化，重点检查更新结果、更新时间和节点列表是否发生预期变化。下载到新文件不代表已成功加载，配置语法错误时，客户端也可能继续使用之前的有效配置。

  • 返回 401 或 403：检查服务方账户、有效期和订阅链接是否已重置。HTTP 状态码本身不能证明套餐一定过期。
  • 返回 200 但导入报错：检查响应是否实际为登录页、错误说明或不兼容格式，而不是可用的 Clash YAML 配置。
  • 节点仍显示但全部不可用：旧配置可以保存在本地，账户到期后节点名称未必自动消失，应回服务方账户页核对剩余流量与到期日。
  • 通过代理更新失败：若客户端提供订阅更新代理选项，确认是否陷入“必须先连上失效节点才能更新”的循环；按当前网络条件尝试直连更新。

订阅地址往往带有访问令牌，不要将完整链接粘贴到公开论坛、截图或日志附件中。需要重新导入时，从服务方账户页复制当前有效链接，并先保留原配置便于对照。

三、检查本地端口，确认内核确实在监听

应用必须连接到实际监听的端口。下面以 127.0.0.1:7890 为演示地址；7890 不是所有客户端的固定默认值。先在客户端设置或当前生效配置中查看 mixed-port、port 和 socks-port，然后把命令中的端口换成实际值。external-controller 是管理接口，不能当作网页代理端口使用。

Windows：查看监听与所属进程

打开 PowerShell，执行以下命令。第一条检查本地 TCP 连接是否建立，第二条列出监听进程编号。

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

TcpTestSucceeded : True 只说明该端口可连接，还要到「任务管理器」→「详细信息」按 PID 找到对应进程。如果 PID 属于另一个代理软件，说明可能存在端口冲突；如果没有监听，先查内核启动或配置加载错误，不必急着更换远端节点。

macOS 与 Linux：检查同一个监听端口

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

进程信息可能受系统权限限制。日志出现 address already in use 时，退出占用端口的旧进程，或将代理端口改为一个空闲端口，例如 7893。改完必须同步更新系统代理、浏览器扩展和终端代理环境变量，不能只改 YAML。

四、用显式代理区分系统代理与节点故障

本地端口可连接后，先做一次明确指定代理的请求。这个测试绕过“应用是否读取系统代理”的不确定性，但仍会受客户端当前模式和分流规则影响。为了判断某个节点，可临时切到全局模式，并明确选中该节点；测试结束后恢复原来的规则模式。

# Windows PowerShell；使用 curl.exe，避免旧版环境中的同名别名
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

这里的 5 秒是连接超时上限，15 秒是整个请求的上限，不是实测延迟。演示命令要求该端口支持 HTTP 代理；如果实际只有 SOCKS 入口，应使用对应端口和 socks5h:// 协议。example.com 只是固定测试目标，若结果异常，应再换一个自己确认可用的 HTTPS 网站交叉检查。

  • 提示无法连接 127.0.0.1：回到本地监听检查，远端节点尚未参与这一步。
  • 只看到 200 Connection established：仅表示 HTTP 代理建立了隧道响应，还要继续看 TLS 和最终网站响应是否完成。
  • 得到最终 HTTP 响应：说明这次请求至少走通了链路；即使返回 403、405，也应区分网站访问策略和连接超时。
  • 显式代理成功，浏览器失败：优先查浏览器扩展、系统代理例外列表以及应用自己的代理设置。

系统代理开关与操作系统设置要对得上

Windows 11 到「设置」→「网络和 Internet」→「代理」，检查手动代理地址和端口是否与客户端一致。macOS 到「系统设置」→「网络」→ 当前网络连接的「详细信息」→「代理」，检查 Web 代理与安全 Web 代理。不要同时保留来源不明的自动代理脚本和手动代理配置。

同时打开客户端的「连接」与「日志」页面，再刷新网页。若完全没有对应连接，流量可能没有进入内核，也可能复用了浏览器已有连接；关闭该网页后重新打开再观察。若有记录且目标为 DIRECT，应检查命中的规则，而不是把它误判为代理节点失效。

五、区分 DNS 解析失败与 fake-ip 路径问题

DNS 排查要分两层：一层是“节点服务器域名能否解析”，另一层是“访问网站的域名如何解析”。节点本身的地址都无法获得时，换网站测试没有意义；网站解析异常时，也不能直接断言所有节点损坏。

先读日志中的域名与错误阶段

打开客户端日志，临时使用能显示连接错误的日志等级，重复一次失败操作。记录错误里的域名、端口和时间。no such host 通常指向名称解析失败；i/o timeout 需要结合前后文判断是在 DNS 查询、连接远端还是协议握手阶段。单独截取最后一个 Timeout，信息往往不够。

# Windows：检查系统解析链路
Resolve-DnsName example.com

# macOS / Linux：有 nslookup 时使用
nslookup example.com

这些命令主要验证系统所使用的解析路径，不一定等同于 mihomo 的内置 DNS 结果。系统解析成功、内核仍报解析失败时，应继续检查当前生效配置的 dns 段、解析服务器可达性和节点域名解析设置，而不是反复清空浏览器缓存。

fake-ip 地址不是节点服务器地址

在 fake-ip 模式下，内核可能从配置的地址池分配合成地址，常见示例地址池为 198.18.0.1/16。应用得到这类地址并不等于 DNS 被污染；内核依靠映射关系还原域名，再执行规则与连接。实际是否使用该范围，要看当前配置。

  • 关闭 TUN 后应用仍访问合成地址：可能保留了先前的 DNS 缓存。先退出相关应用，恢复原有解析路径，再重开应用；Windows 可执行 ipconfig /flushdns 清理系统 DNS 缓存。
  • 仅某个局域网应用异常：检查它是否依赖真实 IP、局域网发现或自带 DNS。针对实际域名设置 fake-ip 例外，比把所有域名都加入例外更容易维护。
  • 改用加密 DNS 后开始超时：检查该 DNS 服务本身能否连通，以及其域名是否需要引导解析。加密 DNS 并不保证在每个网络都可达。

需要对比时，可以在备份配置中临时切换为客户端和内核支持的另一种 DNS 模式，再加载配置、重启测试应用。每次只调整一项。远程订阅更新可能覆盖直接编辑的内容，长期修正应放在客户端提供的覆写或合并机制中；具体字段可结合配置参考核对。

六、单独验证 TUN、其他 VPN 与网络接管冲突

系统代理正常、TUN 异常时，先查接管路径。TUN 通过虚拟网络接口和路由处理流量，覆盖范围与系统代理不同；启用它不能修复过期订阅或远端服务器停机。测试时先暂停其他 VPN、加速器和同类虚拟网卡工具，避免多个程序同时修改默认路由或 DNS。

  1. 先关闭 TUN，保留系统代理，执行上一节的显式代理请求。若成功，说明本地代理入口与选定节点至少能完成这次请求。
  2. 关闭系统代理，再启用 TUN，用普通浏览器访问同一测试网站，同时查看连接记录。
  3. 若第二步失败，检查客户端是否提示服务未安装、权限不足或虚拟接口创建失败。桌面客户端可能需要先安装或启动相应系统服务。
  4. 恢复原有开关状态，确认退出客户端后网络也能正常恢复，再决定是否保留 TUN。

Android 同一用户环境通常只能由一个应用占用系统 VPN 服务；另一个 VPN 启动后，原有连接可能被替换。iOS 的网络扩展也受系统与客户端实现约束。手机端应先看系统 VPN 状态和客户端日志，而不是照搬桌面端的 7890 端口检查步骤。

如果只有部分大型网页、上传或视频在 TUN 下卡住，小请求正常，才有必要进一步考虑路径 MTU、UDP 支持或特定协议问题。不要直接复制不明来源的 MTU 数值。先记录能够复现的目标、传输类型与网络环境，再对单项设置做对照测试。

七、最后验证远端节点与延迟测试目标

当本地监听、流量接管和 DNS 都有明确证据后，再判断节点是否不可达。保持同一设备、同一网络、同一目标网站，只切换节点。如果一个节点连续失败、另一个连续成功，问题更可能集中在失败节点或到该节点的网络路径。

延迟测试不是完整的可用性证明

客户端延迟测试通常会通过节点请求指定 URL。测试 URL、超时阈值以及服务端响应策略都会影响结果。若客户端支持设置超时，可将例如 3000 毫秒临时调到 8000 毫秒作对照；这只是放宽等待时间，不是提升速度。能完成轻量测试，也不代表视频、UDP 或长连接一定正常。

远端 TCP 端口能连接，只能证明 TCP 握手可达，不能证明认证、TLS 或代理协议握手成功。某些节点使用基于 UDP 的传输，TCP 端口测试甚至不适用。不要用 ping 的成败判断节点好坏，服务器可能不响应 ICMP，但代理服务仍可使用。

  • 只有一个节点失败：更新订阅，核对是否已被服务方替换，再查看是否有节点维护通知。
  • 同一网络全部失败，热点正常：重点排查当前网络的出口限制、DNS 与远端路径。
  • 两种网络都失败，日志提示不支持协议：核对配置要求与内核能力，更新至客户端官方发布的兼容版本，不要随意改写协议名称。
  • 日志出现认证或 TLS 错误：核对账户、节点参数和系统时间，避免把所有握手失败统称为网络超时。

八、提交故障信息与恢复日常设置

如果仍未解决，整理下面这份记录再求助，比一句“节点全部超时”更容易得到有效答复。日志只保留故障发生前后约 30～60 秒的相关片段，先删去订阅令牌、密码、UUID 和其他认证信息。

  • 客户端名称、客户端版本、内核版本、操作系统版本。
  • 故障发生时间与时区，以及使用 Wi-Fi、有线网络还是手机热点。
  • 是订阅更新失败、节点测试失败，还是具体应用访问失败。
  • 本地实际代理端口、监听进程是否正确、显式代理请求结果。
  • 系统代理与 TUN 的开关状态，规则模式或全局模式，以及命中的策略组。
  • 换节点、换网络、换测试目标后的结果，每次只改变一项。

测试结束后恢复日常规则模式、原有 DNS 和必要的代理开关，关闭临时调试日志。最终判断要落在可重复的证据上：端口是否监听、请求是否进入内核、域名是否解析、远端握手是否完成。按这个顺序检查，通常能把“Clash 连不上”缩小到一个可以处理的环节。首次配置不熟悉时，可先按快速上手教程确认基础设置；常见客户端问题可继续查看帮助中心。