[!IMPORTANT]
免责声明：本文纯属技术科普，介绍网络代理协议的发展历史与原理，不提供代理软件的安装与使用。请读者遵守所在地区的法律法规。

前言

自互联网诞生以来，网络审查与反审查技术便如同一场永无止境的”猫鼠游戏”，”军备竞赛”。一方不断筑高围墙，另一方则持续挖掘地道。这场博弈催生了一系列极具创意的网络协议与工具，也深刻影响了现代网络技术的走向。

所有进出中国大陆的国际流量，必须且只能经过由工信部批准的 国际互联网出口 流通，目前这些出口主要集中在三个国际出口——北京、上海、广州。

出口带宽由中国电信、中国联通、中国移动等少数几家国有运营商垄断经营。这种高度集中的物理拓扑，从基础设施层面赋予了 GFW 得天独厚的封锁便利性——只需在有限的几个节点部署审查设备，便可实现对十四亿人全部国际流量的监控与过滤，而无需深入到每一座城市、每一个小区的网络节点。

GFW 是怎么进行封锁的

1987年，中国发出了第一封电子邮件：“Across the Great Wall, we can reach every corner in the world”（越过长城，走向世界每个角落）。从那一年开始，我们用互联网和这个世界联系在一起了，但是就在12年后，那个越不过去长城，回来了。

1994年，中国正式接入互联网。彼时的网络世界尚是一片蛮荒，内容管控几乎为零。然而好景不长，随着互联网用户规模扩大，监管需求随之而来。

1998年，为了防止大家访问部分网站，针对IP和DNS的污染开始了。伴随着污染，墙和梯的较量正式开始。 早期的GFW不能称之为墙，更像是一个补丁，只是单纯的污染DNS，那么我们修改DNS服务器就可以绕过去。 加上国内的DNS也流氓，所以大家大多会把DNS改成Google提供的 8.8.8.8/8.8.4.4。

之后，真正的GFW正式登上历史舞台。

前北京邮电大学校长、中国工程院院士方滨兴是防火长城关键部分的首要设计师，因此他被不少中国网民称为“中国防火墙之父”。

第一代 GFW

IP 与域名封锁

GFW 维护着一份庞大的黑名单，覆盖被认定为”有害”的境外服务器 IP 段和域名。

DNS 污染是这一时期的标志性手段：GFW 在用户的 DNS 请求到达真实服务器之前将其劫持，返回一个虚假的 IP 地址，让用户根本无法找到目标服务器的正确位置。

此时的 GFW 只有两个任务：

  1. 针对IP、域名列表的扩充，扩大黑名单范围；
  2. 对新增的代理工具的封堵。

内容审查

这一时期最值得深入讲述的，是针对流量内容本身的审查。

彼时互联网尚未普及 HTTPS，绝大多数网站的 HTTP 流量完全以明文形式在网络中传输，内容对 GFW 而言如同透明玻璃。GFW 得以直接检索数据包载荷中的关键词，一旦命中敏感词库，立刻切断连接。

Google 因一个 URL 参数被误封

某段时期，Google 搜索在中国大陆突然无法访问。原因最终被定位到 Google 搜索的 URL 中存在一个参数：gs_rfai。

其中的字符串 rfa 与被大陆封锁的 自由亚洲电台（Radio Free Asia） 的英文缩写及网址高度吻合，触发了 GFW 的关键词过滤规则，导致所有携带该参数的请求被一并屏蔽。

Google 与自由亚洲电台之间，唯一的”联系”只是三个字母的巧合。

这套内容审查机制有一个根本性的阿喀琉斯之踵——它依赖流量的明文可读性。

2010 年代 HTTPS 的加速普及，尤其是 2018 年前后 Chrome 开始将非 HTTPS 网站标记为”不安全”，越来越多的网站迁移至加密传输。流量内容被 TLS 加密保护，GFW 拿到的只是密文，关键词过滤形同虚设。

第一代 GFW 的核心手段就此逐渐退出历史舞台。

第二代 GFW

内容审查失效后，GFW 进化出了更精密的武器——深度包检测（Deep Packet Inspection，DPI）。

传统防火墙只看数据包的”信封”（IP头、端口号），DPI 则深入检查数据包的内容——即协议特征、流量模式与行为规律，即便内容已加密，协议本身的特征依然可能暴露一切。

DPI 的基本原理

传统防火墙视角：
┌─────────────────┐
│ 来源IP: x.x.x.x │ ← 只看这里
│ 目标IP: y.y.y.y │
│ 端口: 443 │
│ [加密数据…] │ ← 不管这里
└─────────────────┘

DPI 视角：
┌─────────────────────────────────────┐
│ 来源IP / 目标IP / 端口 │ ← 看
│ TLS握手版本、加密套件列表 │ ← 也看
│ 证书指纹、SNI字段 │ ← 也看
│ 数据包大小分布、时间间隔规律 │ ← 还看
│ 连接持续时长、上下行流量比 │ ← 全看
└─────────────────────────────────────┘

DPI 如何识别代理流量

OpenVPN 握手特征（明文可见）：

  • 固定的 TLS 握手字节序列
  • 特定的密钥交换模式
  • 控制通道与数据通道的切换时序

GFW 行为：
建立连接 → 采集前N个数据包 → 特征匹配 → 命中 → 封锁

即便 OpenVPN 走 TCP 443 端口（该端口通常用于 HTTPS），DPI 也能通过握手报文的字节模式差异将其与真实 HTTPS 流量区分开来。Shadowsocks 的诞生，正是对这一问题的直接回应：让流量在统计特征上尽量接近”随机噪声”，令 DPI 无从识别协议类型。

SNI 嗅探

HTTPS 虽加密了内容，但 TLS 握手阶段存在一个明文字段：SNI（Server Name Indication，服务器名称指示）。

TLS 握手 ClientHello 报文（明文）：
┌────────────────────────────────────┐
│ SNI: www.google.com │ ← GFW 可直接读取
│ 支持的加密套件: […] │
│ … │
└────────────────────────────────────┘

用户访问哪个 HTTPS 网站，GFW 通过 SNI 字段一目了然。这使得即便网站内容不可见，GFW 依然能够精准封锁目标域名。这也是后来 ECH（Encrypted Client Hello） 技术被寄予厚望的根本原因——它将 SNI 也纳入加密保护范围。

第三代 GFW

DPI 是被动的——它只能分析经过自己的流量。第三代 GFW 变得更加主动。

主动探测

当 DPI 发现一个”可疑”的 IP 地址后，GFW 不再满足于被动观察，而是主动出击，向该地址发起连接，测试它是否是一台代理服务器。

完整的主动探测流程：

  1. 被动发现
    用户流量经过 GFW → DPI 标记某 IP 为”疑似代理”
  2. 主动试探
    GFW 探针服务器 ──发起连接──▶ 可疑 IP
  3. 行为判定
    目标服务器响应正常网页？ → 暂时放行
    目标服务器无响应/响应异常？ → 确认为代理 → 封锁
  4. 持续骚扰
    即便已封锁，GFW 探针仍可能持续发起连接，测试服务器是否更换了伪装策略

这一机制彻底改变了代理服务器的设计思路：服务端不能再”沉默”，必须能够对非法请求返回一个令人信服的”正常”响应。Trojan 协议的核心设计理念——“遇到非法请求就当成普通 HTTPS 网站响应”——正是对主动探测的直接反制。

流量重放攻击

GFW 的主动探测还有一种更精妙的变种：重放攻击测试。

重放攻击探测流程：

  1. GFW 录制用户与某可疑服务器的通信数据包
  2. GFW 主动将相同的数据包重新发送给该服务器
  3. 判定逻辑：
    • 正常 TLS 服务器：因 Session ID / 随机数不匹配，会返回标准的 TLS 错误或拒绝握手
    • 粗糙实现的代理服务器：可能原样处理或返回异常，暴露身份

这就要求代理协议在设计时必须考虑重放保护——对于重复发来的历史数据包，要能够以”正常服务器”的方式响应，而非暴露代理特征。VMess 的时间戳校验机制、各协议的 nonce 设计，都含有对抗重放探测的考量。

IP 信誉系统

IP 信誉评分维度：
├─ 所属 ASN是否为高风险云服务商
├─ 该 IP 段历史上被举报的频率
├─ 主动探测结果（是否表现异常）
├─ 流量行为模式（是否大量用户同时连接）
└─ 地理位置（某些地区的 IP 天然高度可疑）

大量廉价 VPS 服务商（如 Vultr、DigitalOcean 的部分 IP 段）因被代理用户大规模使用，逐渐积累了极高的风险评分，导致新注册的 VPS 刚上线便遭封锁。

第四代 GFW

前三代 GFW 的检测逻辑本质上都是基于规则的：命中某个特征模式就封锁。第四代 GFW 开始引入机器学习，从”规则匹配”进化为”统计推断”。

流量统计特征分析

即便无法解密流量内容，每一条网络连接都会在统计层面留下独特的”指纹”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
机器学习模型的输入特征：

时间维度：
  ├─ 数据包到达时间间隔的分布
  ├─ 连接建立到首包发送的延迟
  └─ 连接总持续时长

大小维度：
  ├─ 数据包大小的均值、方差、分布形态
  ├─ 上行/下行包大小比值
  └─ 突发流量的形态特征

行为维度：
  ├─ 单位时间内的请求频率
  ├─ 多路复用的连接数量模式
  └─ 连接复用与重建的规律

熵值分析：
  └─ 数据包字节的信息熵
     （真随机加密流量的熵值分布有其规律）

