v2rayN 测速结果怎么读，节点又该怎么挑

打开 v2rayN 的节点列表，右键菜单里有三个很容易被混为一谈的入口：测试服务器延迟、测试真连接延迟、测试服务器速度。它们测的对象完全不同，得到的数字也不该放在一列里排序。不少人只看第一个数字挑最小的用，结果视频照样卡——因为那个数字根本不描述带宽，它描述的是握手快慢。

更容易被忽略的是时间因素。任何一次测试都是某一秒的快照，而节点负载在一天里可以差出好几倍。白天空载时表现漂亮的节点，晚上八点半可能只剩零头。所以"挑节点"不是一个动作，是一个至少跨两个时段的筛选流程。

下面就按这个流程展开：先用延迟把不可用的剔掉，再对幸存者做带宽测试缩小范围，最后在晚高峰复测一轮，结合流量倍率定下长期使用的那三四个。

测试延迟和测试真连接延迟，各自测的是什么#

这两项经常被当成同一件事，实际差着一整条链路。测试服务器延迟只探到节点的入口地址，握手一完成就出结果；测试真连接延迟则要通过这个节点完整走一遍代理，访问一个外部目标再返回。

结论很直接：判断"能不能用"看真连接延迟，判断"快不快"看测速，判断"稳不稳"这两个都看不出来。入口延迟这一列的主要价值是排序参考，不适合单独当作选节点依据。

显示 -1 或 timeout，一定是节点坏了吗#

不一定，而且本机原因占的比例不低。同一批节点里只有零星几个超时，多半确实是那几台服务器的问题；如果整片飘红，先怀疑本机。

常见的几类成因：内核进程没起来或被安全软件拦下；测试并发数设得太高，节点侧把探测包当异常流量丢弃；本地网络对 UDP 做了限速，导致基于 QUIC 的节点集体不通；订阅刚更新过，旧节点已经被机场下线但列表还没刷新。

如果超时的是整份列表而不是个别节点，不要在这一页反复重测。判据和分层定位方法见节点全部超时的三步判据，先分清是全体失效还是只有你这台机器失效，能省掉大量无效尝试。

单个节点偶尔超时也别急着删。重测两三次，若三次里有一次能出数字，说明链路是通的，只是丢包严重，这类节点可以留作备用但不适合当主力。

多线程测速的数字为什么常常虚高#

v2rayN 的测速会同时开多条连接抓取数据，这个策略能把可用带宽尽快填满，代价是数字容易偏乐观。原因有三层。

一是突发窗口。很多线路对前几秒的流量不做限制，限速策略在持续传输一段时间后才开始生效，短测速刚好只覆盖了不受限的那一段。二是并发绕过单连接限速。有些节点限制的是每条连接的速率，多开几条自然把总数堆上去了，但真实使用中一个视频流往往只占一到两条连接。三是缓存与就近回源，测试源站如果有边缘节点，测出来的更接近"你到边缘节点"的速度，而不是完整跨境链路的速度。

所以测速值适合用来做横向比较——同样的测法测同一批节点，谁高谁低是有意义的；但把它当成"我以后能跑这么快"的承诺就不合适了。

延迟低就一定看视频不卡吗#

不是。延迟低只说明单个数据包往返快，视频是否流畅取决于带宽是否够、抖动是否小、丢包是否稳定在低位。一个平均延迟 90 毫秒但抖动在 30 到 400 毫秒之间来回跳的节点，体验会比稳定在 180 毫秒的节点差很多。

想看抖动和丢包，v2rayN 本身不提供，得用命令行持续观察。下面是结构示例，example.invalid 请换成你实际节点的入口地址：

# 结构示例：连续发 100 个包，观察丢包率与延迟波动区间
ping -n 100 example.invalid

结果里要看三样：丢包百分比、最短与最长往返时间的差值、以及有没有成片的连续超时。差值越小越平稳；出现连续几个超时，说明链路有周期性中断，这类节点用来跑网页尚可，跑视频会话或者长连接任务就会频繁掉线。

倍率高的节点值不值得当日常主力#

先看倍率把套餐吃掉多少。倍率是机场对不同线路成本的折算方式，标 2x 的节点每传输 1 GB 就从套餐里扣 2 GB。下面是纯算术换算，不涉及任何具体品牌：

高倍率节点通常对应专线或优质中转，速度确实更好。合理的用法是分工：日常网页、聊天、代码托管走 1x 或更低的普通节点；只有对延迟和稳定性敏感的场景——视频会议、流媒体、需要长时间保持连接的工具——才切到高倍率节点。把 5x 的专线当默认出口挂一整天，套餐会消失得比预期快得多。倍率标记通常直接写在节点名里，怎么读这些标签可以参考节点名里的地区与倍率标记相关说明。

晚高峰复测怎么做才有参考价值#

关键是控制变量，否则两次数字没法比。

1. 固定时段。白天基线选在工作日上午或下午，晚高峰选在工作日 20:00 到 23:00 之间。周末的负载曲线和工作日不同，两者不要混着比。
2. 固定测法。两次都用同一个测试入口、同样的并发设置，中途不要改动路由规则或切换接管方式。
3. 固定候选集。只测白天筛出的那几个节点，不要临时加入新节点，否则你无法判断差异来自时段还是来自节点本身。
4. 连续记三天。单晚的数据可能撞上临时故障，连续三个工作日都衰减明显，才算稳定结论。
5. 算衰减比例而不是看绝对值。用晚高峰速度除以白天速度，得到一个百分比。同一份表格里，衰减比例最小的那个节点才是真正适合当主力的。

衰减多少算不能接受没有统一标准，取决于你的用途。纯网页浏览对带宽不敏感，掉一半也无感；视频和会议类场景，一旦掉到白天的三成以下就会开始有明显体验损失。以上为按常见使用场景给出的参考口径，不同网络环境下结果会有差异。

一次固定几个常用节点比较合理#

三到四个，按用途分工，不要更多。

节点太少没有退路，某个节点被封或者临时故障时你会措手不及；节点太多则会陷入无休止的比较，每次卡顿都想换一个试试，最后时间全花在切换上。一个可用的分配是：一个低倍率节点承担日常浏览和下载，一个延迟稳定的节点承担会议与长连接任务，一个不同地区的节点作为备用，另外可选一个专门用于特定平台的节点。

选定之后把它们的位置记住，日常只在这几个之间切换。真正需要重新筛选的时机只有三个：订阅更新后节点列表发生大幅变动、常用节点连续几天表现变差、或者你的使用场景发生了变化。其余时候重复测速的收益很低。

小结#

测试服务器延迟测的是握手，真连接延迟测的是整条链路能否走通，测速测的是那一刻的带宽，三者互不替代，也都不能预测晚高峰表现。多线程测速受突发窗口和并发策略影响，天然偏乐观，适合横向比较而不适合当承诺。延迟低不等于不卡，抖动和丢包要靠持续 ping 单独观察。倍率决定同样的流量能撑多久，高倍率节点适合按场景调用而不是全天挂着。最后固定三到四个分工明确的常用节点，比反复重测更省时间也更省流量。