v2rayN 延迟显示负1怎么办？按测试方式逐层排查
简答：v2rayN 显示 -1，通常表示本次测试没有得到有效结果，不等于节点必然失效。先关闭 TUN，仅保留系统代理，选一个节点测试“TCP 延迟”和“真连接延迟”；如果 TCP 有数值、真连接仍为 -1，再检查测速地址、内核、时间和防火墙。本文以 Windows 版为例，其他平台菜单可能不同。
定义：v2rayN 延迟显示 -1，是测试流程未返回有效延迟值的占位结果，可能来自 TCP 端口不可达、真连接请求超时、测试地址不可用、TUN 路径冲突、核心配置失败或协议与测试方式不匹配。
先看这张判断表：-1 到底是哪一层失败
本站是第三方使用指南站，不是 v2rayN 官方站。v2rayN 官方仓库说明它支持 Windows、Linux 和 macOS，并可使用 Xray、sing-box 等核心；本文只按 Windows 界面举例，菜单名称以当前版本显示为准。
| 现象 | 优先判断 | 先做什么 |
|---|---|---|
| TCP 延迟有数值，真连接延迟为 -1 | 节点端口能建立 TCP 连接，但经代理访问测试地址失败 | 检查真连接测速地址、核心日志、系统代理与 TUN |
| TCP 延迟和真连接延迟都为 -1 | 节点地址、端口、域名解析、核心配置或本地网络可能失败 | 换同订阅中的另一个节点，再看日志 |
| 关闭 TUN 后恢复，开启 TUN 后为 -1 | 测速临时进程与 TUN 路由或保护规则存在冲突 | 暂时关闭 TUN 完成测速，单独排查 TUN |
| 只有 Hysteria2、TUIC 或 QUIC 传输节点为 -1 | 使用了不适合该协议的 TCP 测试方式 | 改用 UDP 或真连接测试，不要只看 TCP 延迟 |
| 所有节点同时变为 -1 | 本地网络、测速地址、核心版本或防火墙问题的可能性更高 | 先只测一个节点，再切换核心或关闭 TUN 复测 |
v2rayN 当前源码把 TCPing、真连接、UDP 测试和下载测速分成不同路径；TCPing直接使用节点地址和端口，真连接则通过本地 SOCKS 代理访问配置中的测试 URL。因此，两种结果不一致并不矛盾，可先按测试类型定位。
可查看 v2rayN 的测速服务源码，其中能看到 TCPing、Realping 和 UDP 测试分别执行。
第1步：关闭 TUN，只测试一个节点
- 停止当前连接：在 v2rayN 主界面断开当前节点。
- 临时关闭 TUN：进入设置中的 TUN 或路由相关页面，关闭 TUN；如果系统代理选项存在，先只启用自动配置系统代理。不同版本的入口名称可能不同，以设置页显示为准。
- 只选择一个节点：不要一开始批量测试全部节点，先选择一个协议和传输方式明确的节点。
- 分别执行测试：先运行 TCP 延迟，再运行真连接延迟。记录节点协议、核心类型、结果和日志时间。
如果关闭 TUN 后真连接延迟恢复，问题未必是节点失效。v2rayN 项目中已有与 TUN、真连接测试返回 -1 相关的公开问题记录；这类记录只能说明存在过该类现象，不能直接证明你的当前版本一定存在相同缺陷。
可参考 v2rayN 关于 TUN 模式下真连接延迟为 -1 的问题记录。若你需要完整接管系统流量，先完成普通系统代理测试，再单独恢复 TUN，避免把两层变量同时改变。
第2步：区分 TCP 延迟、真连接延迟和 UDP 测试
TCP 延迟：主要验证节点地址和端口是否能完成 TCP 连接，适合观察端口可达性，但不能证明代理已经能正常访问网页。
真连接延迟：v2rayN 会为测试节点建立临时配置，并通过本地代理请求测试地址。它更接近“经该节点访问一个 HTTP 地址是否成功”，但会受到 DNS、TLS、测速 URL、核心配置和超时设置影响。
UDP 测试：面向 UDP、QUIC 或特定 UDP 服务。Hysteria2 基于 QUIC，TUIC 也包含 QUIC 和 UDP 相关字段；这类节点用 TCPing 判断，结果可能只代表 TCP 端口测试不适用，不能直接当成节点真实可用性结论。
sing-box 文档明确将 Hysteria2描述为基于 QUIC的协议，TUIC配置中也包含 UDP relay、QUIC字段和 TCP/UDP 网络选项，可查看 Hysteria2 文档 与 TUIC 出站文档。
| 节点类型 | 优先测试 | 不要单独依据 |
|---|---|---|
| TCP、TLS、WS 等 TCP 传输 | TCP 延迟 + 真连接延迟 | 只看 TCP 延迟 |
| VLESS + Reality | 真连接延迟，并结合核心日志 | 把 TCP 延迟当成完整协议验证 |
| Hysteria2 | UDP 测试或真连接测试 | 只用 TCPing 下结论 |
| TUIC | 根据节点网络字段选择 UDP 或真连接测试 | 忽略 QUIC、UDP 与 TLS 参数 |
第3步：检查测速地址和本地代理端口
如果浏览器通过节点可以打开网页，但真连接延迟始终为 -1，优先检查测速地址。v2rayN 的配置中存在 SpeedPingTestUrl 字段，项目源码测试配置也会读取该字段；实际设置入口和默认值可能随版本变化，不能把某个旧版本菜单路径当成所有版本都相同。
- 进入 v2rayN 设置，查找“测试连接用的网址”“真连接测试地址”或相近名称。
- 复制当前地址，在普通浏览器中直接打开，确认不是明显的 DNS、证书或本地网络错误。
- 如果版本没有图形入口，先备份配置目录，再搜索配置文件中的
speedPingTestUrl字段；不要直接删除其他配置项。 - 修改后完全退出并重新打开 v2rayN，只测试一个节点。
不要把任意需要登录、跳转很多次或返回大页面的地址作为测速目标。真连接测试通常需要一个能快速返回 HTTP 响应的地址，但具体地址是否适合你的网络环境仍需自行核验。
v2rayN 项目曾在讨论中说明可在配置文件中修改 speedPingTestUrl，可查看 v2rayN 关于修改真连接测试地址的讨论。源码中的测试超时和测试 URL字段也可在 v2rayN 测试配置文件中核对，但它不等同于当前版本界面说明。
如果你知道本地 SOCKS 端口，可用命令验证本地代理是否真的能转发请求。端口以 v2rayN 设置页显示为准，下面的 10808 只是占位示例：
curl.exe --proxy socks5h://127.0.0.1:10808 -I https://example.com结果判断：能返回 HTTP 状态码，说明本地 SOCKS 入站至少有响应；提示连接被拒绝，说明端口不对或核心未运行；超时则继续检查节点、DNS、TUN 和防火墙。不要把订阅链接、UUID、密码或完整节点分享给他人。
第4步：检查系统时间、核心和节点参数
如果节点使用 VMess，系统时间需要重点检查。Xray 官方文档写明 VMess依赖系统时间，并要求运行 Xray 的系统 UTC时间与实际时间保持在文档规定范围内；V2Fly FAQ则把超过90秒列为常见错误原因。由于不同核心和实现的说明存在差异，本文不把某个秒数当成 v2rayN所有节点的统一阈值。
- 打开 Windows“设置 → 时间和语言 → 日期和时间”。
- 开启自动设置时间和自动设置时区，点击立即同步。
- 完全重启 v2rayN，再测试 VMess 节点。
- 如果是 VLESS、Trojan、Shadowsocks、Hysteria2 或 TUIC，时间仍可作为基础排查项，但不要把 VMess 的时间规则直接套用到其他协议。
可查阅 Xray VMess 官方文档和 V2Fly FAQ。两份资料对时间容忍范围的表述不同，因此更稳妥的做法是校准时间，并结合当前核心日志判断。
接着核对核心：
- 在 v2rayN 的核心设置中确认节点使用的是预期核心，例如 Xray 或 sing-box。
- 对同一个节点切换另一种已安装且兼容的核心，只做单节点复测。
- 查看日志中是否出现配置解析失败、字段不支持、TLS、Reality、证书、DNS 或端口错误。
- 如果问题从升级后开始，先记录 v2rayN版本、核心名称和核心版本，再到 v2rayN Releases核对发布说明；不要直接把某个版本称为“最新版”，以页面实际显示为准。
尤其要注意：v2rayN 的版本与 Xray、sing-box 的版本并不是同一个版本号。某个节点参数在一种核心中可用，不代表在另一种核心中一定兼容。
第5步：排查 Windows 防火墙、安全软件和批量测试
如果单节点在关闭 TUN后仍为 -1，检查 Windows Defender 防火墙或第三方安全软件是否拦截 v2rayN及其核心进程。重点关注 v2rayN主程序、xray.exe、sing-box.exe以及 TUN 驱动或虚拟网卡相关程序。
- 打开“Windows 安全中心 → 防火墙和网络保护 → 允许应用通过防火墙”。
- 确认 v2rayN和实际使用的核心程序在当前网络类型下没有被禁止。
- 如果使用第三方安全软件，临时暂停网络过滤功能进行一次单节点复测；复测后立即恢复防护。
- 不要为了测速长期关闭防火墙，也不要把未知目录下的同名程序直接加入放行列表。
v2rayN 的公开问题中曾记录安全软件、TUN 和 DNS 请求超时可能同时影响测试；这类 Issue 是项目问题线索，不代表每台电脑的原因相同，可结合日志核对。
另外，批量测试不适合作为第一步。v2rayN 项目中有关于 TCPing、真连接批量并发可能造成结果异常或超时的公开讨论。先单节点，再少量节点，最后才批量测试，可以减少本地路由器、NAT 表或安全软件同时处理大量连接的干扰。
可查看 v2rayN 关于批量测试并发的讨论。若单节点有结果、批量测试大量出现 -1，优先降低测试范围并分组复测，不要立即判定全部节点失效。
最小排查清单：按这个顺序做
- 记录 v2rayN版本、操作系统、节点协议、传输方式和核心类型。
- 关闭 TUN，只保留系统代理。
- 只选一个节点，先测 TCP 延迟，再测真连接延迟。
- TCP 有数值、真连接为 -1：检查测速 URL、本地代理端口和核心日志。
- 两种测试都为 -1：换节点，检查域名解析、端口、核心配置和防火墙。
- 仅 UDP/QUIC 节点为 -1：不要只用 TCPing，改用 UDP 或真连接测试。
- VMess 节点异常：同步 Windows 时间；其他协议不要直接套用 VMess 的时间阈值。
- 升级或切换核心后才出现：核对 v2rayN Release、核心版本和节点字段兼容性。
- 单节点确认正常后，再分组批量测试。
如果浏览器经代理访问正常，但 v2rayN 的真连接测试仍为 -1，结论应写成“测速流程未返回有效结果”，而不是直接写成“节点不可用”。反过来，如果本地 SOCKS 请求也失败，再继续排查节点、核心、DNS、端口和防火墙。
常见问题
v2rayN 延迟显示 -1，是不是节点已经失效？
不一定。-1 只能说明这次测试没有返回有效延迟值，可能是节点不可达，也可能是测速地址、DNS、核心配置、TUN 路径或防火墙导致。先关闭 TUN，只测一个节点，并分别执行 TCP 延迟和真连接延迟。
TCP 延迟正常，为什么真连接延迟还是 -1？
TCP 延迟主要验证节点地址和端口能否建立 TCP 连接；真连接延迟还要通过本地代理访问测试 URL，受到 DNS、TLS、核心和测速地址影响。优先检查测速 URL、本地 SOCKS 端口和核心日志。
Hysteria2 或 TUIC 节点可以用 TCPing 测试吗？
可以把 TCPing 当作端口层面的参考，但不能把它当成 UDP/QUIC 协议的完整可用性测试。Hysteria2 基于 QUIC，TUIC包含 UDP relay和QUIC字段，应根据节点配置改用 UDP 或真连接测试。
系统时间一定会导致 v2rayN 延迟 -1 吗？
不能这样绝对判断。VMess 官方资料明确要求客户端和服务端时间接近，时间偏差可能导致握手失败；但其他协议不能直接套用 VMess 的时间规则。校准 Windows 时间是低成本排查项，最终仍要结合核心日志。
开启 TUN 后所有节点都显示 -1，但浏览器能打开网页怎么办？
这可能是测速临时进程没有沿用主进程的 TUN 保护或路由路径。先关闭 TUN、只启用系统代理测试同一节点；如果恢复，再单独检查 TUN、虚拟网卡、DNS和防火墙。浏览器能用不代表 v2rayN 内置测速一定能返回数值。