适合遇到 v2rayN 测试超时、启用代理后网页打不开、换节点仍然无法连接的用户。先用直连和显式代理请求分开验证本机与客户端，再核对节点参数、传输配置和服务端监听。每次只改一项，并保留对应日志，避免把端口占用、DNS 故障和远端不可达混成同一个问题。
先区分：测试超时还是实际请求失败
“节点超时”不是一个完整诊断。TCP 连接测试只回答远端端口是否能建立连接；真连接延迟测试还涉及代理协议、测试地址和请求超时设置。列表里显示超时，不一定代表所有网站都不能访问；显示一个延迟数字，也不代表证书、路由和所有应用都正常。
先选中一个节点作为活动配置，再打开一个固定的 HTTPS 地址。不要同时切换节点、路由模式和 DNS。把故障出现的时间记到分钟，并查看同一时刻的内核日志；只截一张节点列表，通常看不出连接卡在哪一层。
- 所有节点都超时：优先检查本机网络、内核启动、本地端口和公共配置；同一来源的节点也可能同时受服务端故障影响。
- 只有一个节点失败：优先比较它的服务器地址、端口、传输方式和远端状态，不要先重置整套客户端。
- 浏览器失败、显式代理请求成功：重点查系统代理、浏览器代理扩展和路由，而不是继续修改节点凭据。
- 仅一个测试地址失败：换一个已知可访问的目标复测，区分测试站点异常与节点异常。
第一步：退出代理，确认本机网络与 DNS
在 v2rayN 托盘菜单的「系统代理」中选择「清除系统代理」，同时关闭 TUN 模式。暂时退出其他会接管网络的工具，避免流量仍绕经虚拟网卡。然后访问平时能够直连的站点；若此时也打不开，先处理 Wi-Fi 登录、网关或运营商连接。
-
恢复直连
清除系统代理并关闭 TUN 后重新打开浏览器。浏览器若配置过独立代理，也要恢复为使用系统设置，不能只退出客户端主窗口。
-
检查地址
在 Windows 终端运行
ipconfig，查看当前网络适配器的 IPv4 地址和默认网关。出现169.254.x.x且没有可用网关时，先重新连接网络或排查 DHCP。 -
检查解析
运行下面的 DNS 命令。先确认普通域名可解析，再对节点实际使用的域名执行同样检查；若节点填的是 IP 地址，这一步不验证节点地址解析。
-
更换网络
用手机热点对同一节点复测一次。只有原网络失败时，优先排查当前网络的 DNS、出口策略和路由，不急着重装客户端。
ipconfig
nslookup example.comexample.com 仅用于演示命令格式，不是节点服务器。解析成功只说明得到了地址，不说明该地址上的服务可连接。也不要因为 ping 没有响应就认定节点离线：远端可能禁用了 ICMP，而 TCP 服务仍然正常。
第二步：检查内核、本地端口与系统代理
恢复基础网络后，启动客户端并选定节点。进入 v2rayN「设置」→「参数设置」，检查本地监听配置与当前使用的内核；不同桌面版本的子页名称可能不同，以实际字段为准。先确认日志没有配置加载失败，再检查系统代理，不要直接用 TUN 掩盖普通代理模式的问题。
以下以本地 SOCKS 入口 127.0.0.1:10808 为示例，实际端口必须以当前设置为准。有的配置使用混合入口，有的配置另设 HTTP 入口；旧配置里也可能见到 10809。不能只凭端口数字判断协议，更不能把 SOCKS 端口误填为 HTTP 代理。
netstat -ano | findstr :10808
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- 先看监听：
netstat输出中的LISTENING表示有进程监听，最后一列是 PID；输出为空时，应先检查内核是否启动、端口是否改过。 - 再看进程：到任务管理器「详细信息」按 PID 确认归属。发现端口被其他程序占用时，先确认用途，再关闭对应程序或修改本地监听端口，不要随意结束系统进程。
- 显式指定代理：示例中的
socks5h让目标域名通过 SOCKS 代理端解析；节点服务器自身的域名仍可能需要本机解析。--noproxy ""用于清除本次请求的直连例外。 - 区分返回结果：收到 HTTP 响应，说明本次目标的代理请求链路已有响应，即使状态码是 403 或 405；仍需结合目标站点策略判断。20 秒超时只是本次诊断上限，不是软件默认值。
结论：显式代理成功后再查接管方式
如果这条命令有响应而浏览器仍失败，保持节点参数不动，启用「系统代理」→「自动配置系统代理」，再检查浏览器扩展和系统代理例外。若显式请求也失败，继续查日志与远端连接，不要反复开关系统代理。
第三步：核对节点参数，不用猜测补字段
打开故障节点的编辑窗口，与服务端提供的原始配置逐项核对。VMess 和 VLESS 是不同协议，不能通过改一个协议名称互相转换。订阅只是配置分发方式，订阅更新成功也不代表节点可用、账户有效或远端服务正常。
| 核对项目 | 具体检查 | 常见误区 |
|---|---|---|
| 服务器与端口 | 逐字核对域名或 IP，以及远端监听端口 | 把本地 10808 当作服务器端口；将所有远端端口都改成 443 |
| 协议与身份 | 核对 VMess / VLESS、用户标识及服务端要求的相关字段 | 复制时丢失字符，或把不同节点的身份与地址混用 |
| 传输方式 | 核对 TCP、WebSocket 或 gRPC 等实际配置 | 认为传输方式只是显示名称，可以任意切换 |
| 安全设置 | 核对 TLS 或 REALITY，以及对应服务端名称和专用字段 | 把 REALITY 当成普通 TLS，只填域名就保存 |
| 路由与出站 | 确认测试目标实际命中预期出站，而非直连或阻断规则 | 活动节点选对了，就认定所有请求都会走该节点 |
如果订阅刚更新，先确认正在使用的是更新后的条目。重复名称容易导致选中旧配置，可以在保留原配置的前提下给测试条目加上便于辨认的备注。不要把完整分享链接、用户标识或订阅地址发到公开讨论区；提交故障信息时只保留协议、传输方式、错误文本与脱敏后的地址。
第四步：按日志定位 TLS 与传输层错误
先在客户端日志区域找到本次请求对应的时间，再看错误发生在域名解析、TCP 建连、TLS 握手还是传输建立阶段。下面是常见错误片段，不同内核的前后文会不同；单独出现 context deadline exceeded 只能说明超时，还要看它前面正在执行哪项操作。
报错：dial tcp: lookup
原因：常见于节点域名解析失败，完整日志通常还包含域名与 DNS 错误。
解法：先用 nslookup 检查同一域名，再核对客户端 DNS 与当前网络；修复后重试一次并观察新日志。
报错：connect: connection refused
原因：连接被明确拒绝，可能是目标端口未监听、防火墙主动拒绝，或本地代理入口根本未启动。
解法：先看报错地址是 127.0.0.1 还是远端；本地查监听，远端由管理员核查服务和防火墙。
报错：i/o timeout
原因：某个网络读写阶段超过期限，可能涉及丢包、静默丢弃或远端迟迟未响应。
解法：结合前文确认超时阶段，再换网络对照；不要仅凭这一行就认定密码错误或服务器离线。
报错：x509: certificate has expired or is not yet valid
原因：本机时间偏差，或服务端证书确实不在有效期内。
解法：先在 Windows「设置」→「时间和语言」→「日期和时间」中校时，再让管理员检查证书有效期。
报错：websocket: bad handshake
原因：WebSocket 升级响应不符合预期，常见于路径、Host、反向代理转发或目标服务不匹配。
解法：对照服务端核对 WebSocket 路径和 Host，并检查反向代理是否将该路径转发到正确的后端。
TLS 的 SNI 是握手时使用的服务器名称，WebSocket 的 Host 是 HTTP 请求字段，两者用途不同。服务端地址、SNI、Host 有时相同，有时按部署要求分别填写，不能照着地址栏统一替换。gRPC 还要核对 serviceName 与中间代理的 HTTP/2 支持；路径和名称中的大小写也应保持一致。
第五步：检查服务端监听与入口防火墙
前面的本机和参数检查都通过后，再由有权限的管理员检查服务端。普通订阅用户不需要寻找服务器登录凭据；向服务提供方提交故障时间、所用网络、节点备注和脱敏日志即可。以下命令用于 Linux 服务端，需在有相应权限的环境中执行。
sudo ss -lntp
sudo systemctl status xray --no-pager
sudo journalctl -u xray --since "20 minutes ago" --no-pager示例假设服务单元名为 xray。只有部署时确实使用该名称才直接执行；使用 V2Ray 或自定义服务单元的环境，应换成真实单元名。服务显示正在运行，不代表目标端口一定存在；应在 ss 输出中同时确认监听地址、端口和所属进程。
- 核对入口端口：若客户端实际使用 TCP 443，就检查公网入口的 TCP 443；不能只放行 UDP 443。其他端口按真实配置检查。
- 区分前后端：有反向代理时，公网 443 可能由反向代理监听，内核只监听回环地址上的后端端口。这种布局本身正常，不应直接把后端全部暴露到公网。
- 核对两层防火墙：云平台安全组与服务器防火墙都要允许实际入口；仅修改其中一层仍可能超时。
- 检查地址记录：域名有 A 和 AAAA 记录时，分别核对 IPv4、IPv6 的监听与可达性，避免一条地址正常、另一条连接失败。
- 检查服务日志：查找端口绑定失败、配置解析失败、用户认证失败和证书加载错误。日志没有请求记录时，也要确认请求是否停在前置反向代理。
结论：用同节点跨网络对照
同一节点在热点可用、原网络失败时，先保留服务端配置，继续排查原网络路径；多个网络都失败且服务端没有入口监听时，优先恢复远端服务。端口能连上但代理请求失败，则回到协议、认证与传输层日志。
节点超时常见问答与复测记录
所有节点都超时，要先重装 v2rayN 吗？
先不用。依次验证直连网络、内核日志、本地监听和显式代理请求。若同一来源的全部节点失败，而其他已知可用配置正常，应联系该来源核查服务状态。重新安装并不能修复远端停机或错误的订阅参数。
TCP 测试有延迟，为什么网页仍打不开？
TCP 建连成功不包含后续认证、TLS 和应用请求。使用前面的 curl.exe 命令测试完整请求，再看同一时刻日志；若完整请求成功，只修系统代理、浏览器设置或路由，不要改远端端口。
开启 TUN 后才断网，应该怎么恢复？
先关闭 TUN，并清除系统代理，确认直连恢复。再用普通系统代理验证节点，成功后才单独启用 TUN，检查权限、虚拟网卡、DNS 和路由接管。不要同时开启多套网络接管工具。
同一节点在安卓可用，桌面端却超时？
先让两端接入同一个网络，并确认服务器、端口和传输字段相同。v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核；不同内核对特定配置的支持并不完全一致。桌面端还需检查实际选择的内核、本地端口和系统时间。
修复后用相同目标连续请求 3 次，记录每次是否收到响应，再恢复日常路由和应用设置。单次成功不能排除间歇性故障，持续失败也不能仅靠延长超时时间解决。测试记录应保留网络类型、活动节点、内核类型、失败阶段和本次改动，不记录凭据。
- 基础网络：关闭接管后能否直连，节点域名能否解析。
- 本地入口：实际监听地址、端口与进程是否一致。
- 完整请求：显式代理请求是否响应，浏览器是否与其结果一致。
- 远端证据：服务是否监听，日志能否对应到测试时间。