代理节点超时但网络正常：订阅状态、DNS 与连接链路检查顺序

一、先区分延迟测试超时与真实连接失败

浏览器能打开本地常用网站，但 Clash 客户端把节点标成“超时”，并不矛盾。本地联网只证明某条直连路径可用；节点延迟测试通常还要经过代理服务器、协议握手和指定测试地址。任意一段失败，都可能在界面上收敛成同一个超时提示。

客户端负责界面、订阅和配置管理，内核负责代理连接、规则与 DNS 等处理。Clash 与 Clash Meta（现常称 mihomo）的字段支持和行为存在差异，不同客户端的测试入口、默认 URL、超时阈值也不完全一致。排查时应记录客户端版本和实际运行的内核版本，而不是只记住应用名称。

二、本地联网检查：排除门户认证与代理残留

先保存当前设置，再关闭客户端的系统代理与 TUN 接管。如果还有其他 VPN 或代理应用，也应在获得使用许可的前提下退出。关闭界面窗口不一定会停止后台服务，更不一定清除系统代理，所以要核对系统设置，而不是只看托盘图标。

Windows 上确认直连基线

1. 打开 Windows 11「设置」→「网络和 Internet」→「代理」，记录自动设置脚本和手动代理原有状态。组织下发的设置不要擅自修改。
2. 访问两个平时能直连的网站，确认 Wi-Fi 没有停留在酒店、校园或公共热点的认证页。能打开路由器管理页只证明局域网连通。
3. 检查「设置」→「时间和语言」→「日期和时间」，确认日期、时区与时间同步正常。明显的时钟偏差可能导致 TLS 证书验证失败。

如果系统已安装 curl，可在 PowerShell 中执行下面的直连请求。Windows 使用 curl.exe，避免部分 PowerShell 环境将 curl 解释为其他命令。macOS、Linux 可将命令名换成 curl。

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://example.com/

--noproxy "*" 让 curl 不使用配置的显式代理，但不能绕过仍在运行的 TUN、透明网关或组织网络策略。这里的 example.com 只是演示目标，可换成你确认能直连的地址；单个示例站点不可达不等于本地断网。5 秒是连接阶段上限，15 秒是本次操作总上限，都不是实测延迟。

三、订阅状态检查：更新成功不等于节点可用

在客户端当前使用的配置详情中，确认最近一次更新是否成功、节点数量是否符合预期，以及更新后是否真正切换到这份配置。有些客户端会保留旧配置继续运行，因此“节点列表还在”不能证明刚才的订阅更新成功。

• 账户状态：到订阅提供方的账户页面检查有效期、剩余流量、设备或并发限制。客户端未显示用量信息时，不应据此推断流量充足。
• 响应状态：401 或 403 提示授权或访问策略问题；429 通常需要停止频繁更新并等待；5xx 优先核查服务端状态。
• 响应内容：HTTP 200 也可能返回登录页或错误说明。完整 YAML、仅含节点的数据和单节点分享链接，不一定由同一个导入入口处理。
• 更新路径：某些客户端允许为订阅更新选择直连或代理。若更新依赖的节点已经失效，会出现“更新需要代理、代理又需要新订阅”的循环。

只在客户端明确提供相关设置时，尝试更换订阅更新路径，然后手动更新一次并查看日志。不要连续点击更新，也不要把私人订阅 URL 粘贴进公开的在线转换或诊断服务。URL 中的令牌往往就是访问凭据。

四、节点参数检查：把端口连通与协议握手分开

选中一个失败节点，核对其协议、server、port 和认证参数。对于使用 TLS、WebSocket 或 gRPC 的节点，还需核对服务方提供的服务器名称、传输类型、路径或服务名。Reality 等扩展参数则要求内核支持，不能把字段从其他协议随意移植过来。

先检查节点服务器的 TCP 端口

下面是 Windows PowerShell 的交互式检查，运行时输入当前节点的真实服务器地址和端口。服务器地址只填主机名或 IP，不带 https:// 前缀，不输入订阅 URL。

$nodeHost = Read-Host "输入节点 server 地址"
$nodePort = [int](Read-Host "输入节点 port 数值")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed

此检查应在 TUN 等接管已关闭的直连基线下进行，否则结果可能经过现有代理。TcpTestSucceeded: True 只证明该次 TCP 连接建立成功，不证明密码、UUID、TLS 或代理协议正确。结果为 False 时，应继续检查地址解析、远端监听和中间网络限制。

这不是 UDP 节点的通用检测工具。例如基于 QUIC 的代理协议主要使用 UDP，TCP 端口测试失败不能证明它不可用。同样，ping 测的是 ICMP；服务器不响应 ICMP，也可能正常提供代理服务。

• 端口能连接，但日志报告认证失败：核对账户与节点参数，先不要调整 DNS。
• 出现证书名称不匹配：核对服务器名称、系统时间和服务端证书，不要把关闭证书验证作为常规修复。
• 只有特定网络失败：在允许的情况下，用同一设备切换手机热点复测，记录差异；一次切网结果仍不足以确定是运营商限制。

五、DNS 排查：节点域名与目标域名分别验证

代理连接可能至少涉及两类域名：一类是节点服务器自身的域名，另一类是浏览器要访问的目标域名。前者解析失败时，连接通常还没到达节点；后者如何解析，则与协议、DNS 配置和流量进入内核的方式有关。

