节点显示超时，不等于协议本身失效。相同的红色延迟结果，可能来自订阅仍保留旧地址、系统时间偏差、域名解析失败、本地监听端口冲突，也可能是传输层参数与服务端不一致。直接反复切换节点会把这些原因混在一起，日志也会被大量重复请求覆盖。
更稳定的做法是固定排查顺序，每轮只改变一个变量，并记录客户端版本、测试时间、网络类型与核心日志。本文适用于桌面端 v2rayN，以及 Android 上使用 Xray 内核的 v2rayNG、使用 v2fly 内核的 v2flyNG。菜单名称可能随小版本调整，但订阅、时间、端口、网络与协议五层判断保持一致。
本文速览
先用订阅更新时间和另一网络确认节点信息是否仍有效，再把系统时间偏差压到 30 秒以内；随后检查本地 SOCKS 端口 10808、HTTP 端口 10809 与防火墙，最后逐项核对地址、端口、UUID、传输方式、TLS、SNI 与路径。按这条链执行，可以判断故障停在本地、网络入口还是远端握手阶段。
先确定超时发生在哪一段
一次代理连接至少经过应用、本地代理监听、路由规则、远端网络连接和协议握手。浏览器只显示“连接超时”，无法说明是哪一段失败。应先打开客户端日志，再发起一次可重复的请求。例如关闭其他下载任务，只访问一个固定网页，并保留请求前后 30 秒的日志。
延迟测试也要区分类型。TCP 探测只说明远端地址与端口能否建立连接，不代表 VLESS 或 VMess 握手成功；真实延迟会经过完整代理链，更接近实际访问。若 TCP 延迟为 86 ms，而真实延迟持续显示超时，应优先检查协议、安全层和传输参数，而不是先改本地 DNS。
应用请求
本地端口
路由匹配
远端连接
协议握手
报错:context deadline exceeded
原因与解法:请求在限定时间内没有完成，单凭这一行不能定位原因。向上查看同一时间附近的 DNS、dial、TLS 或 transport 日志，再按本文顺序缩小范围。
报错:connection refused
原因与解法:目标主机主动拒绝当前端口，常见于服务端端口调整、进程未监听或入口规则变化。先更新订阅，不要自行猜测并替换端口。
结论:日志位置比“超时”字样更重要
本地监听失败通常在启动核心时立即出现；远端拨号和握手错误只会在流量经过该节点后出现。先确认报错阶段，再决定检查端口还是协议参数。
第一步：更新订阅并确认节点仍有效
订阅是节点参数的来源。服务端更换域名、入口端口、UUID、传输路径或安全层后，本地旧节点仍可能保留在列表中，但连接会持续超时。排查时不要只看节点名称是否相同，应查看订阅最后更新时间，并确认更新后的节点数量、地址和端口是否发生变化。
在 v2rayN 中先进入「订阅分组」→「订阅分组设置」，确认订阅地址完整且分组已启用；返回主界面后选择「订阅分组」→「更新全部订阅（不通过代理）」。如果当前网络无法直接取得订阅，再连接一个已确认可用的节点，改用「更新全部订阅（通过代理）」。两种方式只选一种完成测试，避免连续操作覆盖错误现场。
-
记录旧状态
记下节点数量、订阅更新时间和当前选中节点。示例记录为 24 个节点、最后更新 2026-05-27 21:10，便于判断更新是否真正发生。 -
更新订阅
打开「订阅分组」→「更新全部订阅（不通过代理）」。等待完成提示，不要在更新过程中退出客户端或切换网络。 -
检查变化
比较更新前后的地址、端口与节点总数。若数量由 24 变为 21，先使用新列表，不要从旧备份恢复已移除节点。 -
单节点复测
选中一个新节点，重启核心后测试三次。每次间隔 5 秒；若三次均超时，再继续检查时间与网络，不要批量改协议。
报错:failed to find an available destination
原因与解法:出站地址没有得到可用解析结果。核对订阅中的域名拼写，切换到稳定 DNS 后重启核心，再进行一次单节点测试。
报错:unexpected EOF
原因与解法:远端在响应完成前关闭连接。先确认订阅已刷新；若多个网络下只有该节点复现，应保留日志并向节点服务方核对入口状态。
第二步：校准系统时间并检查域名解析
VMess 的认证依赖时间窗口，TLS 证书校验也依赖系统日期。设备时间偏差数分钟时，普通网页可能仍能打开，但代理握手会失败。先开启系统自动设置日期、时间与时区，再触发一次立即同步。建议把偏差控制在 30 秒以内；超过 90 秒就应先校时，不要继续调整节点参数。
时间准确后再看 DNS。节点地址如果是域名，本地必须先把它解析为可连接的 IP。可在终端执行系统自带的查询命令，观察是否返回地址以及响应耗时。连续三次查询都超过 2000 ms，或交替出现解析失败，说明问题发生在协议握手之前。
- 确认系统日期、时区和夏令时规则与所在地一致，不能只看任务栏中的小时和分钟。
- 暂停后恢复的电脑应重新同步时间；长时间休眠后，时间服务可能尚未完成校准。
- 更换网络后重新解析节点域名，避免继续使用失效的本地缓存结果。
- 若订阅地址能打开，但节点域名不能解析，分别记录两个域名的查询结果，不要把它们视为同一故障。
nslookup node.example.net
期望观察:
Address: 203.0.113.20
首次响应: 42 ms
连续查询: 均返回同一组有效地址报错:certificate has expired or is not yet valid
原因与解法:系统时间不正确，或远端证书当前不在有效期内。先同步系统时间；时间准确后仍出现同一错误，再由节点服务方检查证书状态。
报错:no such host
原因与解法:节点域名解析失败。检查地址是否夹带空格或错误字符，清理本地 DNS 缓存并更换网络复测。
第三步：检查本地端口、核心状态与防火墙
节点参数正确，也要先由本地核心成功监听代理端口。v2rayN 常见配置会使用 SOCKS 端口 10808，并从该端口派生 HTTP 端口 10809；实际值以「设置」→「参数设置」中的本地监听配置为准。如果浏览器填写 10809，而客户端已经改成 20809，请求不会进入当前核心。
端口冲突通常发生在旧核心未退出、另一个客户端仍在运行，或系统休眠恢复后遗留进程。关闭 v2rayN 窗口不一定代表后台进程已经结束，应从托盘执行退出，再重新启动。排查期间只保留一个客户端和一个核心实例，避免多个程序同时修改系统代理。
-
确认核心运行
查看主界面底部状态与日志。启动后应出现监听成功信息；若日志在一秒内退出，先处理核心启动错误。 -
核对监听端口
进入「设置」→「参数设置」，记录 SOCKS 端口 10808 与 HTTP 端口 10809。浏览器或其他应用必须填写对应类型的端口。 -
释放冲突端口
完全退出其他代理客户端与遗留核心，再重启 v2rayN。若 10808 仍被占用，可改为 20808，并同步调整 HTTP 端口和应用设置。 -
检查防火墙
确认当前核心程序允许在正在使用的网络类型下通信。测试完成后恢复既定安全策略，不要长期放宽无关程序的入站权限。
正常监听示例:
SOCKS listening on 127.0.0.1:10808
HTTP listening on 127.0.0.1:10809
冲突示例:
failed to listen TCP on 127.0.0.1:10808
bind: address already in use报错:bind: address already in use
原因与解法:当前本地端口已被其他进程占用。退出遗留核心，或在「设置」→「参数设置」中更换本地端口，并同步修改系统代理和浏览器设置。
报错:connection refused 127.0.0.1:10809
原因与解法:应用访问了没有监听的本地端口。确认核心正在运行，并核对应用使用的是 HTTP 端口而不是 SOCKS 端口。
结论:先验证本地监听，再判断远端节点
若访问 127.0.0.1 的代理端口已经被拒绝，请求根本没有到达节点。此时切换 VLESS、VMess 或传输方式不会产生有效结果。
第四步：用另一网络区分线路与节点故障
订阅、时间和本地端口都正常后，应在不修改节点参数的前提下切换网络。可以把家庭宽带与移动热点作为两组对照：同一节点、同一客户端、同一测试地址，各执行三次真实延迟测试。只改变网络入口，才能判断问题是否集中在当前线路。
例如家庭网络三次结果均超时，移动热点分别为 118 ms、126 ms、121 ms，说明节点配置至少可以完成握手，排查重点应转向家庭网络的 DNS、路由或防火墙。如果两种网络都在约 10 秒后超时，则更可能是远端端口不可达或协议参数不一致。
| 测试现象 | 更可能的位置 | 下一步 |
|---|---|---|
| 两种网络都立即拒绝 | 远端端口或入口状态 | 更新订阅并核对端口 |
| 一种网络可用，另一种超时 | 本地线路、DNS 或路由 | 保留节点参数，检查当前网络 |
| TCP 可达，真实延迟超时 | 协议握手或安全层 | 核对 UUID、TLS、SNI 与传输 |
| 所有节点同时失败 | 订阅、本地核心或网络入口 | 回查更新时间与核心日志 |
第五步：逐项核对协议与传输参数
只有前四层通过后，才需要进入节点编辑界面。先确认协议类型是 VLESS 还是 VMess，再逐项比较服务端给出的参数。UUID 是认证标识，不应凭经验改写；端口必须与入口监听一致；传输方式的 TCP、WebSocket、gRPC 不能互换。TLS、REALITY 等安全层也必须与服务端配置对应。
WebSocket 场景要检查 Host 与路径，路径中的斜杠和大小写都可能影响路由。gRPC 要核对服务名。TLS 场景通常还要检查服务器名称，也就是 SNI；连接地址可以是 IP，但证书校验所用名称仍需与服务端要求一致。REALITY 配置则要核对服务器名称、公钥和短 ID，不能把普通 TLS 字段直接套用。
| 参数 | 检查重点 | 常见表现 |
|---|---|---|
address 与 port |
域名可解析，端口与订阅一致 | 拨号超时或连接被拒绝 |
UUID |
字符完整，未混入空格 | 认证失败或远端立即断开 |
network |
TCP、WebSocket、gRPC 与服务端一致 | TCP 可达但传输握手失败 |
security |
TLS、REALITY 或指定安全层一致 | 证书或握手错误 |
SNI 与 Host |
使用服务端指定域名 | 证书名称不匹配或入口拒绝 |
| 路径或服务名 | 大小写、前导斜杠与内容完全一致 | 远端返回异常响应或提前关闭 |
报错:tls: failed to verify certificate
原因与解法:证书名称、有效期或信任链校验失败。先确认系统时间，再核对节点中的服务器名称与服务端要求，不要把跳过证书验证当作长期处理方式。
报错:invalid user
原因与解法:认证信息未被远端接受。重新更新订阅并核对 UUID，不要手工拼接来自不同节点的地址、端口与认证字段。
报错:websocket: bad handshake
原因与解法:WebSocket 握手未得到预期响应。检查传输类型、Host、路径与 TLS 设置，并确认请求到达正确入口。
不同客户端上的复测要点
桌面端 v2rayN 适合直接查看核心启动、监听和出站日志。排查前可在「帮助」→「关于」记录客户端版本，并在日志开头记录核心版本，例如客户端 7.x 与 Xray-core 25.x。版本号不是故障结论，但能帮助判断同一配置是否在不同核心环境中复现。
Android 上的 v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核。把同一订阅分别导入两个不同内核客户端，只适合确认配置兼容性，不应在同一轮测试中同时改传输参数。移动网络与无线网络切换后，要重新执行连接测试，因为系统分配的 DNS 和出口路径可能已经变化。
订阅更新一直提示超时怎么办？
先复制订阅地址并确认字符完整，再分别尝试「更新全部订阅（不通过代理）」和「更新全部订阅（通过代理）」。第二种方式需要先连接一个已确认可用的节点。
延迟有数值，但网页还是打不开？
确认系统代理已经开启，并检查浏览器是否使用正确的 HTTP 端口。延迟测试成功只代表测试请求通过，不代表浏览器流量已经进入 10809。
所有节点突然同时超时正常吗？
多个不同入口同时失败时，先检查本地核心、系统时间、订阅更新时间和当前网络。逐个编辑几十个节点通常不能解决共同故障。
更换本地端口后还要改哪里？
如果把 HTTP 端口从 10809 改为 20809，需要同步更新系统代理、浏览器扩展和其他手工配置的应用。SOCKS 应用则使用对应的 20808。
TCP 测试成功为何仍提示握手失败？
TCP 测试只确认地址和端口可连接。继续核对协议类型、UUID、传输方式、TLS、SNI、WebSocket 路径或 gRPC 服务名。
完成修复后的验证顺序
找到原因后不要只验证一次。先重启核心，确认本地端口监听成功；再执行三次真实延迟测试；随后打开普通网页和需要代理的目标地址；最后等待 10 分钟再复测一次。短时间内偶然成功，可能只是 DNS 缓存或线路切换尚未稳定。
建议把最终结果记录为“客户端与核心版本、网络类型、节点协议、修复项、三次延迟”。例如：v2rayN 7.x、Xray-core 25.x、家庭宽带、VLESS over WebSocket with TLS、修正 SNI，三次结果为 92 ms、95 ms、91 ms。这样的记录比“重装后好了”更适合下次复用。
-
重启核心
确认日志中 10808 与 10809 均监听成功，且启动后没有端口冲突或配置解析错误。 -
执行三次测试
每次间隔 5 秒。三次真实延迟差值若低于 50 ms，说明当前连接状态相对稳定。 -
验证应用流量
检查浏览器、系统代理与单独配置的应用，确认它们使用的代理类型和端口与客户端一致。 -
保留有效记录
保存错误时间、关键日志和修复项，不要保存已经失效的订阅参数作为长期配置。
结论:固定顺序能避免误判
订阅、时间、端口、网络、协议参数是一条由外到内的排查链。前一层没有通过，就不要进入下一层批量改配置；每次只改一个变量，才能得到可重复的结论。