订阅里常见的节点类型五花八门:ss、vmess、trojan、hysteria2……很多人直接用服务商给的默认配置,其实并不清楚这些协议之间到底差在哪。这篇文章从「速度」「抗封锁」「配置复杂度」三个维度做个横向对比,帮你理解取舍。

先看一张总览表

协议传输层抗封锁典型场景
ShadowsocksTCP/UDP一般,特征较易识别轻量、上手快,老牌协议
VMessTCP + WS/gRPC较好(配合 CDN 伪装)需要伪装成正常 HTTPS 流量时
VLESSTCP + WS/gRPC/XTLS好,性能优于 VMess对性能与抗探测都有要求
TrojanTLS好,流量特征接近正常 HTTPS追求简单可靠的伪装能力
Hysteria2QUIC (UDP)强,对弱网环境优化好高延迟/丢包网络下追求速度
TUICQUIC (UDP)强,启动速度快移动网络、频繁切换环境

Shadowsocks:简单可靠的老牌协议

Shadowsocks(简称 SS)几乎是最早普及的加密代理协议之一,配置简单,只需要 serverportcipherpassword 四个核心字段。缺点是流量特征相对固定,在特征识别较严格的网络环境下容易被针对性限速或阻断。

- name: "SS-示例" type: ss server: example.com port: 8388 cipher: aes-128-gcm password: "password"

VMess / VLESS:搭配 CDN 的伪装能力

VMess 与其后继者 VLESS 通常搭配 WebSocket 或 gRPC 传输层,再套一层 TLS,让流量看起来像是普通的 HTTPS 网页请求,甚至可以套 CDN 中转。VLESS 相比 VMess 去掉了部分加密开销,配合 XTLS 时性能更好。

- name: "VLESS-示例" type: vless server: example.com port: 443 uuid: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" network: ws tls: true

Trojan:伪装成「正常网站」

Trojan 的设计思路很直接:整个连接看起来就是一次标准的 HTTPS 请求,服务器甚至可以在被探测时直接返回一个正常网站的内容作为「掩护」。配置字段也比较精简,是追求简单与伪装能力平衡的常见选择。

Hysteria2 / TUIC:基于 QUIC 的新一代协议

这两者都构建在 QUIC(基于 UDP)之上,天然具备更好的拥塞控制与连接迁移能力,在高延迟、弱网或频繁切换网络(比如移动网络在 WiFi 和 4G/5G 之间切换)的场景下,体验通常优于传统 TCP 类协议。

- name: "Hysteria2-示例" type: hysteria2 server: example.com port: 443 password: "password" up: "50 Mbps" down: "200 Mbps"
QUIC 类协议依赖 UDP,如果所在网络对 UDP 限速或屏蔽较严格,实际体验可能不如预期,这种情况下可以换回 TCP 类协议对比测试。

连接复用对实际体验的影响

除了协议本身,传输层的连接复用方式也会显著影响体感速度。像 VMess/VLESS 搭配的 gRPC 传输可以在一条物理连接上复用多个逻辑流,减少反复建连的开销,在弱网或高延迟链路上尤其明显;而每次请求都单独建立新连接的方案,在网页里同时加载大量小资源(图片、脚本)时容易出现明显的卡顿感。如果你发现同一个节点在浏览网页和下载大文件时体验差异很大,往往和传输层的复用策略有关,而不是单纯的带宽问题。

为什么同一协议不同服务商体验差异很大

很多人纠结「到底哪个协议最快」,但实际测试中会发现同样是 Trojan 协议,不同服务商的节点速度可能差好几倍。这是因为影响最终体验的变量远不止协议类型:服务器本身的带宽出口质量、与你所在地区的物理距离、中转链路是否经过优化,甚至同一时段服务器上的并发用户数,都会叠加影响最终结果。协议只决定了「传输层怎么包装数据」,真正决定速度上限的还是底层网络基础设施。

怎么测试节点的真实速度

光看策略组里的延迟数字(ms)并不能完全反映真实体验,因为那通常只是一次 TCP/HTTP 探测的往返时间,反映的是延迟而非带宽。更全面的测试思路是:先看 url-test 的延迟排序做初筛,再对候选的两三个节点分别下载一个体量适中的测试文件,观察实际下载速率曲线是否稳定,而不是只看瞬时峰值。如果某个节点延迟很低但下载速率不稳定(时快时慢),大概率是服务器端并发压力较大或者出口带宽有限。

不同协议对丢包和抖动的敏感程度也不一样:基于 UDP/QUIC 的协议(Hysteria2、TUIC)通常更能容忍一定程度的丢包,而传统 TCP 类协议一旦出现丢包,重传机制会让延迟感知被进一步放大。

实战建议:怎么选

  • 只是想稳定能用:服务商给什么协议就用什么,Clash 客户端会自动识别并处理,不需要纠结。
  • 网络环境审查严格:优先选择 Trojan、VLESS 这类流量特征接近正常 HTTPS 的协议。
  • 网络质量差(高延迟/高丢包):优先尝试 Hysteria2 或 TUIC,QUIC 的抗丢包能力通常更好。
  • 多协议节点都有:可以放进同一个 url-test 策略组,让客户端自动挑选当前网络下延迟最低的一个。

协议会不会「过时」

会有更新迭代,但不必焦虑「旧协议随时失效」。Shadowsocks 用了这么多年依然活跃,说明简单可靠的方案自有其生命力;新协议(如 Hysteria2、TUIC)更多是在特定场景(弱网、抗封锁要求更高)下提供了更好的选择,而不是彻底淘汰旧协议。实际使用中更值得关注的是节点提供方是否持续维护更新,而不是协议本身新旧——一个长期没人维护的新协议节点,体验可能还不如维护良好的老协议节点。

小结

协议没有绝对的「最好」,只有「当前网络环境下最合适」。如果订阅里同时提供了多种协议的节点,不妨都保留下来放进自动测速的策略组,让 Clash 根据实际网络状况自动选择,比死磕一种协议更省心。