通过对大量已知代理流量和正常流量的训练，模型能够以一定概率对”未知协议”的连接进行分类——即便该协议从未被见过，只要其统计特征与已知代理流量相似，就会被标记为可疑。

为什么 Hysteria2 选择 UDP/QUIC

第四代 GFW 的统计分析模型，其训练数据主要来自 TCP 流量——毕竟绝大多数代理协议都基于 TCP。

QUIC 协议基于 UDP，其流量的统计特征与传统 TCP 代理流量有着根本性的差异，现有模型的泛化能力在面对 QUIC 时相对有限。这是 Hysteria2、TUIC 等基于 QUIC 协议的工具在对抗第四代 GFW 时具备相对优势的重要原因之一。

特征维度 TCP 代理流量 QUIC 代理流量
握手特征 三次握手特征明显 0-RTT 或 1-RTT 快速建立
确认机制 严格的 ACK 机制 自定义拥塞控制算法
传输表现 线头阻塞导致的停顿规律 多路复用，无垂直线头阻塞
识别难度 模型训练样本充足，易被识别 模型训练样本相对稀少，探测难度高

Reality 的应对思路

面对统计流量分析，XTLS Reality 给出了一个截然不同的解题思路：与其让自己的流量特征”足够接近”正常流量，不如让自己的流量特征直接就是正常流量。

Reality 工作机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
代理连接建立阶段：
  客户端 ──TLS握手──▶ 服务端
                      │
                      ├─ 验证特殊字段（ClientHello 中隐藏的身份信息）
                      │   ├─ 验证通过 → 建立代理连接
                      │   └─ 验证失败 → 将连接转发给真实的目标网站
                      │               （如 microsoft.com）
                      ↓
  GFW 主动探测时：
  探针 ──请求──▶ 服务端 ──转发──▶ microsoft.com ──响应──▶ 探针
                （探针得到的是微软官网的真实TLS证书和响应）

流量统计特征：
  Reality 的流量 = 真实 TLS 1.3 流量特征
  底层 TLS 实现完全相同
  统计特征无限接近真实 HTTPS 访问

机器学习模型无法将 Reality 流量与访问 microsoft.com 的流量区分开来，因为两者在技术层面本就是同一回事。

当前的对抗

这种”不完全封锁”并非技术无能，而是一种理性的政策选择：将误封率控制在商业和社会可接受的范围内，同时维持足够高的翻墙门槛，将大多数普通用户拦截在外。

SOCKS 与 HTTP 代理

HTTP 代理是最古老的代理形式之一，其原理简单到几乎不需要解释：

1
2
3
4
5
6
没有代理时：
用户 ──HTTP请求──▶ 目标服务器（被GFW拦截）

使用HTTP代理时：
用户 ──HTTP请求──▶ 境外代理服务器 ──▶ 目标服务器
                  （GFW只看到与代理的通信）

HTTP 代理有一个显而易见的局限：它只能处理 HTTP 协议的流量。非 HTTP 流量（如即时通讯、游戏、视频流等）完全无法通过 HTTP 代理转发。

为了弥补 HTTP 代理的局限性， SOCKS 协议应运而生。

SOCKS 工作在更底层，它不关心上层是什么应用协议——HTTP 也好，SMTP 也好，任意 TCP 连接都可以通过 SOCKS 代理转发。

SOCKS5 握手过程：

  1. 客户端 → 代理：我想连接 google.com:443
  2. 代理 → 客户端：好的，连接已建立
  3. 客户端 ↔ 代理 ↔ google.com：透明转发，代理不关心内容

无论是 HTTP 代理还是 SOCKS5 代理，在代理场景下都有两个根本性的弱点：

第一，流量完全不加密。 用户与代理服务器之间的通信是明文的。GFW 不仅能看到你在使用代理，甚至能看到你通过代理在访问什么内容。

第二，代理服务器 IP 极易被封锁。 一旦 GFW 识别出某个 IP 是代理服务器（通过流量特征或举报），直接将其加入黑名单即可。代理服务器的 IP 地址是固定的、公开的，封锁成本极低。

这两个弱点决定了普通代理只能作为一种临时性的应急手段，无法在对抗 GFW 的长期博弈中占据一席之地。真正的角力，还需要更重量级的技术登场。

VPN 时代

VPN 的本来面目

VPN（Virtual Private Network，虚拟私人网络） 从未被设计用来翻墙。它最初的使命，是帮助企业员工在出差或居家时，安全地接入公司内网——就好像在公网上凿出一条加密的”专用隧道”，让远程用户仿佛置身于公司局域网之内。

中国用户发现，这条”加密隧道”同样可以打通另一个方向——将流量引导至境外，从而绕过 GFW。于是，一项企业级技术被大规模挪用，成为当时翻墙主流。

PPTP：最简单也最脆弱

PPTP（Point-to-Point Tunneling Protocol） 是微软在 1999 年主导开发的隧道协议，Windows 系统原生支持，配置极为简单——填入服务器地址、用户名和密码，点击连接即可。

然而，PPTP 的安全性是 VPN 协议中公认最差的：

PPTP 的主要安全问题：
加密算法：MS-CHAPv2（已于2012年被完全破解）
认证机制：可被中间人攻击
数据加密：MPPE 最高128位，强度不足
隐患：理论上GFW可在不封锁的前提下直接解密流量

更致命的是，PPTP 使用固定的 TCP 1723 端口和 GRE 协议，特征极为明显，GFW 只需封锁这两个特征，PPTP 便彻底失效。

L2TP/IPSec：稍好，但依然透明

L2TP（Layer 2 Tunneling Protocol） 本身不提供加密，通常与 IPSec 捆绑使用，由 L2TP 负责建立隧道，IPSec 负责加密。

安全性相较 PPTP 有所提升，但同样面临特征明显的问题，封锁成本极低，效果立竿见影。

OpenVPN

2002 年，开发者 James Yonan 发布了 OpenVPN，这是第一个真正为灵活性和安全性而设计的开源 VPN 协议。

核心优势：

OpenVPN 基于 OpenSSL 库，使用标准 TLS 协议进行加密，安全性远超 PPTP 和 L2TP。更重要的是，它可以运行在任意端口，包括 TCP 443——这正是 HTTPS 的标准端口。

这个思路极具启发性——端口伪装，即用合法端口承载非合法（在审查方看来）流量，成为此后数十年反审查技术的核心思路之一。

然而，GFW 很快进化出了 DPI 能力。OpenVPN 的 TLS 握手虽然看起来像 HTTPS，但在字节层面存在可识别的特征差异：

1
2
3
4
5
6
7
8
9
真实 HTTPS (TLS) 握手：
  ClientHello → ServerHello → Certificate → ... → 应用数据

OpenVPN TLS 握手：
  ClientHello → ServerHello → Certificate → ...
                                             ↑
                              此后出现 OpenVPN 自定义控制通道
                              数据包大小、时序与真实HTTPS不符
                              ── DPI 可识别

此外，OpenVPN 协议较重，在高延迟、高丢包的跨国线路上性能表现不佳。

2012 年前后，随着 GFW 的 DPI 能力趋于成熟，主流 VPN 协议逐一沦陷。

如今的 VPN 并未完全封锁而是采用白名单制，以应对企业的需求。

为对抗审查而生的 Tor

Tor（The Onion Router，洋葱路由器） 并非诞生于硅谷，而是出自美国海军研究实验室。

1990 年代中期，美国军方面临一个棘手的情报问题：特工在互联网上传递信息时，即便内容经过加密，通信双方的身份（即 IP 地址）依然暴露无遗。加密能保护”说了什么”，却无法隐藏”谁在和谁说话”。

为解决这一问题，数学家 Paul Syverson 与计算机科学家 Michael Reed、David Goldschlag 提出了洋葱路由的概念，并于 1997 年发表论文，2002 年形成可用实现。2004 年，Tor 的源代码以自由软件许可证对外发布，逐渐成为全球反审查与匿名通信的重要基础设施。

Tor 的核心创新在于一个优雅的比喻——洋葱。

普通代理只有一层：用户 → 代理 → 目标，代理服务器完整地知道用户的身份和目标。Tor 则将这个路径拆解为多跳，并将数据像洋葱一样包裹在多层加密之下：

Tor 的加密与路由过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[原始数据] 
  → 用 节点C 的公钥加密 → [密文C]
  → 用 节点B 的公钥加密 → [密文B[密文C]]
  → 用 节点A 的公钥加密 → [密文A[密文B[密文C]]]

传输过程：

用户 ──密文A[B[C]]──▶ 节点A（入口节点）
                       用私钥解密外层，得到密文B[C]
                       只知道："来自用户，转发给节点B"
                          ↓
                       节点B（中间节点）
                       用私钥解密，得到密文C
                       只知道："来自节点A，转发给节点C"
                          ↓
                       节点C（出口节点）
                       解密得到原始数据
                       只知道："来自节点B，发送给目标网站"
                          ↓
                       目标网站

每个节点只知道自己的上游和下游，没有任何单一节点能够同时掌握”谁发出了请求”和”请求的目标是什么”。这就是洋葱路由匿名性的数学基础。

尽管 Tor 的匿名设计极为精妙，但在翻墙这个具体场景下，它有一个难以回避的缺陷：

慢。非常慢。

三次加密解密、三跳转发、志愿者节点带宽参差不齐——这些因素叠加，使得 Tor 在需要高速访问的日常浏览场景下体验极差。Tor 更适合对速度不敏感、对匿名性要求极高的特定场景（如举报人传递文件、记者在高风险地区通信）。

