“科学上网/代理”技术理解成 5 层

你的程序/浏览器
      ↓
本地入口
SOCKS5 / HTTP / TUN
      ↓
代理协议
VLESS / VMess / Trojan / Shadowsocks / TUIC / Hysteria2
      ↓
传输方式
RAW(TCP) / WebSocket / gRPC / XHTTP / QUIC
      ↓
安全与伪装
TLS / REALITY / XTLS Vision / Obfs
      ↓
Internet
      ↓
境外代理服务器
      ↓
Google / YouTube / GitHub / ChatGPT...

Xray 官方现在也明确把 代理协议、传输方式、传输安全 分开定义。例如 VLESS 属于代理协议，RAW/XHTTP/gRPC/WebSocket 属于传输方式，而 TLS/REALITY 属于传输安全。(XTLS)

一、代理到底是怎么工作的

假设你访问：

https://www.google.com

没有代理时：

你的电脑
   ↓
运营商网络
   ↓
Google

使用代理后变成：

你的电脑
   ↓
代理客户端
   ↓
【加密/封装后的连接】
   ↓
代理服务器
   ↓
Google

例如：

Chrome
 ↓
127.0.0.1:1080 SOCKS5
 ↓
VLESS
 ↓
REALITY
 ↓
TCP 443
 ↓
VPS
 ↓
Google

中间网络真正看到的主要是：

你的 IP
   ↕
VPS IP

而不是你和 Google 直接通信。

这里有一个非常重要的概念：

“加密”≠“抗封锁”。

加密主要解决：

你传了什么？

伪装/抗探测解决：

你到底在运行什么协议？

所以即使某个协议内容完全加密，只要它的数据包形态非常独特，DPI 依然可能判断：

“虽然我不知道里面是什么，但我知道这是某种代理协议。”

二、目前常见协议整体对比

下面这个表更接近实际使用时应该如何理解。

这里的星级只能表示一般网络环境下的相对特点，不能理解为“★★★★★ 就永远不会封”。真正影响结果的还有 IP、ASN、端口、流量大小、TLS 指纹、客户端实现、网络运营商以及是否限制 UDP。

三、Shadowsocks：简单、高速的经典方案

Shadowsocks 本质上是：

应用数据
 ↓
Shadowsocks
 ↓
AEAD 加密
 ↓
TCP / UDP
 ↓
服务器

SS 2022 使用预共享密钥以及 AEAD，加密后数据在外观上接近随机字节流，同时增加了完整的重放保护，并重新设计了 UDP 会话机制。(Shadowsocks)

优点

非常轻。

没有复杂 TLS/WebSocket/gRPC 套娃：

SS
 ↓
TCP

CPU 消耗低、吞吐高、客户端支持广。

问题

它的哲学是：

我让你看不懂

而不是：

我让你觉得我是正常 Chrome HTTPS。

因此：

Trojan / Reality / Naive
          ↓
“看起来像普通互联网应用”

Shadowsocks
          ↓
“看起来像一段加密随机数据”

这两种设计思路完全不同。

四、VMess：V2Ray 时代的经典协议

VMess 是 V2Ray 早期最核心的协议之一。

典型架构：

VMess
 +
WebSocket
 +
TLS

例如：

VMess
 ↓
WebSocket
 ↓
TLS
 ↓
443

过去非常常见。

但 Xray 后来发展出了：

VLESS
XTLS
REALITY
XHTTP

所以如果你现在研究 Xray/s-ui，理解 VMess 就可以，但更应该重点理解 VLESS。

一个重要区别是 VLESS 本身是无状态轻量协议，而且不像 VMess 那样依赖系统时间。(XTLS)

五、VLESS：现在 Xray 体系里最值得理解的协议

VLESS 可以理解成：

“尽量什么都不做的代理协议。”

核心目标是：

认证
+
告诉服务器我要访问哪里
+
转发数据

而不是自己承担所有加密工作。

因此经典 VLESS：

VLESS
 ↓
TLS / REALITY
 ↓
TCP

