节点测速全部超时（Timeout）或延迟显示为 -1ms 的排查与修复步骤

现象本质定位：客户端的测速动作到底发生了什么？

在日常使用代理客户端（如 Clash Verge Rev 客户端配置、Mihomo Party 客户端教程、sing-box 通用内核指南或 iOS 端 Shadowrocket 小火箭配置）时，许多用户会遇到这样一个令人头疼的场景：点击客户端右上角的“延迟测速”按钮后，列表中的数十个甚至上百个节点在几秒钟内全部变成醒目的红色，显示 Timeout 或 -1ms。如果配合 TUN 虚拟网卡与系统代理差异模式全局接管，甚至可能直接诱发 TUN 模式开启后整机断网故障。

面对全红的界面，初级用户的直接反应往往是“这家机场的所有境外服务器同时瘫痪了”。从网络工程和概率学常识来看，在具备 BGP 多线动态冗余接入的现代基础设施中，分布在香港、日本、新加坡、美国十几个不同机房的物理服务器在同一秒钟内集体断电或断网的概率接近于零。

这种大面积同时超时的现象，绝大多数源自本地运行环境、系统网络协议栈拦截或服务商入口鉴权失败。

要解决这个问题，首先要搞明白客户端在测速时究竟发出了什么网络请求。

【客户端延迟测速完整通信时序图】

