从握手往返次数、加密层开销、移动端耗电三个维度横比 VMess、VLESS、Trojan、Shadowsocks,再给出可套用的选型顺序。适合已经在 v2rayNG 或 v2rayN 里导入订阅、需要在同一服务器的多个协议端口之间做取舍的用户;读完能判断当前网络下该优先保留哪种协议的节点。
握手路径:四种协议各多出几趟往返
协议之间的差距,一半来自握手,一半来自加密层。握手决定「连上要几趟往返」,加密层决定「每传一个包要多花多少 CPU 和多少字节」。VMess 与 VLESS 出自同一套 Project V 体系:VMess 自带认证与加密层,VLESS 把加密完全交给外层 TLS 或 REALITY,自身只保留一个极简请求头。
Trojan 走的是伪装路线,认证信息放在 TLS 建立之后的第一段数据里,握手成本约等于一次普通 HTTPS 握手。Shadowsocks 是另一种思路:不套 TLS,直接用 AEAD 对整条流加密,客户端连上就能发数据。
把四种协议放进同一张表,差异集中在往返次数与头部字节两列。
| 协议 | 握手组成 | 额外往返 | 头部开销(量级) |
|---|---|---|---|
| VMess(AEAD,alterId=0) | TCP + VMess 认证头 | 0 | 约 40–50 字节 |
| VLESS | TCP + 极简请求头 | 0 | 约 20–40 字节 |
| Trojan | TCP + TLS 握手 + 密码校验 | 1(TLS 1.3)/ 2(TLS 1.2) | 约 60 字节 |
| Shadowsocks(AEAD) | TCP + AEAD 加密载荷 | 0 | 约 30 字节 |
表里的额外往返按裸 TCP 场景计算,头部开销不含 TLS 记录层,实际字节数会随地址类型(域名、IPv4、IPv6)浮动。一旦把 VMess 或 VLESS 套进 WebSocket + TLS,就要再加一到两趟 TLS 往返——这也是同一条线路上,裸 TCP 的 VLESS 往往比 WebSocket + TLS 的 VMess 先出首字节的原因。
握手开销如何折算成首字节延迟
一次请求的总延迟,大致等于链路 RTT 乘以往返次数,再加上服务端处理时间。跨境线路单程 80 ms 时,一趟往返就是 160 ms 左右;TLS 1.2 的握手比 TLS 1.3 多一趟,首字节就多出一个往返,在上面的线路上约 160 ms。
打开一个页面通常不是一次连接,而是十几次。浏览器的连接复用能省掉一部分,但每个新域名、每次订阅更新、每个独立 App 的请求,都可能重新走一遍握手。协议之间的差距,就在这些「重新握手」的次数上被放大。
VLESS TCP 1 趟 → 请求头随首包发出,总往返 1
VMess TCP 1 趟 → 认证头随首包发出,总往返 1
Trojan TCP 1 趟 → TLS 1.3 握手 1 趟,总往返 2
Shadowsocks TCP 1 趟 → AEAD 载荷直发,总往返 1把这张阶梯套回四种协议:VLESS 与 Shadowsocks 只付 TCP 那一趟;VMess AEAD 同样只多一个认证头,不额外占往返;Trojan 与套了 TLS 的 VMess、VLESS 则要多付一到两趟。选协议时先数往返趟数,再谈其他参数。
结论:先看 TLS 版本,再看协议名
同一台服务器上,VLESS 裸 TCP 与 Trojan 的首字节差距,主要来自 TLS 1.2 与 1.3 的选择;把服务端升到 TLS 1.3 并开启会话复用,收益比换协议更大。
移动端耗电:加密方式与连接次数
安卓端的耗电大头不在协议名,而在两件事:加密算法有没有硬件加速、单位时间内的连接次数。ARMv8 之后的手机 SoC 普遍带 AES 指令集,VMess 与 Shadowsocks 选 aes-128-gcm 时 CPU 占用低;只有较老的 ARMv7 设备上,chacha20-ietf-poly1305 的纯软件实现才更快。
连接次数与 Mux 多路复用相关。v2rayNG 的节点编辑页里有「启用 Mux」开关,开启后多条请求复用同一条连接,握手次数随之下降,适合消息类 App 这种高频小请求;跑大文件下载时反而建议关掉,避免单条连接成为瓶颈。
不同链路质量下,这套本地参数的取舍并不一样。
推荐方案:按链路质量分两套本地参数
移动网络(4G / 5G)
- 优先 VLESS + REALITY 或 Trojan + TLS 节点
- VMess 与 Shadowsocks 节点把加密方式设为 aes-128-gcm
- 开启 Mux,压低握手次数
固定宽带(Wi-Fi / 有线)
- VLESS 裸 TCP 与 Shadowsocks AEAD 都能跑满带宽
- 大流量下载时关闭 Mux
- 需要 UDP 的场景确认服务端已放开 UDP 转发
协议由服务端决定,客户端能调的是加密方式、Mux 与路由模式这三项。
按场景选协议:四种组合的适用面
协议要配上传输方式,才是订阅里真正能用的节点形态。下面四种组合覆盖了绝大多数订阅中出现的节点类型。
VLESS + REALITY
推荐握手等于一次 TLS 1.3,不需要自签证书,抗主动探测表现最好;Xray 内核原生支持,流控填 xtls-rprx-vision。
适合:日常主力、跨境高延迟线路
Trojan + TLS
流量形态与普通 HTTPS 一致,节点参数只有地址、端口、密码三项;前提是服务端持有可用证书。
适合:已有域名与证书的自建节点
VMess + WebSocket + TLS
兼容性最好,可以套 CDN 中转;代价是多一层 WebSocket 与 TLS,握手往返次数最多。
适合:老节点、需要 CDN 中转的线路
Shadowsocks AEAD
握手最轻、CPU 占用最低,连接建立几乎只有 TCP 那一趟;没有 TLS 外壳,流量特征更明显。
适合:内网跳板、链路稳定的专线
四种组合没有绝对优劣:VLESS + REALITY 把握手压到最低且不需要自签证书;Trojan 的配置项最少;VMess + WebSocket 在需要 CDN 中转时几乎是唯一选择;Shadowsocks 在链路本身干净时开销最小。
结论:先排除链路问题,再谈协议
握手次数固定后,同一台服务器上四种协议的吞吐差距主要来自加密开销,量级在 10% 以内;而换一条丢包率更低的线路,首字节延迟的改善往往超过 40%。
客户端核对:协议字段对照表
协议选型落到客户端,就是几个字段的核对。v2rayNG 里长按节点进入「编辑」,能看到别名、地址、端口、用户 ID、alterId、加密方式、流控、传输方式与伪装域名;v2rayN 里是「服务器」菜单选中节点后点「编辑」,字段与安卓端一一对应。
不同协议用到的字段并不相同,下面这张对照表可以当检查清单用。
| 字段 | VMess | VLESS | Trojan | Shadowsocks |
|---|---|---|---|---|
| 用户 ID / 密码 | UUID | UUID | 密码 | 密码 |
| alterId | AEAD 模式下填 0 | 不适用 | 不适用 | 不适用 |
| 加密方式 | auto / aes-128-gcm | 固定 none | 不适用 | aes-128-gcm / chacha20-ietf-poly1305 |
| 流控 flow | 不适用 | xtls-rprx-vision | 不适用 | 不适用 |
| 传输方式 | tcp / ws / grpc | tcp / ws / grpc | tcp | tcp |
把 VLESS 节点的「加密方式」改成 aes-128-gcm。VLESS 协议规定该字段必须是 none,填其他值会在握手阶段被服务端直接拒绝;需要更强加密时,应该在外层选择 TLS 或 REALITY。
端口方面,v2rayN 默认在本地开 10808(SOCKS)与 10809(HTTP),v2rayNG 的本地 SOCKS 端口同样是 10808。这两个端口只服务本机应用,和节点服务端的 443、8443 是两回事,排查时别混淆。
改完参数回到节点列表,先做一次真连接延迟测试,再打开页面确认代理生效;如果测速正常但页面打不开,优先检查路由模式与分应用代理有没有把目标 App 排除在外。
常见疑问
同一节点换协议后速度差很多,是协议的问题吗?
先核对两件事:服务端 TLS 是 1.2 还是 1.3、节点有没有套 WebSocket。协议自身的头部只有几十字节,不足以造成成倍差距;差距通常来自这两项,以及服务端到出口的那段线路。
安卓手机上哪种协议更省电?
关键在加密方式而不是协议名。VMess 与 Shadowsocks 选 aes-128-gcm,ARMv8 设备有 AES 硬件加速,CPU 占用低;再开启 Mux 减少握手次数。同一机型上换协议带来的耗电差异,通常小于屏幕亮度的影响。
Shadowsocks 没有 TLS,还能用吗?
看链路环境。内网跳板或稳定专线上,Shadowsocks 的握手最轻、延迟最低;公网直连时没有 TLS 外壳,流量特征更明显,被限速的概率更高,这种场景优先换 VLESS 或 Trojan。
订阅里同一服务器给出多个协议端口,留哪个?
先用真连接延迟测试把每个端口都测一遍,保留首字节最快的一个做主用。同一服务器的不同协议端口走的是同一台机器,差距通常来自握手方式,优先留 TLS 1.3 的 VLESS 或 Trojan 端口,其余不用删,方便随时切换。