Xray 官方也明确提醒：普通 VLESS 如果没有启用 VLESS Encryption，不应该直接裸跑在不可信网络上，而应配合 TLS/REALITY 等安全层。(XTLS)

六、REALITY 到底是什么

这个尤其重要。

很多人会说：

REALITY 是协议。

其实不准确。

它更接近：

传输安全/伪装层

所以：

VLESS + REALITY

实际上是两个东西。

可以理解成：

VLESS
负责代理

REALITY
负责让外层 TLS 行为更接近正常互联网连接

Xray 官方描述 REALITY 为一种修改后的 TLS，通过借用目标网站的 TLS 外观和握手特征进行伪装，使外部观察到的流量更接近正常 Web 流量。(XTLS)

因此：

VLESS
   ↓
XTLS Vision
   ↓
REALITY
   ↓
RAW/TCP

是目前 Xray 体系非常典型的一种架构。

七、XTLS Vision 又是什么

这个也不是独立代理协议。

可以理解为：

VLESS 数据应该怎么高效地流动。

普通代理：

TLS数据
 ↓
Xray 用户态
 ↓
复制
 ↓
处理
 ↓
复制
 ↓
socket

符合条件时，XTLS Vision 可以利用 Linux splice() 等机制减少数据在用户态中的复制和处理。

也就是说：

VLESS = 身份/代理协议

REALITY = 外层安全和伪装

Vision = 数据转发优化

所以：

VLESS + REALITY + Vision

并不是“三个代理协议叠起来”。

而是三层功能。Xray 文档也说明了 Vision 与 TCP+TLS/REALITY 搭配时可以减少核心 IO 开销。(XTLS)

八、Trojan：直接装成 HTTPS

Trojan 的思想非常容易理解：

既然 HTTPS 是互联网最常见流量
那我为什么不直接像 HTTPS？

所以：

Trojan
 ↓
真正的 TLS
 ↓
TCP 443

客户端首先完成正常 TLS 握手，然后在 TLS 内发送 Trojan 身份认证和代理请求。(Trojan GFW)

如果是正确客户端：

TLS
 ↓
Trojan认证成功
 ↓
代理

如果有人探测：

TLS
 ↓
认证失败
 ↓
正常网站/回落服务

这就是它抗主动探测的设计思想。

相比 Shadowsocks：

SS：
“不让你看懂”

Trojan：
“让你以为我是 HTTPS”

九、NaiveProxy：直接模仿 Chrome

NaiveProxy 的思路更进一步。

不是：

做一个“类似 HTTPS”的协议

而是尽量直接使用：

Chromium 网络栈

因此网络侧看到的 TLS/H2/H3 行为会更接近 Chrome。

架构类似：

应用
 ↓
Naive Client
 ↓
HTTP/2 或 HTTP/3 CONNECT
 ↓
TLS
 ↓
Caddy / 前端
 ↓
Naive Server

NaiveProxy 官方明确说明它利用 Chromium 网络栈来降低 TLS 参数指纹、流量分类和主动探测带来的可识别性，并使用 padding 等方式降低长度特征。(GitHub)

它的设计哲学可以概括成：

不要自己发明一种“像浏览器”的流量

直接尽可能使用浏览器本身的网络行为

所以在流量真实性方面很有特色。

十、Hysteria2：另一条完全不同的路线

前面的：

VLESS
Trojan
Naive

大部分重点是：

TCP / HTTPS

Hysteria2 则主要走：

UDP
 ↓
QUIC
 ↓
Hysteria2

QUIC 本身支持多路复用：

一个 QUIC Connection

├─ TCP连接A
├─ TCP连接B
├─ TCP连接C
└─ UDP数据

不会像传统 TCP 那样所有流都互相严重影响。

Hysteria2 官方协议建立在标准 QUIC 上，并支持 TCP 和 UDP 代理。(Hysteria 2)

它特别适合：

高延迟
高丢包
跨国链路
移动网络
Wi-Fi质量差

它的 Brutal 等拥塞控制思想偏向：

即使存在丢包，也积极尝试利用可用带宽。

所以很多情况下测速非常猛。

十一、Hysteria2 的伪装

