代理协议对比

代理协议应按完整部署组合比较：本地怎样接管流量，远端怎样表达目标与认证，TCP/UDP如何承载，以及安全层验证谁。不能把某个协议名称直接换算成“速度高”“永远无法识别”这样的固定等级。

HTTP CONNECT、SOCKS5是通用代理接口；Shadowsocks、VMess、Trojan、VLESS和Hysteria又有各自的认证、报文与承载设计。TUN是本地IP设备接口，TLS是传输安全机制，WebSocket是消息承载，REALITY和Vision也承担不同职责。

先用五个维度缩小范围

本地入口和远端出口可以组合，例如TUN接管后使用一个远端TCP代理协议；这不会让该远端协议自动获得原生UDP能力。也可以由SOCKS入口接入QUIC远端承载，SOCKS仅是本地接口。

核心机制对照

表格描述能力结构，不保证每个客户端和每种组合都实现全部功能。协议扩展、Mux以及UDP封装需按两端版本核实，不能把某实现的可选模块当作协议强制部分。

Shadowsocks：AEAD 保护与线格式版本

旧AEAD TCP流先发送salt，再用会话子密钥保护长度块和内容块；长度也有独立认证标签。每个chunk有两次AEAD操作，nonce按规范演进。UDP则按独立数据报构造，不是复用一条TCP流的分块状态。Shadowsocks AEAD

以AES-128-GCM旧AEAD格式为例，salt16 B、长度2 B及其tag16 B、内容N B及其tag16 B。发送1000 B协议payload作为一个chunk，首次该方向共16+2+16+1000+16=1050 B；拆成两个chunk则1084 B。这里payload可能还包含目的地址等协议数据，不等于1000 B纯应用内容，也未计TCP/IP头。

def old_aead_tcp_size(payload_sizes, salt=16, tag=16):
    assert all(0 < size <= 0x3fff for size in payload_sizes)
    return salt + sum(2 + tag + size + tag for size in payload_sizes)

assert old_aead_tcp_size([1000]) == 1050
assert old_aead_tcp_size([500, 500]) == 1084
assert old_aead_tcp_size([500, 500]) - old_aead_tcp_size([1000]) == 34
print('一个 / 两个 chunk:', old_aead_tcp_size([1000]), old_aead_tcp_size([500, 500]))

AEAD-2022更新了密钥要求、会话、重放处理和报文结构等，不能只替换cipher名称后继续套旧salt与chunk图。配置迁移要同时核对两端协议代际、密钥格式及UDP支持。SIP022

认证加密保证规定条件下的保密与完整性，不承诺密文长度、分包或连接行为与普通HTTPS一致。某种部署被识别，也不能推导为AEAD密码学已经失效。

同样1000字节，拆成小块会多出多少？

把chunk从1改成2，内容总量不变，只多付一次34 B开销；增加到20块后，认证和定界成本占比明显上升。这里解释一个明确线格式的预算，不将字节更少直接等同于真实速度更快。

$$L=16+N+34k$$

VMess：代理报文与外层传输分开

VMess用自己的认证请求头和数据格式表达目标、选项与身份，AEAD头部格式是需要区分的协议版本。时间相关验证意味着时钟条件会影响握手；不能把它简化为“TCP里放一些随机加密字节”。V2Fly VMess规范

在WebSocket或其他传输上承载VMess，会增加一层连接建立、帧或代理行为。CDN是否可用取决于它实际支持的HTTP承载和转发配置，不能因一条TCP流套了TLS就认为任意CDN都能中转。

复用多个逻辑会话可能减少建立连接次数，也可能让它们共享一个外层TCP的队头阻塞。选择是否复用应看短连接数量、交互时延和丢包条件，而不是默认Mux永远更快。

Trojan：TLS 外观与应用认证不是同一保证

Trojan在TLS连接内发送代理认证及请求信息，其协议包含TCP CONNECT和UDP ASSOCIATE类命令。TLS用于保护通道并验证服务端，代理凭据用于决定是否允许中继，两者缺一不能互相补偿。

UDP数据在该协议中有目标、长度和内容等记录格式，经TLS流承载。它保留数据报边界，但外层可靠流发生缺口时，后续数据仍会等恢复；适合TCP的可靠性特征不一定适合实时UDP应用。Trojan协议

正常TLS握手和回落站点有助改变观察到的行为，但握手参数、流量大小、时序和部署响应仍可能不同。有效公共证书只能证明相应服务身份，不能保证“与普通网页访问无法区分”。

VLESS、Vision 和 REALITY 分别负责什么

VLESS保留用户ID及代理请求语义，并没有移除UUID类身份字段。传统encryption: none组合依赖外层TLS/REALITY等提供保护；截至2026年9月，Project X文档还定义VLESS Encryption选项，因此不能把“VLESS永远没有协议加密”写成不变事实。

Vision是特定流处理模式，关系到内层TLS识别、填充与适用路径优化，不是新TLS套件，也不能与XUDP、Mux画等号。模式选择还可能改变UDP443处理策略，应核对具体flow而非只看“VLESS”标签。Project X VLESS配置

REALITY采用专用认证和握手处理，并为未通过认证的连接设计回落行为。服务器有自己的配置密钥，客户端持有对应验证材料；这不是取得第三方网站私钥，也不是靠“备案获取某网站真正证书”来完成合法代理客户端的认证。REALITY项目

当前Xray客户端代码包含基于AuthKey等材料的专用证书验证路径，同时区分正常证书验证与是否达到预期REALITY认证状态。读取其中一个InsecureSkipVerify标志就断言“完全不验身份”同样错误，因为它配置了自定义验证。Xray REALITY客户端实现

复制一张公开证书无法让任意服务器证明持有该证书私钥；回落转发与专用客户端认证是两条路径。机制可以减少某些观察差异，但不能从项目目标直接推出所有主动探测都无效，或对所有观察者都有不可区分保证。

Hysteria 2：QUIC 多流与可选外层混淆

Hysteria 2使用QUIC/TLS并通过HTTP/3认证交换建立代理使用资格。通过认证后，TCP连接各使用相应双向流，UDP能力由服务器表明并按协议封装。它并不是把所有代理内容当作普通网页HTTP响应传输。

QUIC允许流间分别恢复，但连接拥塞控制仍共享。Hysteria的拥塞与带宽配置影响发送策略，填更大的带宽值不会增加真实链路容量；瓶颈排队甚至可能损害小交互延迟。Hysteria 2协议

Salamander是可选外层混淆，加入salt并处理QUIC包字节；它不消除包长、方向和时序，也不保证所有检测都失效。当前文档还列出其他混淆选项，不能把一个选项写成协议唯一永久形式。QUIC包含TLS握手，Initial保护材料可由公开信息派生，所以“QUIC没有TLS指纹”本身就不成立。

UDP受到限制的网络中，QUIC类承载可能不可用或不稳定；可用时也应测量首包、尾延迟、吞吐和CPU，而非仅以“基于UDP”判断性能。客户端设置需与服务端和所用版本匹配。Hysteria客户端配置

怎样做有意义的比较

比较应固定服务端位置、路径、负载和客户端版本，记录配置组合；一次失败可能来自DNS、证书、UDP路径或版本不匹配。协议安全目标、实现正确性、部署可达性和识别风险应分别给出证据。

继续查阅

• 正向代理：CONNECT、SOCKS5与DNS位置。
• 透明代理与TUN：本地接管及出站绕行。
• TLS 1.3：认证、密钥与握手可见性。
• UDP与QUIC：可靠流、DATAGRAM及拥塞边界。