对于绝大多数只是想看看 YouTube、用用 Google 的普通中国网民而言，Tor 太重了。他们需要的，是一个更轻、更快、更聪明的工具。

这个工具，一位中国程序员正在写。

Shadowsocks 协议

2012 年 4 月，一位化名 clowwindy 的中国程序员在 GitHub 上提交了第一行 Shadowsocks 的代码。背后是一个技术人对现有方案的深刻不满——VPN 太重，Tor 太慢，HTTP 代理不加密，SSH 隧道需要技术门槛。clowwindy 想要一个轻量、快速、难以识别的代理协议，于是他自己写了一个。

此前所有的代理工具，都在尝试”隐藏”流量——用加密包裹起来，让 GFW 看不见内容。但 GFW 不需要看见内容，它只需要识别出”这是一条代理连接”，便可以封锁。

clowwindy 换了一个角度思考：能不能让代理流量在统计上与正常的加密流量无法区分？

这个问题的答案，就是 Shadowsocks。

协议设计

Shadowsocks 协议极为精简，去掉了一切不必要的元数据：

Shadowsocks 数据包结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────┐
│            经过 AEAD 加密的载荷              │
│  ┌──────────────────────────────────────┐   │
│  │  目标地址（ATYP + HOST + PORT）      │   │
│  │  实际数据                            │   │
│  └──────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

没有：
  × 版本号字段
  × 握手协商过程
  × 任何可识别的协议头
  × 连接状态标识

整个数据流从第一个字节开始就是密文，没有任何明文的协议握手过程。GFW 的 DPI 拿到这个数据流，无法找到任何已知协议的特征码，在当时只能选择放行。

加密机制

早期支持的加密方式：
AES-128-CFB、AES-256-CFB、ChaCha20 等

问题：流密码不提供数据完整性验证
攻击者可以：

  1. 在不解密的情况下篡改密文，导致解密后数据出错
  2. 更严重：利用”选择密文攻击”，
    在某些条件下推断出明文内容（CCA攻击）

AEAD 加密（以 AES-256-GCM 为例）：

加密：明文 + 密钥 + Nonce → 密文 + 认证标签（Tag）
解密：密文 + 密钥 + Nonce + Tag → 明文（验证完整性）

优势：
✓ 加密 + 完整性验证 一步完成
✓ 任何篡改都会导致解密失败（Tag验证不通过）
✓ 抵抗选择密文攻击
✓ Nonce 递增机制防止重放攻击

本地与远程分工

完整的 Shadowsocks 连接流程：

1
2
3
4
5
6
7
8
9
10
11
12
应用程序
  ↓ SOCKS5
ss-local（本地客户端）
  ↓ 解析目标地址
  ↓ AEAD 加密（目标地址 + 数据）
  ↓ TCP/UDP
防火长城 ←── 看到的是无法识别的随机字节流
  ↓
ss-server（境外服务器）
  ↓ AEAD 解密，取出目标地址
  ↓ 代为发起连接
目标网站（Google、YouTube等）

本地客户端暴露一个标准的 SOCKS5 接口，对应用层完全透明——应用程序根本不需要知道自己的流量经过了代理。

clowwindy 的离开

2015 年 8 月 22 日，clowwindy 在 GitHub 上留下了一段令无数人扼腕的话：

“Two days ago the police came to me and wanted me to stop working on this. Today I’m deleting all the code.”

image.png

但代码已经传遍世界。Shadowsocks 早已被 fork 成数十个版本，被无数人在自己的服务器上运行。一个人可以被噤声，但已经自由传播的代码无法被收回。

由于Shadowsocks系列在翻墙界长期享有盛名，它的纸飞机logo一度甚至成为了翻墙的代名词，许多翻墙服务商也因此被称为“机场”。

image.png

基于SS的衍生协议

GFW 的反击：流量分析

Shadowsocks 的设计在 2012-2014 年间几乎是无敌的。GFW 拿到一段随机字节流，无法识别协议，只能放行。

然而 GFW 的工程师们很快发现了另一条路——不需要识别协议，只需要找到可疑的服务器。

具体方法是：对 Shadowsocks 服务器发起主动探测：

GFW 主动探测流程：

1
2
3
4
5
6
7
8
9
10
11
1. 发现某IP有大量用户以奇怪的加密连接进行访问
2. GFW 主动连接该IP的对应端口
3. 发送随机字节
4. 观察服务器的反应：
   ├─ 直接断开连接 → 可疑！正常服务器不会这样
   ├─ 无响应/超时 → 可疑！
   └─ 返回有意义的HTTP/TLS响应 → 可能是正常服务器

早期 Shadowsocks 服务器：
  收到无法解密的随机字节 → 解密失败 → 直接断开
  → 被 GFW 判定为代理服务器 → 封锁

这就是著名的 “特征暴露”问题 ：Shadowsocks 服务器面对非法探测时的沉默或断开，本身就是一种暴露。

ShadowsocksR：混淆功能

ShadowsocksR（SSR） 由一位化名 breakwa11 的开发者于 2015 年推出，在 Shadowsocks 的基础上增加了两个核心机制：

混淆插件（Obfuscation）

混淆的目标是让 Shadowsocks 流量”看起来像”某种已知的正常协议：

SSR 混淆方式示例：

  • http_simple：
    在数据流前添加伪造的 HTTP 请求头
    GET / HTTP/1.1\r\nHost: bing.com\r\n…
    [实际的SS加密数据]
    → 看起来像普通HTTP请求

  • tls1.2_ticket_auth：
    伪造 TLS 握手过程
    → 看起来像 TLS 连接

  • plain（不混淆）：
    依然是随机字节流

协议插件（Protocol）

协议层的改造主要针对主动探测问题：

1
2
3
4
5
6
7
auth_sha1_v4 等协议插件：
  在数据包中加入基于时间戳和密钥的 HMAC 认证
  
  合法客户端发来的数据：HMAC 验证通过 → 正常处理
  GFW 探针发来的随机数据：HMAC 验证失败 → 不立即断开
                                          → 模拟正常服务器行为
                                          → 让探针"找不到把柄"

SSR 的争议

SSR 的出现伴随着巨大的社区争议。breakwa11 以闭源方式开发核心混淆逻辑，与 Shadowsocks 社区产生了激烈冲突。批评者认为，闭源的安全工具不可信；支持者则认为，混淆算法公开会让 GFW 更快针对性破解。

2017 年，breakwa11 遭到人肉搜索，随即删除了所有代码和账号，SSR 的官方开发就此终止。但与 Shadowsocks 的历史如出一辙，代码已经广泛传播。

V2Ray 与 VMess 协议

2015 年，就在 clowwindy 被迫停止 Shadowsocks 开发的同一年，一位化名 Victoria Raymond 的开发者发布了 V2Ray。

如果说 Shadowsocks 是一把精准的手术刀——专注于解决”让流量难以识别”这一个问题，那么 V2Ray 的定位则截然不同：它不是一个翻墙工具，而是一个 网络代理平台。

“Project V is a set of tools to help you build your own privacy network.”
V2Ray 不提供任何服务器，它只提供协议和框架。

这种定位的差异，决定了 V2Ray 的架构远比 Shadowsocks 复杂，也远比 Shadowsocks 灵活。

VMess 协议设计

V2Ray 的核心自研协议是 VMess（V2Ray Message），它在设计上吸取了 Shadowsocks 的经验，并针对主动探测问题做出了根本性的改进。

基于时间的身份认证

VMess 最具特色的设计是其 无状态认证机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
VMess 认证过程：

客户端与服务端共享：
  ├─ UUID（用户唯一标识符，如 550e8400-e29b-41d4-a716-446655440000）
  └─ alterId（额外ID数量，用于生成动态ID）

每次连接时，客户端发送的认证信息：

  HMAC-MD5(UUID + UTC时间戳)
       ↑
  每30秒变化一次
  服务端检查：|客户端时间 - 服务端时间| < 90秒
  
GFW 探针无法伪造有效的认证信息
  → 发送随机数据时，服务端认证失败
  → 服务端选择"不响应"或"缓慢超时"
  → 探针无法判断这是代理还是防火墙

这解决了 Shadowsocks 面对主动探测时”哑口无言”的问题：VMess 服务端对非法连接的处理更加从容，不会立即暴露身份。

数据包结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
VMess 请求数据包（加密后）：

┌────────────────────────────────────────────┐
│  认证信息（16字节，基于UUID+时间戳的HMAC）    │  ← 明文，用于服务端识别用户
├────────────────────────────────────────────┤
│  指令部分（加密）                            │
│    版本号                                   │
│    数据加密 IV + Key                        │
│    响应认证值                               │
│    选项（是否启用重用、混淆等）               │
│    填充长度 + 加密方式                       │
│    目标地址类型 + 地址 + 端口                │
├────────────────────────────────────────────┤
│  数据部分（加密）                            │
│    实际载荷                                 │
└────────────────────────────────────────────┘

每个连接的加密密钥都是动态生成的，即便 GFW 截获了历史流量，也无法用来重放攻击——因为时间戳验证会失败，且每次会话的 IV 和 Key 都不同。

VMess 的局限