HY2 默认会表现得类似 HTTP/3 服务。

没有正确身份认证时，可以像正常 HTTP/3 Web Server 一样处理连接。(Hysteria 2)

另外目前还有：

Salamander
Gecko

两种混淆。

Salamander：

QUIC
 ↓
混淆
 ↓
随机外观 UDP

Gecko 更进一步：

QUIC握手
 ↓
随机拆分
 ↓
随机 Padding
 ↓
UDP

官方文档称 Gecko 会对 QUIC 握手报文进行随机大小的分片和填充。(Hysteria 2)

但 HY2 最大弱点也非常明显：

依赖 UDP

如果网络策略直接：

UDP 443 → 限速
QUIC → 限制
未知 UDP → 丢包

性能甚至连可用性都会明显下降。

sing-box 文档也特别提醒：UDP 型代理虽然可能在某些环境很有效，但从流量类型来看，特征未必比 TCP 方案更不明显。(Sing Box)

十二、TUIC 和 Hysteria2 为什么经常放一起

因为两者都大量使用：

QUIC
UDP
TLS
多路复用

TUIC：

应用
 ↓
TUIC
 ↓
QUIC
 ↓
UDP

TUIC 协议本身设计为运行在可复用的 TLS 加密流之上，并主要为 QUIC 设计。(GitHub)

它还能使用：

CUBIC
New Reno
BBR

等 QUIC 拥塞控制策略。(Sing Box)

可以粗略理解：

TUIC
更像：
“QUIC 高性能代理”

Hysteria2
更像：
“QUIC 高性能代理
 +
弱网优化
 +
HTTP/3伪装
 +
专门的混淆机制”

所以两者性能都很好，但 HY2 的抗审查设计更明显。

十三、WireGuard 为什么速度很快但不是抗封锁第一选择

WireGuard 本质是：

VPN

而不是传统意义的应用代理。

它：

IP Packet
 ↓
WireGuard
 ↓
UDP

把整个 IP 数据包封装进去。

WireGuard 使用 Noise IK 握手、Curve25519、ChaCha20-Poly1305 等密码学机制，并且所有包走 UDP。(WireGuard)

它最大的优势：

代码简单
速度快
延迟低
稳定
系统级 VPN 很方便

但它设计重点是：

安全 VPN

而不是：

伪装成普通 HTTPS

所以在“协议识别”这一层，它和：

REALITY
Naive
Trojan

的设计目标是不一样的。

十四、WebSocket、gRPC、XHTTP 又是什么

这几个最容易和 VLESS 混淆。

例如：

VLESS + WS + TLS

这里：

VLESS
= 代理协议

WS
= 传输

TLS
= 加密

同理：

VLESS + gRPC + TLS

VLESS + XHTTP + REALITY

Trojan + gRPC + TLS

都是组合。

Xray 当前官方支持的主要传输包括：

RAW
XHTTP
mKCP
gRPC
WebSocket
HTTPUpgrade
Hysteria

而传输安全层主要包括 TLS 和 REALITY。(XTLS)

十五、RAW 为什么现在又经常看到

以前很多面板叫：

TCP

现在 Xray 文档里改名叫：

RAW

实际上意思接近：

不再额外套 WebSocket/gRPC/XHTTP，直接把代理协议产生的数据交给底层 TCP/UDP。

例如：

VLESS
 ↓
REALITY
 ↓
RAW
 ↓
TCP

相比：

VLESS
 ↓
WebSocket
 ↓
TLS
 ↓
TCP

少了一层。

所以：

RAW
优点：
低开销
低延迟
配置简单
性能好

Xray 官方也明确说明 RAW 就是直接发送经代理协议包装后的 TCP/UDP 数据，而不使用 XHTTP 等额外传输。(XTLS)

十六、真正应该怎么理解“抗封锁”

不要简单问：

哪个协议最抗封？

应该拆成 5 个问题。

① IP 封锁

例如：

1.2.3.4
直接被封

那么：

VLESS ❌
Reality ❌
Trojan ❌
Hysteria ❌
TUIC ❌
WireGuard ❌

协议再强也救不了这个 IP。