[客户端延迟测试模块] 
   │
   ├─► (1) 发起 HTTP GET 请求至测试 URL (默认 http://www.gstatic.com/generate_204)
   │
   ├─► (2) 触发本地代理核心处理
   │       ├── 检查系统时间戳是否处于合规窗口 (TLS 1.3 校验)
   │       ├── 解析节点入口域名 (若本地 DNS 失败则直接报 Timeout)
   │       └── 尝试与国内入口机房建立 TCP 握手
   │
   ├─► (3) 数据包通过专线或公网隧道送达境外落地服务器
   │
   ├─► (4) 境外服务器向 Google 节点发起真实连接，等待 HTTP 204 返回
   │
   ▼
[收到响应计算往返耗时 RTT] ──► 成功：显示绿色延迟 (如 35ms)
                            └── 超出预设阈值 (默认 5000ms)：直接判定为红色 Timeout (-1ms)

在默认配置下，客户端的测速机制是：通过该节点向一个全球高可用、响应极小的特定目标 URL（最常用的是 Google 的 http://www.gstatic.com/generate_204 或 Cloudflare 的 http://cp.cloudflare.com/generate_204）发起一次完整的 HTTP 请求。如果目标服务器在预设的时间阈值内（通常为 2000 到 5000 毫秒）返回了 HTTP 204 状态码，客户端便将从发起请求到收到回包的总耗时作为延迟数值显示出来；一旦在此期间发生了域名解析失败、TCP 握手超时、TLS 认证中断或回包丢失，测速逻辑就会直接判定失败，返回 -1ms 或 Timeout。

按照以下从易到难、从本地到远端的工程化标准诊断清单逐项排查，可以在数分钟内快速锁定故障根源。

诊断第一阶：本地运行环境核查（解决 80% 的超时故障）

1. 检查并强制校准操作系统本地时间（高频隐形杀手）

这是导致所有节点大面积超时的最常见、也是最容易被忽视的原因。

现代主流加密代理协议（如 VLESS XTLS-Reality、VMess、Trojan 等）均依托于标准 TLS/HTTPS 协议栈。为了防范重放攻击与证书中间人劫持，TLS 握手协议对系统时钟有严格的时间戳比对要求：

误差容忍极限：本地计算机的时钟与全球标准授时网络（NTP）的时间偏差必须保持在 60 秒以内。如果本地时间比真实时间快了或者慢了数分钟，客户端在与境外服务器进行 TLS 握手时，安全证书的生效应答会被判定为“尚未生效”或“已经过期”，服务端或本地密码学库会直接中断握手，抛弃后续数据包。

排错操作步骤：

Windows 平台排查

鼠标右键点击屏幕右下角的任务栏时钟，选择“调整日期和时间”。
确认“自动设置时间”与“自动设置时区”开关均处于开启状态。
点击“立即同步”按钮。如果界面提示同步失败，说明 Windows 默认的 time.windows.com 授时服务器在本地网络被阻断。
打开 PowerShell（管理员身份），输入以下命令强制切换为国内稳定授时源并立即对齐：

# 切换为阿里云与中科院国家授时中心 NTP 服务器
w32tm /config /manualpeerlist:"ntp.aliyun.com,ntp.ntsc.ac.cn" /syncfromflags:manual /reliable:YES /update
# 重启 Windows 时钟服务并强制同步
net stop w32time
net start w32time
w32tm /resync /nowait

macOS 平台排查

进入“系统设置” -> “通用” -> “日期与时间”，确保开启“自动设置日期与时间”，时间源可指定为 time.apple.com。

Linux / 软路由 OpenWrt 排查

在 SSH 终端中执行：

# 查看当前系统时间状态与 NTP 同步情况
timedatectl status

# 强制通过网络授时同步系统时钟
chronyc makestep || ntpdate -u ntp.aliyun.com

2. 检查本地代理端口是否发生冲突与进程僵死

每一个代理客户端在启动时，都需要在本地绑定监听特定的端口（例如 Clash 默认监听 HTTP 端口 7890、SOCKS5 端口 7891、混合端口 7890，部分客户端监听 10808 或 2080）。

如果电脑中同时开着其他代理软件、网络抓包工具（如 Fiddler、Charles），或者之前客户端发生过非正常退出，其底层的内核进程（如 mihomo.exe、clash-core.exe、sing-box.exe）可能依然残留在后台死锁并霸占着该端口。当新启动的图形界面尝试连接内核时，就会由于端口冲突导致所有流量无法进入内核，引发全局测速超时。

排查命令实操：

打开 Windows PowerShell，执行以下命令排查 7890 端口占用情况：

netstat -ano | findstr :7890

如果返回类似以下输出：

TCP    127.0.0.1:7890         0.0.0.0:0              LISTENING       14280

最后一列数字 14280 就是占用该端口的进程 PID。执行以下命令查看究竟是哪个程序在占用：

tasklist | findstr 14280

如果发现占用端口的是其他软件（例如迅雷、某些加速器或多开的客户端），直接在任务管理器中将其结束任务，或者使用命令行强制终止：

taskkill /F /PID 14280

随后彻底退出当前代理客户端并重新以管理员权限启动。

3. 排查本地第三方杀毒软件与网络过滤驱动拦截

许多国产安全卫士（如 360 安全卫士、电脑管家、各类第三方网络防火墙）内置了严格的主机入侵防御系统（HIPS）与流量审计驱动。

这些安全软件在检测到未知可执行程序在向 127.0.0.1 发送大量高频回环流量、或者在系统中安装 Wintun 虚拟网卡设备时，可能在没有任何前台弹窗提示的情况下，直接在内核层丢弃所有与代理内核通信的数据包。

验证与排查方法：

临时完全退出本地安装的第三方杀毒与安全防护软件；
如果开启了 Windows Defender 防火墙，进入“高级安全 Windows Defender 防火墙”设置，检查出站规则与入站规则中是否存在针对当前客户端可执行程序的阻止条目；
将客户端的主程序目录及内核二进制文件添加到安全软件的信任白名单中。

诊断第二阶：服务商订阅状态与节点配置凭据核查

如果本地时间、端口与防火墙均完全正常，但所有节点依然持续报超时，问题很大概率出在账户订阅状态失效或服务商机房端配置更替上。

1. 确认订阅套餐是否过期或流量超额耗尽

代理服务商的计费面板与边缘网关是紧密联动的。一旦用户的订阅满足以下两个条件之一，后端的 RADIUS 计费鉴权集群会立即注销该用户的唯一访问凭据：

套餐已过有效期：即便月付套餐内还剩余几十 GB 流量，只要到期时间一过，网关鉴权就会直接返回未经授权；
当月配额流量耗尽：哪怕账户距离到期还有半个月，一旦高速流量消耗完毕，节点入口会直接拒绝建立连接。

核查动作： 登录服务商用户中心网页端后台，仔细查看仪表盘（Dashboard）中的“套餐状态”是否显示为绿色的 Active，并确认可用流量是否大于 0。

2. 用户在后台重置了订阅密码或 UUID

许多用户为了安全，在服务商网站后台点击过“重置订阅链接”或“更改连接密码”。

服务商的数据库在生成新密码或新 UUID 的同时，会立即将旧密钥废弃。如果用户在网站后台执行了重置，但没有在本地客户端重新拉取更新订阅，本地客户端依然会拿着已经失效的旧 UUID 向机房发起连接。服务端鉴权模块比对失败，直接静默丢弃数据包，导致所有节点全部超时。

修复方法： 在客户端配置管理界面中，右键点击当前的订阅配置文件，选择 “更新订阅”。如果提示更新失败，请参考我们的专项排错手册订阅更新失败 Fetch Subscription Failed 深度排查。

诊断第三阶：DNS 污染与系统网络协议栈死锁排查

1. 节点入口域名的本地 DNS 解析被运营商污染

服务商在向用户下发节点列表时，节点的连接地址普遍采用类似 hk-01.transit-node.com 的域名形式，较少直接暴露裸 IP。

当客户端发起延迟测速时，本地电脑首先需要通过本地宽带的 DNS 服务器将这些入口域名解析为真实的国内入口机房 IP。如果本地运营商的 Local DNS 发生了故障、或者将这些域名错误地解析到了不存在的死地址，客户端连入口机房的门都摸不到，必然报出全部超时。关于此类风险的底层逻辑，可参阅 DNS 污染、DNS 泄漏与 Fake-IP 模式解析。

快速定位方法： 在终端中直接 ping 节点配置中的某个入口域名：

# 测试节点入口域名是否能正确解析出境内机房公网 IP
Resolve-DnsName hk-01.example.com

如果命令提示 DNS name does not exist 或返回被污染的海外 IP，说明本地网络 DNS 存在异常。将电脑物理网卡的 DNS 服务器手动更改为国内干净的公共公共 DNS：

首选 DNS：223.5.5.5（阿里公共 DNS）
备用 DNS：119.29.29.29（腾讯 DNSPod）

2. 测速目标 URL（Test URL）自身在本地被墙

正如前文所述，客户端测速依赖访问一个目标 URL。如果你的配置文件中默认填写的测试 URL 是 http://www.google.com/generate_204，由于 Google 在国内公网本身就是被完全阻断的，一旦客户端的全局分流规则稍有偏差，测速数据包没有正确走代理隧道而是走了本地直连，测试请求就会因超时而返回 -1ms。

优化方案： 在客户端设置中，将延迟测试 URL 更改为针对国内网络更加宽容或专门的全球 CDN 测试地址：

http://cp.cloudflare.com/generate_204
http://www.gstatic.com/generate_204
https://api.github.com/_ping

在 Clash Verge Rev 中，可直接在“设置” -> “内核设置”中找到“延迟测试 URL”进行修改并保存。

诊断第四阶：公网跨网 QoS 惩罚与链路层抗封锁分析

当你排查完本地所有环节，确认账户正常、配置最新，但部分甚至所有普通节点在每天晚上依然准时爆红超时，这通常说明当前节点的网络底层通道遭遇了运营商级别的跨网结算结算拥塞或主动干扰。

1. 跨运营商互通壁垒引发的 TCP SYN 丢弃

国内三大运营商之间的骨干网互联互通存在严格的流量结算机制。如果你使用的是中国移动宽带，而购买的低价服务商为了节省成本，仅部署了中国电信单线的国内中转机房：

移动用户的流量必须在省级交换中心（NAP 点）跨网进入电信网络；
在晚高峰流量高峰期，跨网交换链路的队列极度拥挤，TCP 握手包（SYN）在交换点被大量丢弃；
客户端在等待 3 次重传无果后，触发 5 秒超时，界面变红。

这也是为什么在挑选网络服务时，必须重点关注其是否配备了具备全动态路由能力的 BGP 多线动态中转接入。多线 BGP 能够让移动宽带走移动直连光纤，电信宽带走电信机房，彻底规避跨网互联的拥塞断连。

2. 公网隧道与物理专线的抗封锁天壤之别

普通低价服务商普遍采用公网加密隧道中转。在特殊网络收紧时期，骨干网防火墙会对频繁产生大流量海外传输的端口实施无差别阻断。公网隧道的境外 IP 一旦被识别并列入路由黑洞，所有挂载在该境外 IP 下的节点就会在瞬间集体阵亡。

采用企业级物理隔离的 IEPL 跨国内网专线从根本上杜绝了这一风险。专线走的是跨国运营商的二层内部光缆，数据完全不经过公网出口审查网关，从物理通道上免疫了外界的任何阻断干扰。用户在需要极高可用率的生产力场景下，可参考我们每月基于真实数据维护的 2026 最稳定专线机场横评报告。

终极排障工具：Windows PowerShell 一键网络环境自检脚本

为了帮助工程师和普通用户免去繁琐的手动命令排查，我们编写了一段轻量级的自动化检测脚本。复制以下代码，在本地 PowerShell 中运行，脚本会自动对时钟偏差、核心端口、常用 DNS 及网络连通性进行一键体检：

Write-Host "==========================================" -ForegroundColor Cyan
Write-Host "  ProxyPick 网络环境与节点超时自动诊断脚本  " -ForegroundColor Cyan
Write-Host "==========================================" -ForegroundColor Cyan

# 1. 检查本地时间与标准 NTP 的偏差
Write-Host "`n[步骤 1/4] 正在检测本地系统时间精确度..." -ForegroundColor Yellow
try {
    $timeCheck = w32tm /stripchart /computer:ntp.aliyun.com /samples:1 /dataonly
    Write-Host "系统时间同步检测通过 (参考对齐源: ntp.aliyun.com)" -ForegroundColor Green
} catch {
    Write-Host "警告: 无法连接外部 NTP 服务器，请手动检查系统时钟！" -ForegroundColor Red
}

# 2. 检查 7890 代理端口监听状态
Write-Host "`n[步骤 2/4] 正在检查 7890 端口监听状态..." -ForegroundColor Yellow
$portCheck = Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
if ($portCheck) {
    Write-Host "7890 端口已就绪，当前监听进程 PID: $($portCheck.OwningProcess[0])" -ForegroundColor Green
} else {
    Write-Host "提示: 7890 端口未处于监听状态。请确认客户端是否已正常启动！" -ForegroundColor Yellow
}

# 3. 检查国内外主流 DNS 连通性
Write-Host "`n[步骤 3/4] 正在检测国内公共 DNS 解析能力..." -ForegroundColor Yellow
try {
    $dnsTest = Resolve-DnsName -Name "www.baidu.com" -Server "223.5.5.5" -QuickTimeout -ErrorAction Stop
    Write-Host "DNS 解析功能正常，解析成功: $($dnsTest.IPAddress[0])" -ForegroundColor Green
} catch {
    Write-Host "错误: 本地无法通过公共 DNS 解析域名，网络物理链路可能断开！" -ForegroundColor Red
}

# 4. 检查测速目标服务连通性
Write-Host "`n[步骤 4/4] 正在测试延迟测试 URL 响应..." -ForegroundColor Yellow
try {
    $webTest = Invoke-WebRequest -Uri "http://cp.cloudflare.com/generate_204" -UseBasicParsing -TimeoutSec 3
    if ($webTest.StatusCode -eq 204) {
        Write-Host "延迟测速端点连通性测试通过 (HTTP 204 正常返回)！" -ForegroundColor Green
    }
} catch {
    Write-Host "测速端点直连超时，此为正常现象 (需配合代理分流规则访问)。" -ForegroundColor Gray
}

Write-Host "`n==========================================" -ForegroundColor Cyan
Write-Host "诊断完成。如全部正常但节点依然超时，请执行更新订阅操作！" -ForegroundColor Cyan
Write-Host "==========================================" -ForegroundColor Cyan

总结与快速自救速查表

在遭遇节点大面积超时的紧急时刻，记住以下“黄金三步走”急救策略：

先对表：进入系统设置，点击时间“立即同步”，消灭时钟偏差；
查状态：登录机场官网，确认套餐未到期、流量没烧完；
更订阅：在客户端中点击“更新订阅”，重新加载最新入站路由，遇到报错可参考订阅链接拉取失败与更新报错排查指南。

如果确认所有节点恢复绿字延迟后，个别关键海外服务依然提示访问受限，可进一步查阅 ChatGPT 拒绝访问 1020 报错排查以及 Netflix 提示使用代理检测报错排查。

从根本上规避节点频繁大面积超时，建议深入理解公网中转与公网直连节点差异，优先选择基于物理二层硬隔离的企业级 IEPL 专线网络。追求极致抗波动能力的用户可参考 2026 最稳定专线机场横评排行榜，预算有限的用户也可在高性价比平价便宜机场推荐榜单中挑选高可用服务商。