适用于 v2rayNG 已导入节点，却出现连接超时、真实连接测试失败或浏览器无法访问的情况。先保留原配置，用同一节点比较不同网络，再核对时间、订阅、传输和证书，最后检查服务端监听与日志。每轮只改一个变量，避免把端口不可达、认证失败和 DNS 故障混成同一个问题。
一、先分清超时发生在哪一步
v2rayNG 是 Android 客户端，本文按使用 Xray 内核的配置排查。界面中的连接图标表示本地服务已启动，不代表远端节点已经完成握手。节点列表中的 TCP 测试、真实连接测试和浏览器访问，也分别验证不同层次，不能互相代替。
先在主界面选中目标节点，启动服务，再从菜单进入「日志」，重现一次失败并记录时间。菜单名称可能随版本变化；测试入口通常位于主界面菜单。保存报错时保留前后几行，但应遮住订阅地址、用户标识和密码。
| 观察结果 | 能够说明什么 | 下一步 |
|---|---|---|
| TCP 测试失败 | 目标地址与 TCP 端口暂时不可达；不适用于判断纯 UDP 传输 | 检查网络、域名解析与端口 |
| TCP 成功，真实连接失败 | 端口有响应，但代理握手或测试请求未完成 | 核对协议、TLS 与传输字段 |
| 真实连接成功，某个应用失败 | 测试目标可访问，不代表所有应用都经过代理 | 检查分应用代理、路由和应用自身设置 |
| 订阅更新失败 | 获取订阅内容的请求失败 | 单独排查订阅地址，不直接判定节点失效 |
二、本地网络：用同一节点比较 Wi-Fi 与移动数据
先停止 v2rayNG，确认浏览器能访问平时可直连的网站。公共 Wi-Fi 可能需要先在系统弹出的认证页登录；未完成认证时，代理连接通常也无法建立。随后保持节点和配置不变，分别在 Wi-Fi 与移动数据下启动一次服务。
- 只在 Wi-Fi 失败：检查路由器上网状态、认证页面以及该网络的 DNS。若移动数据正常，暂时不要修改节点的 UUID、密码或传输路径。
- 两种网络都失败：换一个已知可用的节点作对照。若所有节点同时失败，优先查本地 VPN 状态、时间和 DNS；若仅一个失败，继续核对该节点配置。
- 启动后立即停止：检查 Android 的 VPN 授权提示，停止其他占用系统 VPN 槽位的服务。启动失败与远端连接超时是两类问题。
- 仅锁屏后断开：在系统「设置」→「应用」→「v2rayNG」→电池相关选项中允许后台运行。各厂商路径不同，应以实际界面为准。
同时查看系统「设置」→「网络和互联网」→「VPN」中的始终开启及阻止未使用 VPN 的连接选项。旧 VPN 配置残留时，可能连用于对照的直连请求也被阻断。测试结束后恢复原有安全设置，不要为了排查长期关闭必要的防护。
三、系统时间与订阅：先排除过期配置
在 Android「设置」→「系统」→「日期和时间」中开启自动设置时间与时区；部分设备将入口放在「更多设置」。确认显示的日期和时刻正确，再停止并重新启动 v2rayNG。时间偏差可能影响证书有效期判断，也可能导致 VMess 认证失败。
订阅链接能打开，不等于节点仍然有效。登录订阅提供方的管理页面，核对有效期、流量额度和节点变更公告。在 v2rayNG「订阅分组设置」中确认来源地址，再返回主界面执行订阅更新；不同版本的更新命令可能显示为「更新订阅」或「更新当前组订阅」。
- 更新前保留原配置记录，更新后重新选中节点，避免继续测试已经被替换的旧条目。
- 订阅请求本身需要代理时，只能借助另一个确实可用的节点更新；用故障节点更新同一来源容易形成循环。
- 检查导入结果是否包含服务器地址、端口、协议与认证字段。返回登录页面或错误页面的链接不是有效订阅内容。
- 不要把完整订阅地址交给陌生在线转换页面。链接通常携带访问凭据，排查时也应按凭据处理。
四、传输参数：地址、端口、Host 与路径分别核对
在节点列表点击目标条目的编辑图标，逐项对照服务端或提供方给出的原始参数。不要因为节点名称写着某种传输方式，就认定编辑页配置一定一致。服务器地址决定连接到哪里；端口决定连接哪个入口；传输类型决定后续如何建立通道。
这些是协议端口知识，不是推荐配置。节点原来使用其他端口时，不能只把客户端改成 443；服务端监听、防火墙和转发入口必须配套。DNS 能返回地址，也不能证明节点端口可达。
- WebSocket：核对传输类型、Host 和路径。路径中的大小写、前导斜杠、查询参数都应与服务端要求一致。反向代理转发错误也会导致握手失败。
- gRPC：核对服务名称及提供方要求的相关选项，不要把 WebSocket 的路径直接填入服务名称字段。
- 协议认证：VMess、VLESS 的用户标识以及 Trojan、Shadowsocks 的密码应与服务端对应。更换传输方式不能修复错误凭据。
- 域名解析：若日志显示节点域名解析失败，先查本地解析链路。临时用服务端确认的 IP 作对照时，仍需保留正确的 TLS 服务器名称。
结论：TCP 可达后再查握手参数
同一地址与端口在两种网络下都无法建立 TCP 连接时，先查监听和网络路径；TCP 已成功而代理请求失败时，再逐项核对认证、传输和 TLS。不要同时替换 DNS、端口与路径。
五、TLS 与日志：根据报错定位连接阶段
TLS 的服务器名称通常对应 SNI 与证书名称验证，不等于 WebSocket 的 Host，也不一定等于实际拨号地址。三者可以相同，但不能凭名称相似就互相替换。使用 REALITY 的节点还需要核对服务端提供的公钥、short ID 与服务器名称，不能按普通 TLS 节点随意改写。
报错：i/o timeout
原因与解法：某一步网络读写超过等待期限，单独这一行不能确定故障层；查看前文目标地址和操作阶段，再比较网络与服务端同期日志。
报错：connection refused
原因与解法：目标主机或中间设备主动拒绝连接；核对端口，确认服务端进程正在监听，并检查是否存在主动拒绝规则。
报错：no such host
原因与解法：域名解析未得到可用结果；确认报错对象是节点域名还是访问目标，再检查拼写、DNS 配置与该域名的解析记录。
报错：x509: certificate has expired or is not yet valid
原因与解法：证书有效期与当前时间不匹配；先校准手机时间，仍失败则由服务端管理员检查证书续期与实际加载的证书。
报错：websocket: bad handshake
原因与解法：服务端没有返回预期的 WebSocket 升级响应；核对路径、Host 和反向代理转发规则，并结合返回状态码排查。
六、服务端：确认监听、放行规则与转发链路
使用他人提供的节点时，将失败时间、网络类型、客户端版本和脱敏后的报错提交给维护方。自行维护服务器时，先确认运行状态，再查系统防火墙、云安全组、容器端口映射以及反向代理。客户端超时不一定会留下服务端应用日志：流量尚未到达进程时，应用自然没有记录。
下面是 Linux 服务端只读排查命令。先列出实际服务单元；只有确认部署使用名为 xray 的 systemd 服务时，才执行后两条。使用容器或其他服务名的部署，应查对应进程与容器日志。
ss -lntp
ss -lnup
systemctl list-units --type=service --all
systemctl status xray --no-pager
journalctl -u xray --since "10 minutes ago" --no-pager- 核对实际监听端口和地址。后端只监听
127.0.0.1，由同机反向代理接入，可以是正常部署；若客户端直连该后端，则需要匹配的对外入口。 - 逐层核对云安全组与主机防火墙。放行规则必须匹配实际协议和目标端口，不能只看规则名称。
- 检查域名的 A 与 AAAA 记录。若解析到旧地址或未配置好的 IPv6 入口，应修正对应记录或网络，而不是反复重装客户端。
- 在手机发起一次测试，同时观察入口与后端日志。入口有请求、后端无请求时，重点检查反向代理；后端收到请求但认证失败时，核对用户凭据。
七、常见追问与排查收尾
延迟数字正常，为什么还是打不开网页？
先确认数字来自 TCP 测试还是真实连接测试。TCP 只证明端口有响应；真实连接也只验证指定测试目标。启动服务后查看浏览器请求日志，再检查分应用代理是否排除了浏览器，以及路由是否把目标送到预期出站。
订阅更新一直超时，需要删除全部节点吗？
先保留现有配置，检查订阅地址和有效期。若直连无法获取订阅，用另一个可用节点尝试更新；若提供方已更换地址，修改对应分组即可。清空节点不能修复订阅服务器不可达。
同一个节点在电脑上能用，手机上不能用？
先让两台设备接入同一网络，再比较 v2rayN 与 v2rayNG 中的服务器地址、端口、传输、SNI 和认证字段。确认两端测试的是同一配置，而非同名旧节点，并记录各自内核版本；字段兼容性问题应按具体报错处理。
把连接超时调长，能不能恢复？
只有链路确实能完成握手、但耗时偏长时，增加等待时间才可能有用。对端未监听、证书错误和凭据不匹配不会因此恢复。先用日志确认失败阶段，不要将更长的等待误认为修复。
最后保留一份排查记录：客户端与内核版本、测试时间、网络类型、节点是否完成更新、首次报错以及每次改动。恢复无效改动后再次测试。这样提交给维护方的信息足够定位问题，也能避免下次故障从头猜测。基础连接与路由概念可继续查阅疑难解答和进阶配置。