TCPing 检查到服务器端口的 TCP 握手，真连接延迟检查经节点发出的实际请求，下载测速观察持续传输能力。选日常浏览节点时先看真连接是否成功及结果是否稳定；传输大文件时再比较下载速度。本文给出 v2rayN 与 v2rayNG 的操作顺序，以及低延迟却无法打开网页时的排查方法。
三种数字分别测到哪里
延迟是一次操作从发起到得到结果所用的时间，不等于线路的固定属性。测试入口、目标地址、连接是否复用，都会改变结果。把不同客户端界面的毫秒数直接排序，可能是在比较不同的操作。
TCPing
向节点服务器的地址和端口建立 TCP 连接，主要反映这一段链路的握手耗时。握手成功不代表代理协议认证成功，也不代表目标网站可访问。
适合:批量排除端口不通或握手明显缓慢的节点
真连接延迟
推荐由客户端通过节点向测试地址发起请求。它覆盖代理建立连接及目标请求等更多环节，但仍受测试地址和超时设置影响。
适合:挑选日常浏览使用的节点，先确认请求能够完成
下载测速
持续获取测试文件，观察一段时间内收到的数据量。结果还受文件服务器、设备性能和同时进行的传输影响。
适合:比较大文件下载和持续传输场景
TCPing 并非所有传输方式的通用延迟。如果节点入口使用的不是 TCP，就不能用到某个 TCP 端口的握手时间代替该节点的实际连接时间。真连接测试也只代表当前测试地址的一次请求：目标站点的 DNS、路由和响应速度变化后，毫秒数可能随之变化。
结论:先确认测量对象，再比较数值
只在同一客户端、同一测试地址和相近时间内比较真连接延迟。将 TCPing 用作可达性初筛，不用它证明网页一定能打开。
为什么 TCPing 很低，网页却打不开
例如 TCPing 显示 40 ms，只能说明当时到服务器端口的 TCP 握手较快。节点的 VMess 或 VLESS 参数仍可能与服务端不一致；代理建立后，目标域名解析、路由分流或目标服务器也可能失败。网页打不开时，应先区分“测试地址请求失败”和“只有某个网站失败”。
上面是一组用于说明量纲的示例记录，不是任何节点的性能承诺。40 ms 与 240 ms 不矛盾：前者止于服务器端口握手，后者还涉及客户端、代理链路和测试目标。5.8 MB/s 是传输速率，不能换算成网页的首字节等待时间；10808 则是本地监听端口，根本不是测速结果。
- 先看真连接测试是否成功。失败时打开客户端日志，区分连接超时、认证错误与目标请求错误。
- 确认当前活动节点就是刚测过的节点，并检查系统代理或应用内代理是否已指向当前客户端。
- 确认路由规则是否让目标域名走代理。同一域名在直连与代理路径下，故障位置不同。
- 若仅个别网站失败，检查该域名的解析结果和目标站点状态，不要仅凭一次 TCPing 更换整条订阅。
在 v2rayN 与 v2rayNG 中怎样比较节点
先更新订阅并固定测试条件。测试期间尽量保持同一网络，暂停占用带宽的大文件传输；同一组候选节点使用相同的测试地址和超时设置。不同版本的菜单文字可能略有差异，应以当前客户端界面标注为准。
推荐方案:先筛可用，再测持续传输
桌面端 v2rayN
- 在服务器列表中选择同一组节点，先运行 TCPing，排除端口不可达的结果。
- 再使用列表的「测试服务器真连接延迟」功能，记录成功次数和毫秒数。
- 将候选节点逐个设为活动节点，用实际网页请求复核。
安卓端 v2rayNG
- 在配置列表中对候选节点使用连接测试或真连接测试，留意失败提示。
- 启用选定配置后，确认系统中的 VPN 连接处于活动状态。
- 用同一网络访问常用页面，再对传输需求较高的节点做下载测试。
两端分别记录结果；不要把桌面有线网络的毫秒数与安卓移动网络的毫秒数直接排名。
v2rayN 的真连接测试名称通常直接出现在服务器列表操作中。v2rayNG 的测试入口和批量测试名称会随版本调整；找不到相同文字时，检查配置列表菜单中的连接测试项。两种客户端都需要留意测试地址：如果测试目标响应慢，所有节点可能一起变慢。
建议每个候选节点间隔测试三次，记录是否成功以及大致范围。例如 A 节点连续得到 180、195、188 ms，B 节点得到 90 ms、超时、310 ms。只看 B 的最小值会遗漏一次失败和较大的波动；日常浏览通常应优先选请求稳定完成的节点。
结论:稳定完成请求优先于单次最低毫秒数
先排除真连接反复超时的节点，再从稳定候选中比较延迟。只有持续下载是主要任务时，才用下载测速决定最后的排序。
下载测速如何读，何时需要重测
下载速度与延迟回答的是两个问题。真连接延迟接近时，一条线路可能在长时间传输中更快；下载速度接近时，另一条线路也可能在打开小页面时响应更快。下载测试至少要确认文件足够大、下载持续了一段时间，不能拿刚启动时的瞬时峰值判断整条线路。
| 观察结果 | 优先核对 | 下一步 |
|---|---|---|
| TCPing 低，真连接超时 | 协议参数、节点日志、测试地址 | 先修复请求失败，再谈排序 |
| 真连接稳定，下载慢 | 测试文件来源、并发下载、线路拥塞 | 换同一测试文件，在不同时段复测 |
| 下载快，网页仍慢 | 目标站点响应、域名解析、路由规则 | 分别测试常用网站，不用吞吐量代替响应时间 |
测试地址本身也会影响结论。若下载文件所在服务器限速，测到的是“节点与该文件服务器组合”的速度，而不是节点能达到的上限。同理，路由规则若将测试地址设为直连，下载数字就无法代表经代理的传输。测试前应确认流量确实经过当前活动节点。
- 重测时固定网络类型、测试目标和文件大小；记录测试发生的时段。
- 将 MB/s 与 Mbps 分开记录。按十进制单位粗略换算，1 MB/s 约等于 8 Mbps。
- 不要在一个节点测速尚未结束时切换到下一个节点；旧连接可能继续占用带宽。
常见结果怎么处理
节点列表出现多个低毫秒数时，先看哪些节点实际完成了请求，再用自己的常用网站复核。单次结果只是一段时间的快照；网络切换、服务端负载和目标站点变化，都可能让第二次测试得出不同排序。
TCPing 是 30 ms，真连接却超时？
先检查当前节点的地址、端口和协议参数，再查看客户端日志。TCP 端口可连接只能排除一部分网络故障，不能确认 VMess 或 VLESS 的代理请求已经成功。
真连接有结果，为什么浏览器仍打不开网页？
确认浏览器实际使用了系统代理或正确的手动代理端口。随后检查目标域名的路由规则；测试地址成功，不代表所有域名都走相同路径。
v2rayN 和 v2rayNG 测出的延迟差很多？
先确认两端使用同一节点、同一测试地址和同一种网络。再检查两端的内核配置与路由设置；条件不一致时，不宜按毫秒数直接比较设备。
下载测速第一秒很快，随后下降？
记录完整传输过程的平均速度，换一个时段用同一文件复测。起始峰值可能受到缓存或短时可用带宽影响，不应单独用于选节点。
应该只选延迟最低的节点吗？
日常浏览先排除请求失败和明显波动的节点，再比较稳定候选的真连接延迟。大文件传输则补做下载测速，并以实际使用时段的结果为准。
最终选择需要与用途对应：打开网页看请求能否稳定完成，持续传输看一段时间内的速度，排查入口故障才优先看 TCPing。保留测试时间、网络类型和失败提示，比只保存一个最低毫秒数更有助于下次定位问题。