这是：

IP层

的问题。

② 被动 DPI

防火墙只是观察：

包大小
方向
时间
TLS ClientHello
协议结构
UDP/TCP特征

不主动连接服务器。

这个场景通常：

REALITY
Naive
Trojan

这类“正常互联网协议外观”设计更有优势。

③ 主动探测

例如发现：

某 IP:443 很可疑

于是主动连过去：

你好，你是不是代理服务器？

好的设计不会回答：

“是。”

而应该表现成：

普通网站
普通 HTTPS 服务
或者没有有效响应

Trojan 的 fallback、REALITY 的设计、Naive 的前端以及 HY2 的 HTTP/3 masquerade，都在解决类似问题。Trojan 原始协议就明确设计了认证失败后转交正常服务的机制。(Trojan GFW)

④ 流量统计

这是更高级的一层。

即使内容和握手完全隐藏：

你每天晚上

20:00 → 某IP
持续 4 小时
稳定 30Mbps
双向长连接

也可能被统计模型识别为异常。

因此现代方案开始使用：

Padding
Multiplexing
Fragmentation
真实 TLS 指纹
HTTP 行为

减少统计特征。

NaiveProxy 就专门针对 TLS 指纹和长度特征做了这类处理。(GitHub)

⑤ UDP/QUIC 限制

这是：

HY2
TUIC
WireGuard

特别需要关注的问题。

如果网络环境 UDP 很好：

HY2 / TUIC
往往体验非常优秀

如果 UDP 被严重 QoS：

TCP Reality
可能反而稳定得多

十七、所以现在可以把整个技术路线分成三派

第一派是：

加密派

Shadowsocks
VMess
WireGuard

核心：

让数据无法读取。

第二派是：

HTTPS伪装派

Trojan
NaiveProxy
VLESS + TLS
VLESS + REALITY

核心：

不仅不能让你看懂，而且尽量让你觉得这是正常互联网流量。

第三派：

QUIC高速派

Hysteria2
TUIC

核心：

重点解决跨国、高延迟、丢包情况下的吞吐和延迟，同时再做一定程度的伪装。

十八、如果对应到你刚才看的 s-ui，可以这样记

最容易记住的是这一棵树：

                    代理技术
                       │
        ┌──────────────┼───────────────┐
        │              │               │
     代理协议         传输层          安全层
        │              │               │
     VLESS            RAW             TLS
     VMess            WS              REALITY
     Trojan           gRPC
     SS               XHTTP
                      QUIC
        │
        └────── 流控 / 优化
                 │
              Vision
              Mux
              Padding

所以看到：

VLESS
RAW
REALITY
XTLS Vision

正确翻译不是：

“用了四种协议。”

而是：

代理协议：VLESS
传输：RAW
安全/伪装：REALITY
流控：XTLS Vision

这也是为什么你前面 s-ui 页面里会出现很多看起来像“协议”的选项，其实它们处在完全不同的层。

如果只看目前这些技术的设计目标和综合特征，可以大致把它们记成：

VLESS + REALITY + Vision
→ TCP 路线，低开销 + 强伪装 + 高性能

NaiveProxy
→ 最强调“像真正浏览器”

Hysteria2
→ UDP/QUIC 路线，弱网和高延迟性能突出

TUIC
→ QUIC 高性能代理

Trojan
→ 经典 HTTPS 伪装路线

Shadowsocks 2022
→ 极简、高效、经典加密代理

WireGuard
→ 高性能 VPN，而非专门的伪装协议

其中最需要记住的一句话是：不存在单纯意义上的“最抗封协议”——IP 封锁、DPI、主动探测、流量统计和 UDP 限制是五种不同的问题，而不同协议解决的是其中不同部分。 (XTLS)

如果你接下来继续研究 s-ui，下一步最有价值的是把它页面里的 VLESS / Trojan / Shadowsocks / Hysteria2 → RAW / XHTTP / gRPC / WS → TLS / REALITY → Vision 每个选项逐个对应起来，我可以直接按照你上一张 s-ui 截图的菜单结构给你画成一张“协议选择树”。