在前一步的 PowerShell 窗口中执行以下命令，可观察系统解析节点域名的结果。若 server 已经是 IP 地址，可跳过这一项。

Resolve-DnsName -Name $nodeHost -Type A
Resolve-DnsName -Name $nodeHost -Type AAAA

没有 AAAA 记录不一定是异常；有 AAAA 记录也不代表当前网络的 IPv6 路由可用。若日志显示正在连接 IPv6 地址并超时，而 IPv4 路径可用，应检查 IPv6 链路和内核的地址选择设置，避免直接对整个系统做永久性禁用。

系统解析成功，为什么内核仍然报错？

• 内核启用了自己的 DNS 处理，使用的上游与系统不同，系统命令的成功不能代替内核日志。
• 加密 DNS 上游自身需要域名解析或代理通道，配置不当可能形成启动依赖循环。
• 规则或覆写改变了 DNS 路由，当前运行配置与订阅文件内容不完全相同。

部分 mihomo 版本支持 proxy-server-nameserver，用于指定节点服务器域名解析所用的上游；是否采用还应结合实际版本与完整 DNS 配置确认。它不适合未经核对就加入所有 Clash 配置。字段关系可对照配置大全中的 DNS 说明。

调整 DNS 后，按客户端支持的方式重新加载配置，并重新建立测试连接。Windows 的 ipconfig /flushdns 只清除系统 DNS 缓存，不会一并清除浏览器缓存、内核缓存和既有连接。

六、代理接管检查：用本地端口隔离系统设置

节点和 DNS 没有明显异常后，检查应用请求有没有进入内核。系统代理只对遵循该设置的应用有效；TUN 通过虚拟网络接口与路由接管流量，需要相应系统权限，并可能与其他 VPN 的路由冲突。开启 TUN 不会自动修复失效节点，也不代表所有流量都必然进入代理。

以下命令假设当前运行配置的 HTTP 或 mixed 监听地址为 127.0.0.1:7890。7890 是教学示例，不是所有客户端的固定值；请先在当前配置或监听信息中确认。若该端口要求认证，需按客户端说明在本地提供凭据，分享记录时删除敏感内容。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

该命令显式连接本地代理，不依赖浏览器是否采用系统代理。空的 --noproxy 列表用于覆盖已有的代理绕过设置。测试时仍应查看连接记录中的规则命中和最终出口：即使请求进入本地端口，也可能被规则分到 DIRECT，不能直接当成节点已经可用的证据。

诊断时可短暂切换全局模式并明确选择测试节点，但要记录原模式并在测试后恢复规则模式。已有连接可能继续使用旧出口，因此切换后应关闭旧测试连接再发起新请求。不要用全局模式长期掩盖规则配置错误。

七、测试地址与日志：定位超时发生在哪一段

如果显式代理能够访问实际业务目标，而客户端延迟测试仍超时，应优先检查测试 URL。测试服务可能故障、限制频繁请求，或对某些出口不可达；某些实现还会核对预期 HTTP 状态码。不要仅凭一个红色延迟标签删除整份配置。

一次只调整一个测试条件

1. 记录当前测试 URL 和阈值；若界面支持，可将 3000 毫秒暂时调为 10000 毫秒，再对同一节点测试 3 次。这只是诊断设置，不是推荐延迟标准。
2. 改用自己有权访问、响应稳定的小型 HTTPS 目标进行对照。更换目标是为了区分测试端故障，不是挑一个总能返回成功的数字。
3. 对不支持 HEAD 的目标，将 curl 命令中的 -I 改为 -o NUL，发送普通 GET 并丢弃响应体；macOS、Linux 使用 -o /dev/null。
4. 同时查看内核日志和连接记录，确认访问域名、匹配规则、策略组及实际节点一致。

curl 的退出码 7 通常表示无法建立连接，28 表示操作超时，60 与证书验证失败有关；它们不是统一的“节点离线”代码。使用 HTTP 代理访问 HTTPS 时，输出中的 200 Connection established 只表示 CONNECT 隧道阶段成功，还需要看后续 TLS 与目标 HTTP 响应。

日志中的 lookup、dial tcp、handshake 等上下文有助于定位阶段，但不要只截取最后一行“timeout”。保留同一时间附近的记录，并标注测试目标。临时提高日志级别后应及时恢复，避免长期积累访问记录。

八、恢复设置与反馈清单

完成排查后，恢复原来的规则模式、DNS 设置和接管方式，确认自动策略组是否需要重新启用。不要把调大超时、临时固定节点、暂停 TUN 等诊断动作直接当作最终配置。最终验证至少包含一次新建网页连接，以及原来失败的那个应用场景。

• 环境：操作系统、架构、客户端版本、实际内核版本，以及问题发生时的网络类型。
• 范围：全部节点还是单个节点、所有目标还是一个目标、系统代理与 TUN 是否表现不同。
• 证据：准确测试时间、采用的端口、规则命中、实际出口和经过脱敏的错误上下文。
• 已做操作：订阅更新时间、账户状态核查、DNS 结果、切换网络的对照结果及是否已恢复原设置。

截图或反馈前，应遮盖订阅 URL、令牌、密码、UUID 和不希望公开的服务器信息。若同一节点在多个网络下都无法完成握手，可向订阅提供方提交脱敏记录；若显式代理正常而客户端接管异常，则更适合向对应客户端项目反馈。按照失败发生的层级找维护方，比反复重装更容易得到可执行的修复建议。