VMess 的时间戳机制是一把双刃剑。
VMess 的已知问题：

  1. 时间同步要求
    客户端与服务端时差不能超过 90 秒
    时区混乱或系统时间错误 → 连接失败
    在某些嵌入式设备或时间同步困难的环境下很麻烦

  2. 协议头开销
    相较于 Shadowsocks，VMess 的协议头更复杂
    在高频短连接场景下，额外开销更明显

  3. MD5 的争议
    早期 VMess 认证使用 MD5，虽非用于数据加密
    但 MD5 本身的安全性问题引发了社区讨论
    后续版本引入了更安全的替代方案

V2Ray 的核心架构：传输层与协议层分离

VMess 只是 V2Ray 的协议层，真正让 V2Ray 脱颖而出的，是其传输层与协议层彻底分离的架构设计：

V2Ray 分层架构：

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────┐
│              应用层协议（入站）              │
│   VMess / VLESS / Shadowsocks / Trojan ...  │
├─────────────────────────────────────────────┤
│              传输层（可自由组合）            │
│   TCP / WebSocket / HTTP2 / gRPC / QUIC ... │
├─────────────────────────────────────────────┤
│              安全层（可选）                  │
│              TLS / XTLS / Reality           │
├─────────────────────────────────────────────┤
│              底层网络                        │
│              IPv4 / IPv6                    │
└─────────────────────────────────────────────┘

这意味着你可以自由组合：

  • VMess + TCP（最基础）
  • VMess + WebSocket + TLS（最常用，下一节详述）
  • VMess + HTTP/2 + TLS
  • VMess + gRPC + TLS
  • ……

每一种组合，都带来不同的流量特征、不同的性能表现、不同的抗封锁能力。

路由与分流

V2Ray 的另一个重要贡献是内置的路由引擎：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
routing:
  rules:
    - type: field
      domain:
        - geosite:cn          # 中国域名
        - geosite:private     # 私有地址
      outbound: direct        # 直连，不走代理

    - type: field
      ip:
        - geoip:cn            # 中国IP段
      outbound: direct

    - type: field
      domain:
        - geosite:ads         # 广告域名
      outbound: block         # 直接丢弃

    - type: field
      network: tcp,udp
      outbound: proxy         # 其余流量走代理

这套路由引擎让 V2Ray 能够精确地决定每一条连接的走向：国内流量直连（保证速度），国外流量代理（绕过GFW），广告流量丢弃（顺带去广告）。这比早期工具的”全局代理”模式在体验上有了质的飞跃。

WebSocket + TLS + CDN 的组合技

纯粹的 VMess over TCP，在理论上流量特征已经相当接近随机噪声。但它依然面临一个现实困境：服务器 IP 的暴露问题。

无论协议伪装得多好，只要 GFW 发现某个 IP 持续被大量用户以”奇怪”的方式访问，它可以不管协议是什么，直接将该 IP 封锁。封 IP 比识别协议代价更低、效率更高。

这催生了代理技术史上最具创意的组合方案之一：WebSocket + TLS + CDN，俗称”套 CDN“或”套 CF（Cloudflare）“。

第三层的 CDN（内容分发网络）

CDN 的本职工作是将网站内容缓存在全球各地的节点，加速用户访问。当用户访问一个接入了 CDN 的网站时，实际连接的是 CDN 的节点服务器，CDN 再将请求转发给源站。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
套 CDN 之后的连接路径：

用户 ──HTTPS──▶ Cloudflare CDN节点 ──▶ 代理服务器（源站）
               （合法的CDN IP）         （真实IP被隐藏）

GFW 看到的：
  用户在访问 Cloudflare 的 IP 地址
  流量是标准的 HTTPS

GFW 的困境：
  封锁 Cloudflare 的 IP？
  → Cloudflare 是全球最大的 CDN 服务商之一
  → 中国境内依赖 Cloudflare 的网站不计其数
  → 封锁 Cloudflare = 大规模误伤正常业务
  → 政治经济代价过高，投鼠忌器

代理服务器的真实 IP 被 Cloudflare 的 IP 所遮蔽，GFW 即便想封锁，也只能选择封锁 Cloudflare 的整个 IP 段——而这是它不敢轻易做的事。

代价：延迟与速度

这个方案几乎完美——但天下没有免费的午餐。

流量经过 CDN 中转，意味着多了一跳网络传输。更关键的是，Cloudflare 的免费套餐对 WebSocket 流量的带宽和连接数有限制，在高峰时段体验可能不佳。

CDN 优选 IP

由于 Cloudflare 在中国的节点覆盖有限，流量往往需要绕道亚太地区的节点才能入境，延迟较高。

为此，社区开发出了 CDN 优选 IP 工具（如 CloudflareSpeedTest），通过批量测试 Cloudflare 的 IP 段，找出延迟最低、速度最快的节点。

WebSocket + TLS + CDN 的组合，标志着代理技术从”对抗识别”进化到了”对抗封锁”的新阶段。 它不是让流量难以识别，而是让封锁的代价高到 GFW 不愿意付出。

VLESS 与 XTLS 的性能优化

VMess 的冗余

WebSocket + TLS + CDN 的组合虽然在抗封锁上表现优异，但在性能上引入了明显的开销。V2Ray 社区的开发者们开始重新审视 VMess 协议本身，发现了一个结构性的浪费：

1
2
3
4
5
6
7
8
9
10
11
VMess over TLS 的加密现状：

用户数据
  ↓ VMess 自身的 AEAD 加密（第一层）
  ↓ TLS 加密（第二层）
网络传输

问题：数据被加密了两次
  TLS 已经提供了足够强的加密和认证
  VMess 的内层加密在 TLS 保护下变得多余
  两次加密 = 两倍的 CPU 开销

这就是所谓的”双重加密“问题。在现代 CPU 上，AES 加密因硬件指令集（AES-NI）的存在速度极快，单层加密几乎没有瓶颈；但双重加密依然会在高速传输场景下造成可感知的性能损耗，尤其在嵌入式设备或移动端上。

VLESS：去掉内层加密的极简协议

VLESS 是 V2Ray 社区（后来主要由 Xray 项目主导）对 VMess 的一次大刀阔斧的精简：

VMess vs VLESS 核心对比：

维度 VMess VLESS
自身加密 有（AEAD） 无（精简协议）
时间戳验证 有（误差需在 ±90秒内） 无
TLS 依赖 可选 强依赖（必须配合 TLS 使用）
协议头开销 较大 极小
认证方式 UUID 认证 UUID 认证
性能表现 良好 更优（开销更低）
安全性保障 协议自身提供加密 完全委托给 TLS 层

VLESS 的设计哲学是彻底的职责分离：

  • 加密这件事，交给 TLS 去做，TLS 已经足够好；
  • VLESS 只需要做好一件事：轻量、高效地将用户数据从 A 点传到 B 点。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
VLESS 数据包结构（极简）：

┌────────────────────────────────┐
│  协议版本（1字节）              │
│  UUID（16字节，用户认证）       │
│  附加信息长度（1字节）          │
│  附加信息（可选）               │
│  指令（1字节）                  │
│  目标端口（2字节）              │
│  目标地址类型+地址              │
├────────────────────────────────┤
│  实际数据（透明传输）            │
└────────────────────────────────┘

整个结构只有外层TLS一层加密
CPU开销减半

XTLS：消灭”双重 TLS”

VLESS 解决了 VMess 的冗余加密问题，但 Xray 的开发者 rprx 发现还有一个更深层的性能问题尚未解决。

当用户访问 HTTPS 网站时，连接中实际上存在两层 TLS：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
访问 https://google.com 时的实际流量：

用户浏览器 ──[外层TLS]──▶ VLESS服务端 ──[内层TLS]──▶ google.com
            （代理隧道）                 （网站本身的HTTPS）

数据流：
  google.com 的响应数据
    ↓ google.com 用自己的证书加密（内层TLS密文）
    ↓ VLESS服务端再用代理TLS加密（外层TLS）
    ↓ 传输给客户端
  客户端先解外层TLS，再解内层TLS

问题：内层TLS密文被外层TLS又加密了一遍
     这一层外层TLS加密在数学上是完全多余的
     ── 没人能在不知道内层密钥的情况下利用这个"漏洞"
     ── 但CPU还是老老实实做了这次无意义的加密

XTLS（eXtreme TLS） 正是为消灭这个多余的外层加密而生：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
XTLS Vision 工作原理：

握手阶段：
  客户端 ──[外层TLS握手]──▶ 服务端
  （此阶段仍需外层TLS，因为握手数据不是TLS密文）

数据传输阶段（核心创新）：
  检测到内层流量已经是TLS密文？
    ├─ 是 → 直接传输内层TLS密文，跳过外层TLS加密
    └─ 否 → 保持正常的外层TLS加密

效果：
  CPU加密运算量 ≈ 单层TLS
  吞吐量大幅提升（尤其在访问HTTPS网站时）
  延迟降低

这个优化在理论上非常优雅，但实现上极为复杂——需要在 TLS 栈内部精确识别内层流量是否为 TLS 密文，并在适当时机切换传输模式。

Xray：V2Ray 的社区分支

XTLS 和 VLESS 最初由 rprx 作为 PR 提交给 V2Ray 主项目，但因为架构分歧和代码审查争议，最终未能合并。

2020 年底，rprx 及一批社区成员 fork 了 V2Ray，建立了独立的 Xray-core 项目。Xray 首先实现了 XTLS 和 VLESS，随后又推出了 REALITY 协议。

VLESS + XTLS Vision 的组合，在性能优化的道路上已经走到了极致。但性能之外，还有一个更根本的问题尚待解决：如何在主动探测面前，让服务器”完美装作”一台普通的 HTTPS 服务器？

答案，是 REALITY。

