代理协议的讨论里，经常把“加密强不强”“像不像正常网页”“速度快不快”和“客户端支不支持”混成一个问题。实际上，这些是不同层面的事：有的协议负责认证和封装数据，有的传输方式决定数据如何到达服务器，还有的 TLS 或混淆层负责提供外观。节点名称里的 VLESS + REALITY、Trojan + TLS 或 Hysteria 2，因此并不能简单地按一个“协议名”横向比较。
本文对比七种常见选择：Shadowsocks（SS）、VLESS、Trojan、AnyTLS、Snell、TUIC 和 Hysteria 2（Hy2）。重点放在协议设计和实际部署取舍，不把不同网络中的跑分当成协议的固定属性。文中的“抗干扰”也只表示某些设计有助于降低识别或阻断特征，不代表任何协议都能保证可用。
先把四个层次分开
一条代理连接通常可以拆成四层来看：
- 代理协议：客户端如何认证、指定目标地址、转发 TCP 或 UDP 数据。
- 承载传输：代理数据跑在 TCP 还是 UDP/QUIC 上，连接是否复用。
- 加密与认证：由协议自带加密，还是交给 TLS，或两者组合。
- 流量外观：外部观察者能看到怎样的握手和数据包形状，服务器如何回应探测请求。
这几层的边界并非每个协议都相同。例如，Shadowsocks 自己加密代理数据；Trojan 把认证数据放进 TLS 连接；VLESS 本身是轻量的代理协议，常见部署再叠加 TLS 或 REALITY。REALITY 是 TLS 外观与验证机制，XTLS Vision 是配合数据传输的流控模式；它们都不是 VLESS 的加密算法。Project X 的传输配置表把这些安全层分别列出，也指出协议自身的加密与 TLS/REALITY 提供的 HTTPS 外观不是一回事。
一眼看懂七种协议
| 协议 | 常见承载 | 加密与认证 | 主要特点 | 主要代价 |
|---|---|---|---|---|
| Shadowsocks | TCP、UDP | 预共享密钥 + AEAD | 轻量、成熟、客户端覆盖广 | 加密流量不等于 HTTPS 外观；特征和密钥管理取决于具体版本 |
| VLESS | TCP、WebSocket、gRPC、XHTTP 等，视核心实现而定 | 通常搭配 TLS 或 REALITY；协议自身偏轻量 | 配置组合多、路由和生态灵活 | 组件多，容易把协议、传输和安全层混为一谈 |
| Trojan | 常见为 TCP + TLS；UDP 能力依实现 | TLS 负责加密，口令负责代理认证 | 可与真实 HTTPS 服务共用入口，部署直观 | TLS 证书、域名和服务端回落配置要正确 |
| AnyTLS | TLS/TCP | TLS + 密码认证 | 在 TLS 会话上复用多条代理流，并可对开头数据包填充 | 新一些，兼容性不及 SS/VLESS；会话复用和填充增加复杂度 |
| Snell | TCP；部分版本可转发 UDP | 预共享密钥；版本相关的流量整形/混淆 | Surge 生态集成好，配置简单，v6 有自动整形 | 由 Surge 团队维护，客户端与服务端版本支持受生态限制 |
| TUIC | UDP + QUIC | QUIC/TLS + 认证 | 多路复用、低延迟建连、UDP 转发和连接迁移 | 依赖 UDP；版本之间不保证兼容 |
| Hysteria 2 | UDP + QUIC | QUIC/TLS + 认证 | 面向高吞吐，支持拥塞控制配置、UDP 转发和 HTTP/3 伪装 | UDP 被限就难以使用；激进提速配置可能影响稳定性或公平性 |
表格里的“常见承载”不等于每个客户端都支持所有组合。实际可用能力要以客户端、服务端版本和具体配置为准。
逐个看协议
Shadowsocks：简单、成熟的加密代理
Shadowsocks 最容易理解：客户端与服务端预先共享密钥，客户端把目标地址和数据加密后发给服务端。它支持 TCP 和 UDP，长期以来被大量桌面、手机和路由器客户端支持。部署和导入节点相对简单，作为通用加密转发协议仍然很实用。
今天看 SS 时要区分旧式加密配置、常见 AEAD 版本和 Shadowsocks 2022（SS2022）。官方文档建议使用 AEAD；SS2022 进一步要求直接提供定长预共享密钥、改进重放保护和 UDP 会话处理。SS2022 规范也明确说明它不提供前向保密。Shadowsocks AEAD 文档；SIP022 SS2022 规范
SS 的关键局限是：它提供的是加密代理流量，不会因为“加密了”就自动看起来像普通 HTTPS。外部仍可能依据流量特征判断这不是浏览器 TLS。若部署目标需要 TLS 外观、域名证书和网页式探测响应，通常要在 SS 外另加传输或混淆层，并接受额外配置与兼容性成本。
适合：优先考虑客户端兼容、部署简洁、一般加密转发和 UDP 代理的场景。选择新部署时，应确认客户端与服务端都支持预期的 AEAD/SS2022 方案，并妥善生成和保管密钥。
VLESS：轻量协议，能力来自组合
VLESS 是 Xray 生态的轻量、无状态代理协议，协议头主要承载用户标识、目标地址和命令，本身不负责提供传统意义上的数据加密。VLESS 协议说明因此应把完整配置拆开看：VLESS 负责代理请求，TCP/WS/gRPC/XHTTP 等负责承载，TLS 或 REALITY 提供传输安全与握手外观，Vision 等模式负责特定的流量处理。
常见的 VLESS + TLS 依赖有效证书和 TLS 配置；VLESS + REALITY 则使用 REALITY 的握手和验证设计。REALITY 只修改 TLS 层，可与 Xray 支持的特定传输组合使用，并不意味着“VLESS 协议本身不可识别”。Xray 文档还明确区分了 VLESS、TLS、REALITY 和可选的 VLESS Encryption。REALITY 配置文档
VLESS 最大的优势是灵活和生态丰富，可以在一个核心里完成多协议、路由、分流和入站组合。相应的代价是配置项多、版本差异明显，排错时必须逐层确认。仅看到“VLESS”三个字，无法推断节点究竟使用了哪种传输、安全层或 UDP 封装。
适合：使用 Xray/sing-box 等通用核心、需要灵活组合传输与安全层、希望做复杂路由或统一管理多类入口的用户。想减少配置选择时，可先采用客户端和服务端都明确定义、文档完整的一套组合。
Trojan：把代理认证放进 TLS 连接
Trojan 的典型流程是先建立真正的 TLS 连接，再在 TLS 里面发送口令摘要、目标地址和代理数据。Trojan 服务端可以把认证失败或探测请求转交给本地网站，因此同一个 TLS 入口可以兼顾代理和网站服务。Trojan 官方协议说明
这里的“像 HTTPS”依赖部署是否完整：证书有效、域名和 TLS 行为合理，失败请求也有合适的回落站点。只在任意端口跑 TLS 并不能自动变成真实网站。与 SS 相比，Trojan 的明显特征是 TLS；与 VLESS + REALITY 相比，它通常使用常规 TLS 证书和回落站点，配置心智模型更直观，但需要维护域名、证书和网站入口。
Trojan 的核心协议主要定义基于 TLS 的代理请求。UDP 转发、复用或其他高级行为，要看具体核心的扩展和兼容情况，不能只根据“Trojan”名称推定。
适合：已有域名和证书、希望代理入口同时提供正常 HTTPS 网站行为、需要成熟 TLS 代理方案的用户。
AnyTLS：TLS 里的多路代理流与握手填充
AnyTLS 建立在 TLS 上，在单个会话中承载多条独立代理流，并定义连接认证、流创建、数据传送和填充方案。填充方案可以改变连接初期若干次写入的数据长度和分包形态；sing-box 文档也把 TLS、用户和 padding_scheme 列为服务端配置项。AnyTLS 协议实现文档；sing-box AnyTLS 配置
多路复用可以减少频繁建立 TLS 连接的开销，但一个 TLS 会话的网络问题也可能同时影响其承载的多条流。填充能调整可观察到的包形状，却会增加带宽开销；它不是对抗所有识别或阻断的保证。AnyTLS 相比 SS 和 Trojan 属于较新的选择，客户端和服务端要确认支持兼容的协议版本。
一个值得了解的隐私细节是客户端元数据。AnyTLS 规范曾要求在设置帧中发送客户端软件名称和版本。sing-box 文档对这一设计提出隐私批评，并记录 sing-box 1.13.16 与 1.14.0-beta.5 起默认不发送元数据的变更；其他实现的行为需要单独核实。sing-box 关于 AnyTLS 客户端元数据的说明
适合：客户端、服务端均支持，且希望在 TLS 连接内复用多条代理流、使用可调连接初期填充的场景。选择时应同时检查协议版本和客户端元数据行为。
Snell：Surge 生态里的轻量加密协议
Snell 由 Surge 团队设计，采用预共享密钥，按版本演进。Surge 当前文档列出 v1 到 v6；UDP 转发从 v3 开始支持，v4 及之后版本可以配置连接复用，v5 对 QUIC 转发有特定处理。v6 则根据密钥派生部署专属的流量整形配置，默认模式同时加密并整形流量；截至文档所示，v6 仍处于 beta 阶段。Surge Snell 文档
Snell 的长处是 Surge 用户容易使用，配置项少，客户端和服务端版本一起更新时管理直接。它的局限来自生态集中：虽然其他客户端可能逐步增加支持，覆盖面和跨客户端的一致性通常不如 Shadowsocks、VLESS。不要把它当作通用标准协议，也不要遗漏版本号；Surge 文档特别建议显式写出版本。
适合：主要使用 Surge，或已确认客户端、服务端都支持目标 Snell 版本的用户。若希望跨多种客户端迁移，先核实各端对版本和 UDP 的支持。
TUIC：基于 QUIC 的低延迟、多路复用代理
TUIC 把代理请求放在加密 QUIC 连接上，目标是通过 QUIC 提供多路复用、连接迁移、拥塞控制和 TCP/UDP 转发。TUIC v5 规范还关注 UDP 转发的 0-RTT 建立，以及可选择有损数据报或可靠流承载的 UDP 转发。TUIC 协议仓库与规范入口
QUIC 用 UDP 承载连接，因此在丢包或移动网络切换时，多路复用和连接迁移可能带来体验优势；TCP 上的单连接丢包阻塞与 QUIC 的多流行为也不同。但这不是“QUIC 一定更快”：服务器拥塞控制、客户端实现、路径 MTU、网络是否限速 UDP，以及链路丢包都会影响结果。QUIC 依赖 UDP，UDP 被网络封锁时，通常不能靠换端口把它变成 TCP。
TUIC 仓库将协议规范与具体实现分开维护，并注明不同版本不保证兼容。部署时要确认客户端和服务端说的是同一版协议（常见为 v5），以及认证、TLS 证书和 UDP 端口都配置一致。
适合：UDP 可用，希望降低建连等待、并发多流或转发实时 UDP 应用的场景。网络对 UDP 不稳定时，应准备 TCP 入口作为备选。
Hysteria 2：以高吞吐为目标的 QUIC 代理
Hysteria 2 运行在 QUIC/UDP 上，用 HTTP/3 请求完成认证，并支持 TCP 和 UDP 代理。规范定义了客户端接收速率信息、服务端拥塞控制等机制；实现提供 BBR、Reno 或 Brutal 等配置选项，具体选择和默认值应以对应版本文档为准。Hysteria 2 协议规范；客户端配置说明
Hysteria 2 的设计目标侧重高吞吐，面对高延迟或有损链路时，合理设置拥塞控制和带宽参数可能有帮助。代价是如果把可用带宽估得过高，激进发送会造成拥塞、竞争或体验波动；即便是高速链路，也不保证 Hy2 总比 TCP 代理快。
协议默认使用 HTTP/3 外观，并可配置实际网页内容或反向代理作为伪装响应。可选 Salamander 会对 QUIC 数据包做混淆；新版文档还列出 Gecko，用分片和填充改变握手数据报的外观。这些机制只能改变流量特征，不能绕过 UDP 被整体封锁的事实，也不应误解为普通 HTTP/3 网站流量的完全复制。伪装与服务端配置；Salamander 与 Gecko 规范
适合：UDP 可用、长距离或高丢包网络中更关注吞吐量的用户。对于对延迟抖动敏感的游戏、实时语音，或者网络会封锁 QUIC/UDP 的环境，建议与实际使用的线路一起测试，而不要只看协议名称。
怎么按场景选
- 最看重客户端普及和部署简单：先看 Shadowsocks；确认服务端和客户端都支持同一套现代 AEAD 方案。
- 需要丰富组合与复杂路由：看 VLESS，并把协议、安全层、传输方式分别记录和维护。
- 有域名证书，希望入口能正常提供网站内容：看 Trojan + TLS，并认真配置认证失败时的站点回落。
- 已经在用 Surge：Snell 是顺手的选择；先对齐 Snell 版本和跨端需求。
- QUIC/UDP 可用，优先并发、建连延迟或 UDP 转发：比较 TUIC 与 Hysteria 2。两者的实际效果受实现和网络影响，应在目标线路上测。
- 希望使用 TLS 会话复用与连接初期填充：可以评估 AnyTLS，重点核对双方版本和客户端元数据策略。
- UDP 常被封锁或限速：优先保留一条 TCP 方案。TUIC 和 Hysteria 2 无法消除它们对 UDP 的依赖。
比协议名更重要的检查项
测试节点时，把同一台服务器、同一条线路和同一个客户端核心作为控制条件，再更换协议配置。分别观察连接成功率、首包延迟、下载和上传速度、长连接稳定性、UDP 应用可用性，以及网络切换后的恢复情况。速度测试应多次进行，并记录本地接入、时段和服务器负载；单次峰值不足以说明长期体验。
服务端还要检查证书是否有效、时间是否正确、系统是否允许 UDP、端口映射与防火墙是否一致，以及客户端和服务端协议版本是否匹配。REALITY、TLS、HTTP/3 伪装或数据包填充各自解决的问题不同，任何单一名称都不构成安全或可用保证。
最后，代理协议只决定连接如何加密、认证和转发。选择合法合规的用途，遵守所在地区法律、单位网络政策和服务商条款；不要把协议伪装能力误认为匿名性、终端安全或绝对隐私。