面向已经导入订阅、但面对一长串节点不知道从哪条开始试的用户。全文按地区、协议类型、倍率、延迟四个维度给出取舍顺序，附 v2rayN 与 v2rayNG 中对应的测试入口、延迟上下波动时的判断标准，以及一套可以直接照做的日常挑选流程。
先定顺序：地区 → 协议类型 → 倍率 → 延迟
节点列表里的字段很多，真正影响使用体验的只有四类：节点所在地区、协议与传输组合、流量倍率，以及由前两者和本地线路共同决定的延迟。把这四项放在同一个层级上反复比较，只会一直纠结。
更有效的做法是先排除、再排序。地区决定往返时间的物理下限，协议组合决定这条线路在拥堵时是否容易被干扰，倍率决定你为这些流量付出的成本，延迟只是前三项落在你当前网络环境里的结果。
四个维度上可以直接用的参考数值如下，后文逐项展开。
地区：决定延迟下限，也决定线路质量
物理距离绕不过去。数据包从本地出口到对端机房再返回，光在光纤里的往返时间已经决定了延迟的地板值，协议层面的优化只能在这个基础上做加法。
下表是按常见机房位置整理的经验区间。实际数值会随本地宽带出口、运营商国际线路和晚高峰拥堵状态浮动，同一地区的不同线路之间，差异可能比跨地区差异还大。
| 机房位置 | 往返延迟参考区间 | 适合场景 | 需要注意 |
|---|---|---|---|
| 香港 | 30–60 ms | 网页浏览、视频、日常主力 | 晚高峰拥堵明显，同城不同机房差异大 |
| 日本 / 韩国 | 60–120 ms | 长连接、稳定性优先 | 直连线路与绕行线路差别明显 |
| 新加坡 | 80–150 ms | 东南亚服务、备用线路 | 部分运营商回程绕行 |
| 美国西部 | 150–250 ms | 大带宽下载、非实时任务 | 交互操作有可感知的顿挫 |
地区的作用是缩小范围，而不是直接决定最终选择。先按物理距离把候选分成就近、次近、远端三组，每组内部再比较具体线路，比较效率会高很多。
结论：先用地区把候选压到 5 条以内
在 v2rayN 里可以用「订阅」→「订阅分组设置」建立地区分组，把不常用的节点移出主列表，每组只留延迟最低的两三条。候选超过 10 条时，人眼比较的结果基本等于随机。
协议类型：先看传输层，再看安全层
客户端列表里的节点名通常包含三段信息：协议、传输方式、安全层，例如 VLESS + TCP + Reality，或者 VMess + WebSocket + TLS。协议决定身份验证与加密方式，传输方式决定数据包在网络里长什么样。
普通用户不需要理解每种组合的实现细节，只需要判断三件事：这条线路是否需要自备域名、是否依赖 TLS 证书、以及在你常用的客户端里能不能正常加载。
VLESS + TCP + Reality
推荐不需要自备域名与证书，握手阶段借用真实站点的 TLS 特征，端口通常直接用 443。新部署的节点优先考虑这种组合。
适合：新节点、对握手特征有要求的线路
VMess + WebSocket + TLS
出现时间早、兼容面最广，可以套在 CDN 后面转发。字段较多，任何一个字段填错都会表现为连接建立成功但无法上网。
适合：老订阅、需要 CDN 中转的场景
VLESS + TCP + TLS
结构最直接，额外开销最小，在本地线路本身干净的情况下延迟表现最好，但依赖一个可用的域名与有效证书。
适合：线路质量好、有独立域名的自建节点
三种组合在正常网络下的速度差距通常小于 10%，真正拉开差距的是线路在晚高峰或跨网时的稳定性。协议类型适合用来排除明显不合适的组合，不适合用来精挑细选。
判断一条节点属于哪种组合，看订阅里的分享链接参数最快：
security：安全层，取值none/tls/reality，决定握手方式。type：传输方式，取值tcp/ws/grpc/http。flow：流控方式，xtls-rprx-vision只在 VLESS + TCP + Reality 或 VLESS + TCP + TLS 下有效。sni：握手时使用的目标域名，Reality 与 TLS 都依赖它。path与host：WebSocket、HTTP 传输专用，缺失时会出现连上但无法转发流量的情况。
倍率：把流量成本算清楚再排序
倍率是服务端对流量的计费系数。1.0× 表示实际传输 1 GB 就在套餐里扣 1 GB，2.0× 表示同样传输 1 GB 要扣掉 2 GB。倍率与速度没有必然关系，高倍率线路不一定更快。
把倍率乘进日常用量，判断会直观很多。假设每月上下行合计 60 GB：
- 1.0× 线路：消耗 60 GB 套餐流量。
- 1.5× 线路：消耗 90 GB 套餐流量。
- 2.0× 线路：消耗 120 GB 套餐流量。
- 3.0× 线路：消耗 180 GB 套餐流量。
结论是把倍率 2.0× 以上的节点当作应急备用，日常主力留在 1.0× 与 1.5× 之间。看视频、下载大文件这类高流量任务优先选低倍率；网页浏览、即时通信这类小流量任务，倍率之间的差异几乎可以忽略。
注意
倍率由服务端下发，客户端只负责显示。订阅里的节点名如果没有标注倍率，以服务商的套餐说明为准，不要根据节点名里的数字猜测。
延迟：测什么、测几次、波动多少算异常
客户端里能测的延迟有两种。一种是 TCP 握手延迟，只验证到节点服务器的端口是否可达；另一种是真连接延迟，会在节点上实际发起一次请求并把结果返回。前者数值更小，后者更接近真实体验，挑选节点时以后者为准。
在 v2rayN 里，选中节点后右键选择「测试真连接延迟」，主界面会按结果重新排列；在 v2rayNG 里，点右上角 ⋮ 选择「测试全部配置延迟」，列表右侧会逐条回填数值。跨境线路上默认的超时时间可能偏短，可以在「设置」→「参数设置」→「基础设置」里调大后复测。
单次结果不要直接采信。同一个节点连续测三次，取中位数，再和相邻节点比较。判断标准可以按下面四条执行。
- 三次结果都在 80 ms 以内：可以设为日常主力。
- 三次结果波动超过 30%，或中间出现一次超时：说明线路抖动，降级为备用。
- 真连接延迟明显高于 TCP 延迟，例如高出一倍以上：节点服务器负载偏高或回程绕行，换同地区的其他节点。
- 所有节点同时变慢：问题通常不在节点，先关闭代理确认本地网络本身是否正常，再回来复测。
还有一种情况值得单独记录：某个节点白天稳定、晚高峰必然抖动。这属于线路拥塞而不是节点故障，把它留在备用分组里，比直接删除更有价值。
结论：延迟用来排序，不用来淘汰
一条 120 ms 但三次结果都稳定的线路，实际体验通常好于 60 ms 但每次都不一样的线路。后者在视频通话和长时间下载里会不断重连，反而更浪费时间。
落地：两端共用一份挑选结果
桌面端与安卓端使用同一条订阅链接时，节点列表、分组与排序保持一致，挑选只需要做一次。两端的差别主要在测试入口和日常使用方式上。
推荐方案：一条订阅，两端同一份候选
桌面端（v2rayN）
- 「订阅」→「订阅分组设置」按地区拆组
- 右键「测试真连接延迟」，三次取中位数
- 本地监听端口 10808（SOCKS）与 10809（HTTP）
安卓端（v2rayNG）
- ⋮ →「测试全部配置延迟」批量回填数值
- 「设置」→「分应用代理」决定哪些应用走代理
- 把 v2rayNG 加入系统省电白名单，避免后台被清理
两端节点列表始终来自同一份订阅，换设备不需要重新挑节点，只需要重新测一次延迟。
把这套顺序固化成习惯：新订阅导入后先按地区拆组，排除倍率 2.0× 以上的节点，剩下的每条测三次真连接延迟，按中位数排序，取前三条作为常用节点。之后每次更新订阅时复测一次即可。
需要说明的是，节点质量会随时间变化，一次挑选的结果不是长期结论。同一个机房在不同时间段的表现可能完全不同，定期复测比一次性精挑更有意义。