REALITY 协议

TLS 是纸糊的盔甲

VLESS + XTLS Vision 在性能上已近乎完美，但在对抗 GFW 主动探测时仍有一个根本性的软肋。

当代理服务器使用自己申请的 TLS 证书时，GFW 的主动探测可以这样工作：

GFW 主动探测流程：

  1. 发现可疑 IP：x.x.x.x
  2. 主动发起 TLS 连接
  3. 获取服务器证书
  4. 检查证书信息：
    ├─ 证书域名是否与实际业务相符？
    ├─ 该域名是否有真实的网站内容？
    ├─ 证书签发时间是否异常？
    └─ 该域名的备案信息是否存在？
  5. 进一步探测：
    发送非代理格式的 HTTP 请求
    → 真实网站：返回正常网页内容
    → 伪装的代理：返回空响应或错误
  6. 综合判定 → 封锁

即便服务器配置了 Nginx 返回一个”正常”的网页，GFW 仍可通过以下手段识破：

  • 该域名注册时间极短，缺乏历史访问记录
  • 网站内容过于简单，与真实业务不符
  • TLS 指纹（JA3/JA3S）与声称的服务器软件不匹配
  • 证书链的签发机构组合较为罕见

自建的伪装站，终究是一套”纸糊的盔甲”——经不起探测。

REALITY 的核心理念：借鸡生蛋

REALITY 由 rprx 于 2023 年初发布，它提出了一个截然不同的思路：

与其费力伪造一个真实的网站，不如直接”借用”一个真实存在的网站的 TLS 身份。

这个想法听起来近乎离谱——TLS 的核心安全假设之一，正是私钥不可伪造。REALITY 并非伪造证书，而是设计了一套精妙的机制，让代理服务器在外部观察者眼中，与访问某个真实知名网站 完全无法区分。

技术原理：在握手中藏入秘密

REALITY 的核心是对 TLS 1.3 握手流程的创造性利用。

首先回顾标准 TLS 1.3 握手：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
标准 TLS 1.3 握手：

客户端                              服务端
   │                                  │
   │──── ClientHello ────────────────▶│
   │     (包含: 随机数, 支持的算法,   │
   │      SNI: microsoft.com,         │
   │      KeyShare: 客户端公钥)       │
   │                                  │
   │◀─── ServerHello ────────────────│
   │     (包含: 随机数,               │
   │      KeyShare: 服务端公钥)       │
   │                                  │
   │◀─── EncryptedExtensions ────────│  ← 此后全部加密
   │◀─── Certificate ────────────────│  ← 服务端证书
   │◀─── CertificateVerify ──────────│
   │◀─── Finished ───────────────────│
   │                                  │
   │──── Finished ───────────────────▶│
   │                                  │
   │══════════ 应用数据传输 ══════════│

REALITY 的关键在于 ClientHello 中的一个字段：session_id。

在 TLS 1.3 中， session_id 是一个遗留字段，协议本身不使用它，服务端通常将其原样回传。REALITY 将这个”废弃”字段改造成了 秘密通信的隐蔽信道：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
REALITY 握手过程：

合法的 REALITY 客户端：
   │
   │──── ClientHello ───────────────▶│
   │     SNI: microsoft.com          │  ← 目标是知名网站
   │     session_id: [特殊构造的值]   │  ← 藏入身份认证信息
   │     KeyShare: [临时公钥]         │
   │                                 │
   │     服务端验证 session_id：      │
   │     用 REALITY 私钥解析其中的     │
   │     身份信息 → 验证通过           │
   │                                 │
   │◀─── ServerHello ────────────────│  ← 用真实目标网站的证书响应
   │◀─── Certificate(microsoft.com)──│  ← ！这是真实的微软证书
   │◀─── ...（后续握手）───────────── │
   │                                 │
   REALITY 客户端从 ServerHello 中    │
   提取服务端的临时公钥                │
   用 REALITY 公钥验证其签名           │
   确认这是真正的 REALITY 服务端       │
   建立代理连接 ✓                     │

非法探测者（GFW 探针）：
   │
   │──── ClientHello ────────────────▶│
   │     session_id: [随机/空]         │  ← 无法构造合法的认证信息
   │                                  │
   │     服务端验证失败                │
   │     → 将连接转发给真实的           │
   │       microsoft.com              │
   │                                  │
   │◀─── （来自微软服务器的真实响应）─│  ← 探针看到的是真实的微软网站！

为什么 GFW 无法识破

REALITY 的防探测能力来自多个层面：

第一，证书是真实的。
GFW 探针发起连接后，获得的是 microsoft.com（或其他配置的知名网站）的 真实 TLS 证书——因为 REALITY 服务端真的将探针的连接转发给了微软的服务器，并将响应原样传回。这不是伪造，而是真正的转发。

第二，TLS 指纹是真实的。
TLS 握手中的各项参数（加密套件列表、扩展字段、顺序等）共同构成了 JA3 指纹，不同的 TLS 库实现有不同的指纹。REALITY 客户端使用与真实浏览器相同的 TLS 参数，指纹与 Chrome 或 Firefox 完全一致。

第三，目标网站的选择至关重要。
REALITY 配置中需要指定一个 serverName——即对外声称正在访问的网站。选择的网站需要满足：

  • 使用 TLS 1.3（REALITY 依赖 TLS 1.3 特性）
  • 知名度高（GFW 不敢轻易封锁）
  • 未使用 ESNI/ECH（否则握手流程不兼容）
  • 服务器在境外（需要能够真实转发探针流量）
  • 该域名本身未被 GFW 封锁 IP（否则探针转发失败会露馅）

REALITY 的密钥体系

REALITY 引入了一套独立的密钥体系，与目标网站的证书完全无关：

  • 服务端生成：
    privateKey（私钥）── 仅服务端持有，用于验证客户端身份
    publicKey（公钥） ── 写入客户端配置

  • 工作流程：
    客户端用 publicKey 构造 session_id 中的认证信息
    服务端用 privateKey 验证 session_id

  • 这套密钥与 TLS 证书完全无关
    TLS 证书来自真实的目标网站（微软、苹果等）
    REALITY 密钥只用于识别”谁是合法的 REALITY 客户端”

REALITY 的意义

REALITY 代表了反审查技术的一次重要跃迁——从”模仿正常流量”到”成为正常流量”。

目前，VLESS + XTLS Vision + REALITY 被社区公认为在抗封锁与性能之间取得最佳平衡的协议组合，是当前最主流的代理方案之一。

Trojan

Trojan 诞生于 2019 年前后，比 REALITY 早了约四年。虽然两者的目标相似——让代理服务器在主动探测面前通过审查——但实现思路和技术路径截然不同。

理解 Trojan，需要先理解它所针对的核心问题。

问题：代理服务器的”哑巴”特征

在 Trojan 出现之前，即便是伪装最好的代理服务器，在面对 GFW 主动探测时也存在一个共同弱点：

GFW 探针的典型攻击手法：

  1. 正常 TLS 握手（服务器通过）

  2. 发送一个普通的 HTTP GET 请求：
    GET / HTTP/1.1
    Host: example.com

  3. 观察响应：
    ├─ 真实网站：返回 200 OK + 网页内容
    ├─ Shadowsocks服务器：连接重置或无响应
    ├─ V2Ray服务器：返回配置的伪装页面（但特征可疑）
    └─ → 异常响应即暴露身份

即便配置了 Nginx 返回一个网页，服务器的行为模式与真实 Web 服务器之间，仍有细微但可检测的差异。

Trojan 的设计理念：让代理本身就是网站

Trojan 的核心思想极为直接：

不是在代理服务器前面放一个网站作为掩护，而是让代理服务器的行为在协议层面与真实 HTTPS 服务器完全一致。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Trojan 服务端的工作逻辑：

接收到 TLS 连接
    ↓
TLS 握手（使用真实域名的证书）
    ↓
读取客户端发来的第一段数据
    ↓
┌─────────────────────────────────────────┐
│  数据是否以 Trojan 协议头开始？           │
│                                         │
│  Trojan 协议头 = SHA224(密码) + \r\n     │
│              + SOCKS5格式目标地址        │
│              + \r\n                     │
├─────────────┬───────────────────────────┤
│     是      │          否               │
│     ↓       │          ↓                │
│  代理模式   │   将整个连接（含已读数据）   │
│  建立代理   │   转发给本地的真实Web服务器  │
│  连接       │   （如 Nginx）             │
└─────────────┴───────────────────────────┘

这个设计的精妙之处在于：Trojan 服务端对非法连接的处理，在网络层面与一台真实的反向代理服务器完全相同——因为它本来就是在做反向代理。

协议头设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Trojan 请求格式：

┌─────────────────────────────────────┐
│  密码的 SHA224 哈希值（56字节十六进制）│  ← 身份认证
├─────────────────────────────────────┤
│  \r\n（CRLF）                        │
├─────────────────────────────────────┤
│  CMD（1字节）                        │  ← 0x01=TCP, 0x03=UDP
├─────────────────────────────────────┤
│  目标地址（SOCKS5格式）               │  ← 代理目标
│    ATYP（1字节）                     │
│    地址（可变长）                    │
│    端口（2字节）                     │
├─────────────────────────────────────┤
│  \r\n（CRLF）                       │
├─────────────────────────────────────┤
│  实际数据载荷                        │
└─────────────────────────────────────┘

整个数据包在 TLS 加密下传输
外部观察者看到的只是 TLS 密文

SHA224 哈希的使用，意味着即便数据包被截获，攻击者也无法从中逆推出原始密码。

