排查目标：把“无法连接”定位到本机监听、流量入口、节点配置、时间与握手、远端网络中的一层。本文以 Windows 上的 v2rayN 为主要操作环境，补充 Android 上 v2rayNG 与 v2flyNG 的检查差异；每次只改变一个条件，用同一个请求复测，避免更换节点、路由和 DNS 后无法判断究竟是哪项生效。
第一步：确认本机代理端口正在监听
本机入口：客户端窗口打开不等于代理内核已经启动。v2rayN 负责配置与管理，实际连接由所选内核处理；如果内核配置加载失败、端口被占用，浏览器即使填写了代理地址，也无法把请求送入节点。先查看客户端日志中的启动结果，再确认监听端口。
端口核对：进入 v2rayN「设置」→「参数设置」，查看本地监听地址、端口与对应的入站类型；界面分组名称可能随版本调整。下面以 127.0.0.1:10808 的 SOCKS 入站为例，10808 不是所有安装环境的固定值，也不是服务端端口，执行前应替换成实际监听值。
netstat -ano | findstr ":10808"- 没有输出：检查实际端口是否不同，内核是否退出，以及日志是否出现配置解析或启动失败。不要先修改浏览器设置来补救不存在的监听。
- 存在 LISTENING：读取该行末尾的 PID，在「任务管理器」→「详细信息」确认进程归属。端口可能被其他程序占用，不能只凭数字相同判断正常。
- 监听地址不同：
127.0.0.1是 IPv4 回环地址；仅有[::1]的监听不代表 IPv4 回环连接必然可用，测试地址应与监听一致。
报错：bind: address already in use
原因：准备使用的本地地址与端口已被占用，常见于重复启动或其他代理进程仍在运行。
解法：根据 PID 确认占用者，关闭重复实例或更改本地监听端口，重启内核后同步更新应用代理设置。
安卓差异：v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核；先确认应用已启动连接并获得系统 VPN 授权。Android 的 VPN 接管与 Windows 系统代理不是同一种入口，不应直接套用 Windows 的端口检查结论。
第二步：分离系统代理、应用代理与 TUN
流量路径：系统代理只影响遵循该设置的应用，TUN 则通过虚拟网卡接管流量。浏览器能打开网页而其他程序失败，不一定是节点故障；反过来，客户端延迟测试成功也不代表浏览器已经使用代理。
隔离测试：先记录原来的系统代理和 TUN 状态，暂时关闭 TUN，用明确指定 SOCKS 代理的命令发起请求。这样可以绕开“应用是否遵循系统代理”的不确定性，但仍会受客户端内部路由规则影响。若需要验证代理出站，应同时查看日志中的实际出站选择。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raymark.com/参数含义：socks5h 将目标域名交给代理端处理，不能据此判断本机 DNS 一定正常；10 秒是连接阶段上限，20 秒是整个请求上限，两者只是本次诊断设置，不是网络性能标准。即使返回 403 或 405，也说明收到了 HTTP 响应，不应继续把它归类为连接超时。
-
记录入口
记录 v2rayN 的监听端口、选中节点、系统代理状态与 TUN 状态，保留失败时的原始条件。
-
显式测试
关闭 TUN 后执行上面的命令；若连接本机即被拒绝，回到第一步检查端口及 SOCKS 入站类型。
-
恢复系统代理
显式测试成功后，在 v2rayN「系统代理」中选择「自动配置系统代理」，再查看 Windows「设置」→「网络和 Internet」→「代理」是否与客户端状态一致。
-
单独验证 TUN
确需 TUN 时再启用，按客户端提示确认权限和网卡状态。如果仅 TUN 失败，重点检查路由、DNS 与其他 VPN 的冲突，不要立即改节点参数。
判断：显式代理成功，先查应用入口
显式代理请求成功、浏览器仍失败时，先检查浏览器扩展、应用独立代理与系统代理地址；此时更换服务端不能解决本机入口未生效的问题。
第三步：核对订阅配置与实际使用的节点
配置来源：订阅更新成功只说明获取并解析了配置，不保证每条节点都有效；更新失败也不意味着现有节点立即失效。先确认当前选中节点属于哪个订阅分组，是否仍是更新前的旧条目，再核对服务提供方是否变更过地址、端口或认证信息。
内核边界：v2rayN 应核对当前实际调用的内核及其日志；Android 上不能把 v2rayNG 与 v2flyNG 当成仅名称不同的同一程序。Xray 与 v2fly 的协议扩展和字段支持并不完全相同，配置能被界面导入，不代表内核一定能完整运行。涉及 VLESS、REALITY 等配置时尤其要确认实际支持情况。
| 检查项 | 核对内容 | 常见误判 |
|---|---|---|
| 服务器地址与端口 | 核对节点地址与服务端监听端口；443 只是常见配置示例 | 把本地 10808 填成远端端口 |
| 协议与认证 | VMess、VLESS 类型及对应的用户标识等字段 | 只看节点名称相同，忽略认证已更新 |
| 传输参数 | 核对 TCP、WebSocket 或 gRPC 等实际传输方式及所需字段 | 传输不一致仍只调整 DNS |
| TLS 参数 | 核对 TLS 是否启用、服务器名称与证书要求 | 认为 TCP 端口可达就代表握手正确 |
| 路由出站 | 确认测试请求选中了预期代理，而非直连或阻断 | 把目标网站直连失败算作节点超时 |
更新操作：在 v2rayN「订阅分组」中针对对应分组执行更新，更新后重新选择节点并检查日志。如果当前版本提供通过代理更新与不通过代理更新两种入口，按订阅地址的实际可达性选择；唯一节点已失效时，继续依赖它下载订阅可能形成循环失败。订阅链接与完整节点配置都属于敏感信息，排查截图应隐藏认证字段。
第四步：同步系统时间并辨认 TLS 握手失败
时间影响：系统时钟明显偏差可能使证书被判断为尚未生效或已经过期，也可能影响 VMess 的时间相关认证。VLESS 不能照搬 VMess 的时间校验解释，但启用 TLS 时仍然受到证书有效期检查影响。仅修改时区显示不等于修正系统实际时间。
- Windows：进入「设置」→「时间和语言」→「日期和时间」，启用「自动设置时间」，点击「立即同步」，并确认同步结果。
- Android：在系统设置中搜索「日期和时间」，启用自动设置时间；具体入口由设备系统决定。
- 同步之后：重新启动一次测试请求，并查看同一时刻的内核日志。如果仍有证书错误，继续核对证书有效期与服务器名称。
报错：x509: certificate has expired or is not yet valid
原因：证书有效期与当前系统时间不匹配，可能是本机时间错误，也可能是服务端证书确实需要更新。
解法：先同步本机时间；时间正确仍报错时，由服务端维护者检查证书及其部署状态。
报错：x509: certificate signed by unknown authority
原因：证书链无法连接到受信任的根，可能涉及缺失的中间证书、私有证书或本机信任库。
解法：核对服务端证书链与预期签发机构；私有证书应通过可信渠道配置信任，不以跳过验证代替修复。
SNI 核对：连接地址与 TLS 服务器名称可以不同，但必须符合服务端部署与证书要求，不能随意填写一个能访问的域名。不要把 allowInsecure 当作超时修复开关；跳过证书验证既不能解决 TCP 不通，也不能修正错误的传输路径，还会削弱身份验证。
第五步：检查服务端可达性与远端监听
远端探测：前四步确认本机入口、流量接管和配置后，再测节点地址的目标端口。下面是 Windows PowerShell 命令，运行时输入实际节点地址及端口，不要输入完整订阅链接。该测试仅检查 TCP 连接，不能验证账号、TLS、WebSocket 路径或 gRPC 服务名。
$nodeHost = Read-Host "输入节点服务器地址"
$nodePort = [int](Read-Host "输入节点服务器端口")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed- TcpTestSucceeded 为 True：当次测试所使用的地址与端口可以建立 TCP 连接。下一步查 TLS、认证、传输参数及服务端日志，不应据此宣布节点完全正常。
- TcpTestSucceeded 为 False：可能涉及地址解析、服务未监听、防火墙、安全组或链路丢包。需要结合解析出的远端地址和错误信息判断，不足以单独证明服务已停止。
- Ping 失败但 TCP 成功：目标可能不响应 ICMP。不要用 Ping 失败替代代理端口测试，也不要把 Ping 成功当成代理服务正常。
- 涉及 UDP：TCP 探测不能说明 UDP 可用性，网页请求成功也不能证明所有依赖 UDP 的应用均可正常工作。
报错：i/o timeout
原因：某次网络读写在期限内没有完成；必须结合相邻日志判断发生在连接节点、TLS 握手还是访问目标服务阶段。
解法：保留同一请求前后的日志，对照远端地址与发生阶段，再分别检查端口、握手或目标服务，不能仅凭这一行更换 DNS。
网络对照：保持节点、目标地址和测试命令不变，只把本机网络切换为手机热点后复测。如果结果不同，应优先检查原网络的出口限制、DNS 返回结果与地址族差异；这仍不是对某种限制原因的最终证明。域名同时具有 IPv4 与 IPv6 地址时，记录实际使用的地址，不要只比较域名文字。
服务端协作：有管理权限时检查进程是否运行、预期端口是否监听、防火墙与安全组是否放行，以及证书和反向代理配置是否一致。没有权限时，向维护者提供失败时间及其时区、协议和传输类型、脱敏日志、端口测试结果；不要公开用户标识、订阅链接或其他认证材料。
判断：端口可达后，转向握手与配置
当 TCP 探测成功而代理请求持续失败时，把下一轮排查限定在 TLS、协议认证、传输参数和实际出站日志；反复增加等待时间通常只会延后同一个错误。
复测收尾：用同一请求确认修复范围
复测标准：完成一项修改后，重新执行第二步的显式代理请求，再验证实际使用的浏览器或应用。显式代理成功只覆盖这条请求路径，不能替代系统代理、TUN、DNS 与其他应用的分别验证。客户端显示的延迟测试结果也有自己的测试目标和方法，不能当成全部应用可用性的结论。
- 记录变化：留下修改项、测试时间、选中节点和对应日志，避免下一次故障从零开始。
- 恢复设置：按实际需要恢复 TUN 和系统代理，撤销临时调整，不保留关闭证书验证之类的绕行设置。
- 缩小范围：若只有一个网站失败，检查该目标的路由与返回状态；若只有一个应用失败，检查它的独立代理和流量类型。
- 保留证据：修复前后的结果应使用同一目标、同一入口和相同超时参数，不把一次成功描述为长期稳定。
后续配置：需要了解系统代理、TUN 与分流规则的关系，可查阅高级用法；首次配置尚未完成时，优先按教程建立一条可重复验证的连接，再逐步增加路由与 DNS 设置。