这套检查顺序适合 v2rayN、v2rayNG 与 v2flyNG 已经导入节点，但延迟测试显示超时、启动后网页打不开或日志持续出现连接错误的情况。排查时先确认本地网络，再核对时间、订阅、协议参数和服务端状态；每完成一层就重新测试一次，可以更快判断问题发生在哪一段。
第一类：先确认本地网络与代理入口
“节点超时”只表示客户端在规定时间内没有拿到预期响应，并不能直接证明节点已经失效。请求从浏览器到远端服务器，中间还会经过系统代理、本地监听端口、V2Ray 或 Xray 内核、DNS、路由器和当前网络。任何一段没有接通，都可能在客户端里表现为超时。
第一步先完全退出客户端，再用浏览器打开两个平时可以直接访问的网站。如果普通网站也打不开，应先恢复本地网络，例如重新连接路由器、切换到另一条可用网络，或检查是否存在需要登录确认的公共网络页面。此时反复更新订阅不会改变结果，因为订阅请求本身也需要可用的基础网络。
基础网络正常后启动客户端，但暂时不要只看托盘图标。以 v2rayN 7.x 为例，应观察主窗口底部或日志区域是否显示内核已启动，并检查当前选中的服务器。常见本地监听端口是 SOCKS 的 10808 和 HTTP 的 10809，不同版本与个人配置可能不同，应以「设置」→「参数设置」中显示的端口为准。端口被其他程序占用时，内核可能启动失败，系统代理却仍指向旧端口。
关闭旧进程
退出 v2rayN 后打开任务管理工具，确认先前的 V2Ray 或 Xray 内核进程已经结束，再重新启动客户端，避免旧进程继续占用本地端口。
核对监听端口
进入「设置」→「参数设置」，记下本地 SOCKS、HTTP 或混合代理端口；再检查浏览器或其他应用填写的端口是否与客户端一致。
重设系统代理
先选择清除系统代理，再重新启用系统代理。这个动作可以修正客户端异常退出后遗留的旧地址与旧端口。
切换本地网络
在条件允许时换一条网络测试同一节点。若原网络连续三次超时，而另一条网络能在 1 至 3 秒内完成连接，问题更可能位于原网络或路由设备。
第二类：校准系统时间与时区
VMess 的认证过程依赖时间，设备时钟偏差过大时可能直接认证失败。使用 TLS 的 VMess、VLESS 或其他配置也会检查证书有效时间。设备日期、时区或自动校时异常，既可能导致节点连接失败，也可能让订阅页面出现证书时间错误。
时间看起来只差一分钟也值得处理。日常建议让设备自动获取时间和时区，不要只手动修改屏幕上显示的小时数。尤其是在更换时区、系统休眠较久、主板时钟异常或路由器阻止时间同步后，显示时间与实际标准时间可能并不一致。
Windows
打开「设置」→「时间和语言」→「日期和时间」，启用自动设置时间与自动设置时区，然后点击立即同步。完成后退出并重新启动 v2rayN。
macOS
打开「系统设置」→「通用」→「日期与时间」，启用自动设定日期与时间，并确认当前时区与所在地一致。
Android
打开系统「设置」中的日期和时间选项，启用自动设置时间与自动设置时区，然后彻底停止并重新打开 v2rayNG 或 v2flyNG。
校时后应重新启动客户端内核，而不是只重新做一次延迟测试。已经建立的失败连接、DNS 缓存和旧会话可能仍留在进程中。若校时前所有节点都失败，校时后多个不同地区节点同时恢复，通常可以确认根因位于设备时间，而不是订阅中的某一个服务器。
报错:x509: certificate has expired or is not yet valid
原因与解法:TLS 证书可能确实过期，也可能是设备日期偏离实际时间。先同步系统时间和时区；若只有一个节点继续报错，再由服务端维护方检查证书。
报错:invalid user
原因与解法:认证信息未被服务端接受，VMess 场景应先校准时间，再核对 UUID、alterId 与订阅内容是否完整，避免直接修改多个参数后失去排查线索。
结论：全部节点同时失败，先查设备共同条件
同一设备上的多个独立节点在同一时间全部超时，更应优先检查网络、系统时间、本地端口和内核状态；单个远端服务器同时故障无法解释这种一致现象。
第三类：检查订阅是否有效且已真正更新
订阅地址能添加到客户端，不等于其中的节点一直有效。订阅可能到期、流量额度用完、访问凭据变化，也可能已经生成新节点，但客户端仍在使用上一次缓存的列表。更新订阅与测试节点是两个动作：前者获取配置，后者才尝试连接配置中的服务器。
在 v2rayN 中，可从「订阅分组」选择对应分组，再执行更新全部订阅。若当前代理已经不可用，优先尝试“不通过代理”更新，避免客户端拿失效节点去请求新的订阅内容。更新完成后查看节点数量、服务器地址和更新时间是否变化，不要只看到“更新完成”四个字就结束检查。
确认订阅可访问
在基础网络正常的前提下重新更新订阅，观察客户端提示的是成功、HTTP 错误、解析失败还是连接超时。不同结果对应的处理方向并不相同。
查看分组内容
确认更新的是当前正在使用的订阅分组。多个分组并存时，旧节点可能仍保留在列表中，名称相似也容易选错。
重新选择节点
更新后从新列表中选择服务器，并明确设为活动服务器。只更新列表不会自动保证当前活动项已经切换到新配置。
测试三个节点
选择不同地址或不同地区的三个节点，各测试两次。只有一个失败通常是单节点问题；三个都在相近时间超时，则继续检查参数或服务状态。
报错:unexpected EOF
原因与解法:订阅响应或远端连接在完成前被关闭。先重新获取订阅；若更新成功但连接时仍出现该错误，再检查传输层参数与服务端状态。
报错:failed to parse config
原因与解法:导入内容不符合当前客户端或内核预期的配置格式。删除刚导入的异常副本，重新更新订阅，并确认没有把网页地址、说明文字或截断内容当成节点配置。
报错:failed to find an available destination
原因与解法:出站目标未能形成可用连接，常见线索包括服务器域名解析失败或路由没有可用出站。检查节点地址拼写、DNS 设置与活动出站后重启内核。
第四类：逐项核对协议、传输与 TLS 参数
节点地址和端口可达，并不代表协议参数正确。VMess、VLESS 的身份字段不同，TCP、WebSocket、gRPC 等传输方式也不能互相替代。只要 UUID、端口、传输类型、路径、服务名、TLS 开关或服务器名称中有一项不匹配，连接就可能超时、被立即关闭或在握手阶段失败。
排查时不要凭经验把端口统一改成 443，也不要看到 WebSocket 就随意填写路径。端口 443 常用于 TLS，但服务端完全可以监听其他端口；WebSocket 的 Host 与 Path、gRPC 的 serviceName 都必须与服务端配置一致。订阅导入的配置通常应保持原样，只有在拿到明确参数后才逐项修正。
| 检查项 | VMess | VLESS | 常见错误表现 |
|---|---|---|---|
| 用户标识 | UUID，现代配置的 alterId 通常为 0 | UUID，部分配置还包含 flow | 认证失败、连接后立即关闭 |
| 传输方式 | 需匹配 TCP、WebSocket 或其他既定方式 | 需匹配 TCP、WebSocket、gRPC 等既定方式 | 握手超时、unexpected EOF |
| TLS 参数 | 核对 TLS 开关与服务器名称 | 核对 TLS、服务器名称及订阅给出的安全参数 | TLS handshake timeout、证书名称错误 |
| 附加字段 | WebSocket 常需核对 Host 与 Path | gRPC 常需核对 serviceName | 服务器返回拒绝或持续等待 |
还要确认客户端所用内核能够处理该配置。v2rayN 可以在「设置」→「参数设置」→「Core 类型」查看或调整所用内核；具体菜单文字会随版本略有变化。包含 VLESS 特定能力的配置通常应交给兼容的 Xray 内核。Android 上，v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核，不能假定两者支持的全部配置字段完全相同。
如果配置来自订阅，最稳妥的对照方式是保留原节点，再复制一份用于单项修改。每次只改一个字段并重新启动内核。例如先核对端口，再核对传输类型，然后检查 TLS 与服务器名称。一次同时改 UUID、路径、端口和 TLS，即使恢复连接，也无法知道真正错误发生在哪里。
报错:TLS handshake timeout
原因与解法:TCP 可能已经连通，但 TLS 握手未在时限内完成。核对服务器名称、TLS 开关、端口与系统时间，再换网络排除链路干扰。
报错:dial tcp: i/o timeout
原因与解法:客户端在建立 TCP 连接时未及时收到响应。检查服务器地址、端口、本地网络和防火墙；若只有该地址失败，再判断远端端口是否停止监听。
报错:connection refused
原因与解法:目标主机明确拒绝了连接，通常表示地址可达但该端口没有对应服务，或入口规则主动拒绝。核对端口后联系服务维护方确认监听状态。
结论：超时与拒绝连接要分开处理
i/o timeout 更像是请求没有得到及时回应，而 connection refused 表示目标明确拒绝。前者先查网络路径和地址，后者优先核对端口及服务端监听。
第五类：用交叉测试判断服务端状态
完成前四层后，如果基础网络正常、时间准确、订阅刚更新且参数一致，就需要判断远端服务器是否正在维护、端口是否停止监听，或线路是否只对某一网络不可达。这里不应继续随机修改客户端设置，而应建立可对照的测试结果。
最有价值的对照包含三个维度：同一设备换节点、同一节点换网络、同一订阅换设备。一次只改变一个条件。例如同一台 Windows 设备上，节点 A 连续三次在 10 秒以上超时，而同分组节点 B 和 C 都能在 2 秒内打开网页，证据更偏向节点 A；若 A、B、C 在当前网络都失败，换网络后全部恢复，则更偏向原网络路径。
- 只有一个节点失败：保留日志中的时间、服务器地址和错误类型，等待服务端恢复或使用同订阅中的其他节点。
- 同一地区节点集中失败：可能是该组入口或线路异常，先切换不同地址测试，不要反复重装客户端。
- 所有节点只在一条网络失败：检查路由器、DNS、网络访问限制和防火墙策略，并使用另一条网络复测。
- 所有设备都无法使用同一订阅：确认订阅有效期、流量状态与服务通知，避免继续修改每台设备的本地端口。
- 只有一个设备失败：回到本地监听、系统代理、时间和内核配置，重点比较它与正常设备的差异。
查看日志时，应关注第一次失败，而不是只看后面重复出现的连锁错误。v2rayN 的运行信息通常会记录目标地址、连接阶段和内核返回内容；v2rayNG 与 v2flyNG 也可以在日志区域查看最近连接结果。先清空或记住当前日志位置，再发起一次访问，可以减少旧记录干扰。
报错:context deadline exceeded
原因与解法:某个操作超过内核或客户端设定的等待期限，单凭这一行无法确定根因。向上查看同一次请求更早出现的 DNS、TCP 或 TLS 错误，再按对应阶段处理。
报错:context canceled
原因与解法:连接任务被上层取消，常见于切换节点、重启内核或前序连接失败后的清理过程。若它紧跟在更具体的错误后面，应以前面的错误作为主要线索。
报错:network is unreachable
原因与解法:系统当前没有到目标网络的可用路径。检查设备是否联网、路由器是否正常、网络接口是否切换，并确认没有残留的代理或虚拟网络设置影响路由。
整套顺序可以概括为：先证明设备能正常联网，再让系统时间可信；接着确认订阅确实更新，核对节点协议参数；最后才通过多节点、多网络和多设备对照判断服务端。这样做的价值不是增加操作步骤，而是避免在本地网络故障时重建订阅，也避免在远端维护时反复修改正确的客户端配置。