Trojan 对抗主动探测的能力

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
场景模拟：GFW 对 Trojan 服务器发起主动探测

GFW 探针（不知道密码）：
  ──TLS握手──▶ Trojan服务器（使用真实证书）
  ──GET / HTTP/1.1──▶

Trojan服务器接收到请求：
  这不是 Trojan 协议头
  → 转发给本地 Nginx
  → Nginx 返回正常网页

GFW 探针收到：
  HTTP/1.1 200 OK
  Content-Type: text/html
  [正常的网页内容]

GFW 判定：
  这是一台正常的 HTTPS 网站服务器
  放行 ✓

与此形成对比的是，在 REALITY 出现之前，大多数代理服务器在面对这种探测时会暴露明显的异常。

为了让伪装足够可信，Trojan 对部署环境有较高要求。
必须项：

  • 一个真实的域名
  • 有效的 TLS 证书（推荐 Let’s Encrypt）
  • 配置真实可访问的网站内容（Nginx/Apache）
  • 域名解析指向服务器 IP
  • 服务器开放 443 端口

Trojan-Go：社区的扩展版本

官方 Trojan 实现功能较为精简。社区开发者 p4gefau1t 推出了 Trojan-Go，在保持 Trojan 协议兼容的基础上增加了大量功能：

Trojan-Go 新增特性：

  • 传输层扩展：
    ├─ WebSocket 支持（可配合 CDN 使用）
    ├─ mux 多路复用（减少连接建立开销）
    └─ 插件系统（兼容 SIP003 混淆插件）

  • 性能优化：
    ├─ 多路复用降低延迟
    └─ 更高效的 Go 语言实现

  • 路由功能：
    └─ 内置简单的路由规则支持

Trojan-Go 的 WebSocket 模式使得 Trojan 也可以像 V2Ray 那样套 CDN 使用，进一步增强了抗封锁能力。

Trojan 与 REALITY 的对比

维度 Trojan REALITY
证书来源 自申请（需真实域名与证书） 借用知名网站（如微软/苹果）
网站可信度 依赖运维者自行维护的伪装页 直接继承顶级大厂网站的可信度
探测抵抗 良好 极强（消除 TLS 指纹特征）
部署复杂度 中等 较高
域名要求 需要持有自有域名 不需要自有域名
性能表现 良好 极佳（配合 XTLS 零拷贝）
CDN 兼容性 需要 Trojan-Go 支持 不兼容（需直接连接）

Trojan 的伪装依赖”自己建一个像样的网站”，这在 GFW 面前终究存在被识破的可能。REALITY 则从根本上消除了这个隐患——它借用的是真实的知名网站身份，连 GFW 工程师本人也无法将其与真实访问区分开来。

尽管如此，Trojan 因其部署相对简单、兼容性好、文档完善，至今仍是自建代理的重要选项之一。

Hysteria2 与 TUIC 等 UDP 协议

至此为止，我们讨论的所有协议——Shadowsocks、VMess、VLESS、Trojan、REALITY——都建立在同一个基础上：TCP。

这并非偶然。TCP 是互联网最核心的传输协议，提供可靠的、有序的字节流传输，绝大多数应用层协议都建立在它之上。对于代理协议来说，TCP 还有一个额外优势：HTTPS 流量基于 TCP，伪装成 HTTPS 需要走 TCP。

然而 TCP 有一个深层的性能缺陷，在跨国长距离传输场景下尤为突出：队头阻塞（Head-of-Line Blocking）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
TCP 队头阻塞问题：

数据被拆分为多个数据包：[包1][包2][包3][包4]...

正常情况：
  包1 ✓ → 包2 ✓ → 包3 ✓ → 包4 ✓ → 数据完整

丢包情况：
  包1 ✓ → 包2 ✗（丢失） → 包3 到达但必须等待 → 包4 到达但必须等待
                ↓
         TCP 停下来等待包2的重传
         即便包3、包4已经到达，也无法被上层使用
                ↓
         跨国线路丢包率：2-10%
         丢一个包 = 整个流的短暂停顿
         = 视频卡顿、网页加载迟滞

跨国线路的丢包率和延迟远高于国内网络，TCP 的这一特性在代理场景下被无限放大，成为制约速度体验的核心瓶颈。

QUIC：为解决 TCP 问题而生的协议

QUIC 最初由 Google 开发，2021 年成为 IETF 标准（RFC 9000），并成为 HTTP/3 的底层传输协议。

QUIC 在 UDP 之上重新实现了可靠传输，同时从设计上规避了 TCP 的队头阻塞问题：

TCP vs QUIC 传输协议差异：

维度 TCP QUIC (基于 UDP)
传输可靠性 操作系统内核保证 应用层（如协议栈本身）自行实现
队头阻塞 存在（单流阻塞影响全局） 无（多流独立，互不影响）
连接建立 1-3 RTT 0-1 RTT
多路复用 TCP 层面不支持，需 HTTP 层解决 原生支持真正的流级别多路复用
连接迁移 不支持（IP变动需重连） 支持（通过 Connection ID 识别，不断线）
加密方式 可选（额外叠加 TLS） 强制（原生内置 TLS 1.3） 
1
2
3
4
5
QUIC 多流示意：

  流1: [视频数据] ──▶ 流1丢包只影响流1，其他流照常传输
  流2: [图片数据] ──▶ 
  流3: [API请求] ──▶

QUIC 的这些特性，使其天然适合高丢包、高延迟的跨国网络环境。

Hysteria2：激进的带宽利用

Hysteria 项目由开发者 tobyxdd 创建，2023 年发布的 Hysteria2 是目前最受关注的基于 QUIC 的代理协议之一。

Hysteria2 的核心创新不在于混淆或伪装，而在于一个大胆的工程决策：使用激进的拥塞控制算法，主动”抢占”带宽。

标准拥塞控制的保守性

1
2
3
4
5
6
标准 TCP/QUIC 拥塞控制（BBR/CUBIC）：

慢启动 → 探测瓶颈 → 遇到拥塞信号 → 降速 → 重新探测

设计目标：与其他流量"友好共存"，不独占带宽
问题：在跨国专线场景下过于保守，大量可用带宽被浪费

image.png

Hysteria2 的 BBR 魔改版

Hysteria2 使用了一个经过特别调优的拥塞控制算法，其核心思想是：

Hysteria2 的带宽策略：

  • 用户配置：
    upload: 50 mbps ← 告知 Hysteria2 本地上行带宽
    download: 200 mbps ← 告知 Hysteria2 本地下行带宽

  • Hysteria2 行为：
    以接近配置上限的速率持续发送数据
    将丢包视为”网络噪声”而非”拥塞信号”
    轻微丢包时不降速，继续保持高发送率

  • 效果：
    在高丢包跨国线路上，速度是标准协议的数倍
    “暴力”利用可用带宽

这种策略在专线或高质量 VPS 上效果惊人，实测下载速度可达数百 Mbps；但在与他人共享的网络环境中，可能造成对其他流量的挤占。

流量伪装：QUIC 伪装为 HTTP/3

Hysteria2 的传输层基于 QUIC，并将流量伪装为合法的 HTTP/3 流量：

Hysteria2 流量外观：

  • 外部观察者看到：
    UDP 流量，目标端口 443
    QUIC 握手（包含 TLS 1.3）
    SNI 字段：配置的域名（如 example.com）

    → 与访问 HTTP/3 网站的流量无法区分

  • GFW 的困境：
    HTTP/3 是现代 Web 标准，YouTube、Google 均已全面支持
    封锁 QUIC/UDP 443 = 影响大量正常 HTTP/3 流量
    且 GFW 对 UDP 流量的统计分析模型尚不成熟

Hysteria2 协议格式

Hysteria2 连接建立：

  1. QUIC 握手（含 TLS 1.3，SNI 指向配置域名）

  2. 认证：
    客户端发送 HTTP/3 POST 请求到 /auth 路径
    Body 中包含密码
    服务端验证通过 → 建立代理会话

    ← 认证过程本身看起来是合法的 HTTP/3 API 请求

  3. 数据传输：
    TCP 代理：通过 QUIC 流传输
    UDP 代理：通过 QUIC 数据报传输

TUIC：优雅的低延迟设计

TUIC（Delicately-TUICed） 由开发者 EAimTY 设计，同样基于 QUIC，但设计目标与 Hysteria2 有所不同——极致的低延迟。

0-RTT 代理建立

传统代理的连接建立开销：

  • SOCKS5 代理：
    客户端 → 服务端：握手请求
    客户端 ← 服务端：握手响应
    客户端 → 服务端：认证
    客户端 ← 服务端：认证响应
    客户端 → 服务端：CONNECT 目标地址
    客户端 ← 服务端：连接成功
    客户端 → 服务端：实际数据 ← 6 次往返后才开始传数据

  • TUIC 的优化：
    利用 QUIC 的 0-RTT 特性
    将认证信息和第一个数据包合并发送
    服务端验证的同时即开始建立目标连接
    延迟敏感型应用（游戏、实时通话）体验提升显著

QUIC 多路复用的充分利用

TUIC 的连接复用模型：

  • 单个 QUIC 连接
    ├── Stream 1：TCP 代理（浏览器标签1）
    ├── Stream 2：TCP 代理（浏览器标签2）
    ├── Stream 3：TCP 代理（视频流）
    ├── Datagram：UDP 代理（DNS / 游戏流量）
    └── …（理论上无限流）

对比传统 TCP 代理：

  • Shadowsocks / Trojan（TCP）：
    每个目标连接 = 一个独立的 TCP 连接
    100 个浏览器请求 = 100 个 TCP 连接
    连接建立开销 × 100

  • TUIC：
    所有请求复用同一个 QUIC 连接
    新请求：直接开新 Stream，无需握手
    连接建立开销 ≈ 0（复用已有连接）

Hysteria2 与 TUIC 的定位差异

维度 Hysteria2 TUIC
核心目标 最大化吞吐量（暴力发包） 最小化延迟（低延迟传输）
拥塞控制 激进（魔改版 BBR） 标准 BBR
适用场景 大文件下载、高清流媒体 网页浏览、网络游戏、实时通话
弱网表现 极佳（强力抗丢包） 良好
带宽策略 主动抢占（较自私） 友好共存
协议伪装 伪装为 HTTP/3 标准流量 QUIC + TLS 封装
实现复杂度 中等 较高

UDP 代理：被长期忽视的需求

基于 QUIC 的协议还解决了一个长期困扰代理用户的痛点： UDP 流量的代理。

这使得 Hysteria2 和 TUIC 在游戏加速、VoIP 等场景下，体验远优于传统基于 TCP 的代理协议。

NaïveProxy

所有此前讨论的协议，都在尝试回答同一个问题： 如何让代理流量看起来像正常流量？

NaïveProxy 的作者 klzgrad 提出了一个更尖锐的追问：

“正常流量”究竟是什么样的？谁的实现是最权威的标准？

答案显而易见： 浏览器本身。Chrome 浏览器发出的 HTTP/2 请求，就是”正常的 HTTP/2 流量”最权威的参考实现。任何模仿它的代理协议，都只是在画虎——而 NaïveProxy 选择直接 使用老虎本身。

核心思路：复用 Chromium 网络栈

NaïveProxy 的实现建立在一个激进的工程决策上： 直接将 Chromium 的网络栈编译进代理客户端。

  • 传统代理客户端：
    自行实现 TLS 握手
    自行构造 HTTP 请求头
    自行管理连接池
    → 实现与真实浏览器存在细微差异
    → 这些差异在统计层面可被检测

  • NaïveProxy 客户端：
    直接使用 Chromium 的 net/ 模块
    → TLS 指纹 = 真实 Chrome 的 TLS 指纹
    → HTTP/2 帧结构 = 真实 Chrome 的帧结构
    → 连接行为 = 真实 Chrome 的连接行为
    → 在任何维度上与真实 Chrome 无法区分

这不是”模仿”，这是”就是”。

传输协议：HTTP/2 CONNECT 代理

NaïveProxy 使用的传输机制是 HTTP/2 的 CONNECT 方法——这是一个完全合法的、被广泛使用的代理协议，最初设计用于让 HTTP 代理支持 HTTPS 流量：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
HTTP/2 CONNECT 代理工作原理：

客户端 ──▶ 代理服务器：
  CONNECT www.google.com:443 HTTP/2
  Authorization: Basic [认证信息]

代理服务器 ──▶ 客户端：
  200 Connection Established

此后：
  客户端 ◀──▶ 代理服务器 ◀──▶ www.google.com
  代理服务器透明转发数据，不解析内容

整个过程：
  外层：TLS 1.3（客户端到代理服务器）
  内层：CONNECT 隧道（透明转发）
  
  与企业网络中员工通过公司代理访问外网：完全相同

HTTP/2 CONNECT 是企业网络环境中极为常见的合法操作，GFW 即便检测到，也难以区分这是合法的企业代理使用还是翻墙行为。

流量特征的彻底消除

NaïveProxy 在流量特征层面的”无懈可击”体现在多个维度：

TLS 指纹（JA3/JA3S）

TLS ClientHello 中的可指纹化字段：

  • 支持的 TLS 版本列表
  • 支持的加密套件列表（顺序很重要）
  • 支持的扩展列表（顺序很重要）
  • 支持的椭圆曲线列表
  • 支持的签名算法列表
  • …

不同 TLS 库的指纹：

  • OpenSSL（大多数代理使用）：指纹 A
  • BoringSSL（Chrome使用）： 指纹 B ← NaïveProxy 使用这个
  • Go crypto/tls： 指纹 C
  • NSS（Firefox使用）： 指纹 D

GFW 可以建立指纹数据库：
“指纹A 的流量 → 大概率是基于OpenSSL的代理工具”
“指纹B 的流量 → 这就是 Chrome”

NaïveProxy 因为直接使用 BoringSSL（Chrome 使用的 TLS 库），其 TLS 指纹与真实 Chrome 完全一致，无法通过指纹识别。

HTTP/2 帧行为

HTTP/2 协议中的可指纹化行为：

  • SETTINGS 帧的参数选择
  • WINDOW_UPDATE 帧的发送时机
  • HEADERS 帧中头字段的顺序
  • HPACK 头部压缩的实现细节
  • 连接预热（connection coalescing）行为
  • 流优先级的设置方式

这些细节的组合，形成了独特的”HTTP/2 指纹”
不同的实现库，指纹各不相同

NaïveProxy：

  • 所有这些行为均来自 Chromium 源码
  • 指纹 = 真实 Chrome 的 HTTP/2 指纹
  • 无从区分

填充对抗流量分析

NaïveProxy 还实现了一个细节优化，用于对抗基于包大小的流量分析：

流量分析攻击原理：

  • 代理流量的包大小分布往往有规律
  • 例如：固定大小的协议头 + 数据
    → 通过统计包大小分布，可以识别代理流量

NaïveProxy 的对策：

  • 在 HTTP/2 DATA 帧中随机添加 Padding
  • Padding 长度随机（0~255 字节）
  • 使包大小分布随机化 → 包大小分析失效

服务端：Caddy + forwardproxy 插件

NaïveProxy 的服务端基于 Caddy（一个现代 HTTP 服务器），配合 forwardproxy 插件实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
NaïveProxy 服务端架构：

                    互联网
                      │
              ┌───────▼────────┐
              │  Caddy Server  │
              │                │
              │  ┌──────────┐  │
              │  │ 正常网站 │   │  ← 真实的网页内容
              │  │ 内容托管 │   │
              │  └──────────┘  │
              │                │
              │  ┌──────────┐  │
              │  │forward   │  │  ← NaïveProxy 代理功能
              │  │proxy插件 │  │
              │  └──────────┘  │
              └───────┬────────┘
                      │
         ┌────────────┴────────────┐
         │                         │
   合法 HTTP 请求            NaïveProxy 请求
   → 返回网站内容            → 建立 CONNECT 隧道
                              → 代理流量

与 Trojan 类似，服务端对非法请求会返回真实的网站内容，对合法的 NaïveProxy 客户端则提供代理服务。

NaïveProxy 的代价

没有任何方案是完美的：

NaïveProxy 的局限性：

  • 编译复杂度：
    Chromium 代码库体积约 30GB+
    完整编译耗时数小时
    普通开发者难以自行编译修改
    → 高度依赖官方预编译版本

  • 客户端体积：
    包含精简版 Chromium 网络栈
    二进制文件体积较大（相比 Shadowsocks 等）

  • 协议限制：
    仅支持 TCP 代理（HTTP/2 CONNECT 的限制）
    UDP 代理支持有限
    → 游戏、DNS-over-UDP 等场景需要其他方案配合

  • 生态整合：
    目前主流客户端（如 sing-box）已支持 NaïveProxy
    但配置相对复杂

与其他协议的横向定位

1
2
3
4
5
6
7
8
9
10
11
12
13
14
各协议的核心差异化竞争力：

Shadowsocks    → 轻量、简单、生态成熟
VLESS + REALITY → 性能极佳 + 极强抗主动探测
Trojan         → 部署简单 + 良好的伪装
Hysteria2      → 弱网环境下的极致速度
TUIC           → 低延迟 + 完善的 UDP 支持
NaïveProxy     → 流量特征层面的终极伪装

它们并非竞争关系，而是针对不同场景的不同工具：
  追求极致速度      → Hysteria2
  追求极致安全      → REALITY
  追求流量无法识别  → NaïveProxy
  追求简单易用      → Shadowsocks / Trojan

客户端与内核生态

代理工具的演进，不只发生在协议层面，同样深刻地发生在客户端软件层面。

早期的代理客户端与协议是强绑定的：用 Shadowsocks 就装 Shadowsocks 客户端，用 V2Ray 就装 V2Ray 客户端。每换一个协议，就要换一套工具，配置从头来过。

这个局面随着 Clash 的出现而彻底改变。

Clash：规则路由的革命

Clash 由开发者 Dreamacro 于 2019 年发布，它的核心创新不在于协议，而在于统一的规则路由引擎：

Clash 的设计理念：

  • 统一接入层：
    支持多种代理协议（SS / VMess / Trojan / …）
    作为本地 HTTP / SOCKS5 代理暴露给系统

  • 规则引擎：
    每个网络请求 → 匹配规则列表 → 分配出口

  • 规则类型：
    DOMAIN-SUFFIX, google.com, 代理节点A
    DOMAIN-KEYWORD, youtube, 代理节点B
    IP-CIDR, 192.168.0.0/16, 直连
    GEOIP, CN, 直连
    PROCESS-NAME, WeChat.exe, 直连
    MATCH, 代理节点A ← 默认规则

  • 节点组（Proxy Group）：
    url-test：自动选择延迟最低的节点
    fallback：主节点不可用时自动切换
    load-balance：多节点负载均衡
    select：手动选择

Clash 将”选哪个节点”和”什么流量走代理”这两个问题，从协议实现中完全剥离，交给用户通过配置文件灵活定义。这种设计极大降低了使用门槛，也催生了繁荣的订阅链接生态——用户只需导入一个链接，即可获得完整的节点列表和分流规则。

图形界面客户端

Clash 的核心是一个命令行程序（clash-core，Clash.Meta-现已更名为Mihomo），在此之上，社区开发出了大量图形界面客户端。

2023年，包括 Clash for Windows、Clash for Android 在内的多个主要客户端作者相继删库，是这一年代理生态最动荡的事件。社区在短暂混乱后迅速分叉出多个替代项目，整体生态并未中断。

Clash.Meta / Mihomo：功能的进一步扩展

Clash.Meta（现已更名为 Mihomo）是 Clash 的社区增强分支，在原版 Clash 的基础上增加了大量协议支持和功能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Mihomo 相较原版 Clash 的扩展：

新增协议支持：
  ✓ VLESS + XTLS / REALITY
  ✓ Hysteria / Hysteria2
  ✓ TUIC
  ✓ WireGuard（出站）
  ✓ AnyTLS

新增功能：
  ✓ 规则集（Rule-Set）── 支持大型规则文件的高效加载
  ✓ Sub-Rule          ── 嵌套规则匹配
  ✓ 地理数据库更新     ── 自动更新 GeoIP/GeoSite 数据
  ✓ 策略组增强         ── 更丰富的负载均衡策略
  ✓ DNS 增强模式       ── 防 DNS 泄漏，支持 DoH/DoT/DoQ

sing-box：下一代通用代理内核

sing-box 由开发者 nekohasekai 于 2022 年发布，被定位为”通用代理平台“，目标是成为下一代的代理内核标准。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
sing-box 的架构设计：

┌─────────────────────────────────────────────┐
│                  sing-box                   │
├─────────────────────────────────────────────┤
│  入站（Inbound）                             │
│  HTTP / SOCKS / Tun / Redirect / TProxy ... │
├─────────────────────────────────────────────┤
│  路由（Router）                              │
│  规则匹配 → 出口选择                          │
├─────────────────────────────────────────────┤
│  出站（Outbound）                            │
│  几乎所有主流协议：                           │
│  SS / VMess / VLESS / Trojan / REALITY      │
│  Hysteria2 / TUIC / NaïveProxy / WireGuard  │
│  SSH / SOCKS / HTTP / ...                   │
└─────────────────────────────────────────────┘

sing-box 的技术亮点：

TUN 模式（虚拟网卡接管）：

  • 传统代理模式：
    应用程序 → 主动设置代理 → 流量走代理
    问题：不支持代理的应用（游戏/部分系统流量）无法代理

  • TUN 模式：
    sing-box 创建虚拟网卡 tun0
    系统路由表：所有流量 → tun0
    sing-box 接管 tun0 的所有流量
    → 无需应用主动设置代理
    → 系统级全流量代理
    → 真正的”透明代理”

更进一步：

  • FakeIP 模式
    DNS 查询返回假 IP（198.18.0.0/15 段）
    sing-box 记录 假IP → 真实域名 的映射
    连接建立时，根据假IP还原真实域名
    → 避免 DNS 泄漏
    → 支持基于域名的精确路由

订阅生态与规则集

客户端生态的成熟，催生了完整的订阅与规则生态系统：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
订阅生态链条：

节点提供方（机场）
  ↓ 提供订阅链接
用户客户端（Mihomo / sing-box）
  ↓ 解析节点列表
路由规则集（社区维护）
  ↓ 定义分流逻辑

主要规则集项目：
  Loyalsoldier/geoip
  ACL4SSR/ACL4SSR
  Loyalsoldier/clash-rules
  blackmatrix7/ios_rule_script
  MetaCubeX/meta-rules-dat

规则集内容示例：
  广告拦截列表    ── 过滤广告域名
  流媒体规则      ── Netflix/Spotify 走特定解锁节点
  AI 服务规则     ── ChatGPT/Gemini 走美国节点
  游戏加速规则    ── Steam/Epic 走低延迟节点
  中国大陆直连    ── 国内域名/IP 不走代理

路由器级别的透明代理

对于追求极致体验的用户，在路由器上部署代理内核可以实现家庭网络全局透明代理 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
家庭网络透明代理方案：

                        互联网
                          │
                    ┌─────▼──────┐
                    │  光猫/调制  │
                    │  解调器     │
                    └─────┬──────┘
                          │
                    ┌─────▼──────┐
                    │  软路由     │
                    │ sing-box   │  ← 代理内核运行在此
                    │ （TProxy） │
                    └─────┬──────┘
                          │
          ┌───────────────┼───────────────┐
          │               │               │
    ┌─────▼──┐      ┌─────▼──┐     ┌─────▼──┐
    │ 电脑   │      │ 手机    │     │ 电视   │
    │（无需  │      │（无需   │     │（无需   │
    │ 配置） │      │ 配置）  │     │ 配置）  │
    └────────┘      └────────┘     └────────┘

所有设备自动享受代理，无需单独配置
包括：智能音箱、游戏机、IoT 设备…

从最初需要敲命令行才能使用的 Python 脚本，到如今一键导入订阅即可使用、自动选择最优节点、精确分流的现代客户端——代理工具的易用性提升，与协议的技术进步同样重要。

它降低了信息获取的门槛，让这项技术真正走入了普通用户的日常生活。

结语

一场从未结束的对话

回望这二十余年的技术演进，从最初简陋的 HTTP 代理，到如今几乎无懈可击的 REALITY 协议；从需要在命令行里敲一串参数才能勉强运行的 Python 脚本，到如今一键导入订阅、自动选优的现代客户端——这场博弈的每一个回合，都在客观上推动着网络技术向前演进。

但如果仅仅将这段历史读作一场”技术军备竞赛”，未免失之浅薄。

技术从来不是在真空中演进的。每一个协议背后，都站着真实的人：

  • clowwindy，一个厌倦了难用工具的程序员，用业余时间写出了影响数亿人的代码，最终在警察登门后沉默离场；
  • breakwa11，在社区争议与人肉搜索的双重压力下，删库消失于互联网；
  • Victoria Raymond，神秘的 V2Ray 创始人，从未公开过真实身份，某天停止了更新，再无消息；
  • rprx，XTLS 和 REALITY 的设计者，因与主项目的代码审查争议而分叉，反而推动了更激进的技术创新；
  • 还有无数没有留下名字的贡献者，他们提交的每一个 PR、每一份文档、每一条 issue，共同构成了这个生态的血肉。

这些人有一个共同点：他们中的大多数，从这些工作中获得的物质回报几乎为零。驱动他们的，是某种更难以名状的东西。

开源精神的胜利

这段历史中最值得记录的，或许不是哪个协议更难以识别，而是开源作为一种组织方式所展现出的惊人韧性。

Shadowsocks 的故事尤其典型。clowwindy 删除代码的那一刻，Shadowsocks 作为一个”项目”死去了；但作为一个”协议”和”思想”，它从未死去。shadowsocks-libev、shadowsocks-rust、shadowsocks-windows……社区的分支比原版活得更久，也更繁荣。

开源不只是一种软件开发模式，在这个特定的语境下，它是一种去中心化的抗脆弱机制——没有单点，没有首领，没有可以被摧毁的中心节点。这与 Tor 的洋葱路由在设计哲学上有着深刻的呼应：真正难以被消灭的系统，是那些没有核心的系统。

从另一个角度看，GFW 是一面意外清晰的技术镜子。

它的每一次升级，都精确地标记了当时反审查技术的薄弱之处：主动探测的出现，说明流量混淆已经达到了让被动检测失效的水平；机器学习分类的引入，说明基于规则的特征匹配已经无法胜任；对 QUIC 流量的谨慎处理，说明统计分析模型在面对新协议时确实存在盲区。

GFW 的工程师们，在某种意义上，是反审查技术最严苛的”同行评审者”。每一个在 GFW 面前存活下来的协议设计，都经过了最残酷的实战检验。这解释了为什么代理领域的协议设计，在某些技术维度上走在了整个网络安全行业的前面——没有任何实验室能够模拟这种量级的对抗压力。

写作本文时，这场博弈仍在进行：

REALITY 协议让主动探测几乎无从下手，但流量统计分析的精度仍在提升；Hysteria2 在弱网环境下速度惊人，但激进的带宽占用策略本身就是一种可识别的行为特征。

ECH（Encrypted Client Hello）的推进，有望从根本上消除 SNI 嗅探这一手段；后量子密码学的标准化，将在未来某个时间点重塑整个 TLS 体系的安全假设；AI 生成流量的出现，或许会让”流量指纹”这一概念本身变得难以为继。

没有人知道下一个回合会在哪里发生，也没有人知道谁会率先打破当前的均衡。

但有一件事是确定的：只要信息流动的需求存在，技术创新就不会停歇。

相关链接

[视频] 盘点翻墙常见协议和内核 | 与中国防火墙的战争
中国的防火长城是如何检测和封锁完全加密流量的
Shadowsocks 协议
V2Fly 社区文档
VMess 协议
Trojan 协议
Hysteria2 协议
TUIC 协议
NaïveProxy 协议
XTLS/REALITY 协议
QUIC 传输协议（RFC 9000）
HTTP/3（RFC 9114）
TLS 1.3（RFC 8446）
SOCKS5 协议（RFC 1928）
An Analysis of China’s “Great Cannon”