【GFW对抗史·第三章】百花齐放——从Xray到Sing-box的新纪元 🌌

作者： GLM4.6
时间： 2025年2月
字数： 约12000字
阅读时间： 45分钟

当一棵大树倒下，阳光洒在林地上，无数新芽便开始疯长。2020年后的翻墙世界，是一部关于分裂、创新与重建的史诗。

🌟 引子：一场关于自由的分裂

如果说第二章的故事是V2Ray一统江湖后的内部分化，那么第三章将是一部更加波澜壮阔的史诗：协议的军备竞赛、内核的王朝更替、客户端生态的一夜崩塌与浴火重生。

在这一章里，你将看到：

• 一个天才开发者因为一行License与整个社区决裂，然后独自创造了可能是人类反审查史上最强大的协议——REALITY
• 一个后来者如何在废墟上建起新的秩序，成为当之无愧的下一代内核之王——Sing-box
• QUIC、Chrome网络栈、零拷贝内核调用这些底层技术，如何被改造成穿透GFW的利刃

准备好了吗？让我们从那场著名的”分裂”讲起。

📜 3.1 Xray：从分裂到革命

3.1.1 故事的起因：XTLS与License之争

时间线：2020年秋天

V2Ray的创始人Victoria Raymond早已消失，社区分叉出的V2Fly勉强维持着v2ray-core的更新。在这个时期，一位核心贡献者RPRX提出了一个极其大胆的想法：

“TLS之上再套一层TLS，是巨大的性能浪费和特征暴露。我们能不能直接把内层的TLS和外层的TLS拼接起来？”

这个想法的产物就是XTLS（Xray Transport Layer Security）。

RPRX将XTLS的代码提交到了V2Fly的仓库中。但问题来了——License（开源许可证）。

V2Fly的其他维护者认为，仓库中的所有代码应当统一使用MIT，要求RPRX更换许可证。RPRX拒绝了。

谁对谁错，社区至今仍有争论。但结果是确定的：

2020年11月，RPRX将XTLS的代码从V2Fly中移除，并Fork了整个v2ray-core，创建了一个全新的项目——Xray-core。

从这一刻起，翻墙世界正式进入了V2Fly与Xray双线并行的时代。而后来的故事证明，Xray这条线，走得远得多。

3.1.2 VLESS：为XTLS而生的精简协议

在讨论XTLS之前，我们先要理解VLESS——它是XTLS的”载体”。

回顾第二章，VMess协议虽然功能强大，但有几个痛点：

RPRX的解决方案是：直接砍掉VMess自带的加密层。

VLESS的设计哲学是：

“我只负责身份验证和数据传递。加密的事情，交给外面的TLS来做。”

1
2
3
4
5
6
7
8
9
10
11

VMess 的数据包结构（简化）：
┌─────────────────────────────────────────────────────────────┐
│ VMess Header │ VMess加密层(AES/ChaCha20) │ 实际数据        │
│  (认证+参数)  │     ↑ 如果外面还有TLS，就是双重加密          │
└─────────────────────────────────────────────────────────────┘

VLESS 的数据包结构（简化）：
┌─────────────────────────────────────────────────────────────┐
│ VLESS Header │ 实际数据（明文传递给外层TLS加密）            │
│ (版本+UUID)  │     ↑ 只加密一次                              │
└─────────────────────────────────────────────────────────────┘

VLESS的Header极其简洁：

• 1字节：协议版本（目前固定为0）
• 16字节：UUID（唯一标识，用于认证）
• 附加数据长度 + 附加数据：可选
• 然后直接就是原始数据流

没有时间戳，没有内置加密，没有复杂的指令字段。

这不是偷懒，这是有意为之。 因为RPRX的终极目标不是VLESS本身——而是让VLESS成为XTLS的完美载体。

三维评价：VLESS（单独使用，无XTLS/REALITY）

3.1.3 XTLS：零拷贝的性能革命

双重加密的罪与罚

为了理解XTLS为什么是天才设计，我们必须先理解一个问题：当你通过翻墙代理访问一个HTTPS网站时，数据到底被加密了几次？

假设你要访问https://www.google.com：

1
2
3
4
5
6
7
8
9
10
11
12

sequenceDiagram
    participant B as 你的浏览器
    participant C as 代理客户端
    participant G as GFW
    participant S as 代理服务端
    participant T as Google

    B->>C: HTTPS数据(已加密)
    Note over C: 代理协议再加密一次
    C->>G: 密文中的密文
    G->>S: 密文中的密文
    S->>T: 解开代理层，转发内层TLS数据

看到了吗？数据在传输过程中实际上被加密了两次：

1. 内层TLS：浏览器和Google之间的TLS连接，数据已经被加密成密文A
2. 外层代理加密：代理客户端把密文A再用代理协议的加密包裹一次，变成密文B

在代理服务端，它需要：

1. 先解开外层加密（拿到密文A）
2. 把密文A原样转发给Google（因为服务端没有Google的私钥，它解不开内层TLS）

重点来了：服务端解开外层加密后，拿到的仍然是TLS密文。它要做的只是原样转发。但是在传统代理中，这个”原样转发”之前，数据被毫无意义地多加密了一次、多解密了一次。

RPRX的核心洞察：既然你访问的目标网站本身就是HTTPS（这在2020年代已经是绝大多数网站的情况），那么外层的加密就是多余的。能不能检测到内层已经是TLS加密了，然后直接把内层的TLS数据”透传”出去？

XTLS的工作原理

XTLS的做法，用一句话概括就是：

在TLS握手完成后，识别出内层的TLS数据流，然后直接将外层TLS”脱壳”，让内层TLS裸奔在TCP连接上。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

[阶段一：TLS握手]
客户端和服务端建立正常的外层TLS连接，交换密钥。
这个阶段和普通的HTTPS连接完全一样。

[阶段二：代理握手]
在TLS隧道内，客户端发送VLESS头部（UUID认证 + 目标地址）。
服务端验证UUID，建立到目标网站的连接。

[阶段三：XTLS魔法开始]
客户端的浏览器开始和目标网站进行TLS握手。
XTLS客户端会「嗅探」经过的数据。当它检测到：
  - 内层TLS握手已完成
  - 后续数据已经是TLS Application Data（密文）

此时，XTLS做了一件惊人的事：
  → 停止外层TLS加密
  → 后续的内层TLS数据直接在TCP连接上传输（即"拼接/Splice"）

1
2
3
4
5
6
7

传统代理的数据流：
内层TLS密文 → [外层TLS加密] → 发送 → [外层TLS解密] → 内层TLS密文 → 转发
CPU消耗：     ████████████         ████████████

XTLS的数据流（握手后）：
内层TLS密文 → [直接发送，不再加密] → 内层TLS密文 → 直接转发
CPU消耗：     ░░(几乎为零)░░         ░░(几乎为零)░░

XTLS的三个版本

XTLS经历了三个重要版本的演进：

XTLS-Vision的关键改进：

Vision不再简单粗暴地”脱壳”，而是在内层TLS握手完成后，继续维持外层的TLS Record封装，对Application Data进行特殊处理：

1. 将内层TLS数据填充到看起来像正常HTTPS流量的包长分布
2. 保持外层TLS Record的结构完整性
3. 在数据传输的尾部阶段，逐渐过渡到直接转发模式

这样，从GFW的角度看，这就是一个完全正常的、从头到尾结构一致的TLS连接。

三维评价：VLESS + XTLS-Vision

🔐 3.2 REALITY：隐蔽性的终极形态

3.2.1 传统TLS伪装的阿喀琉斯之踵

在REALITY出现之前，所有基于TLS的翻墙协议（Trojan、VLESS+TLS、VMess+TLS）都面临同一个根本性问题：

你得有一个域名，还得有这个域名对应的TLS证书。

这意味着：

1. 你的服务器IP绑定了一个域名（比如my-proxy.example.com）
2. 你为这个域名申请了Let’s Encrypt证书
3. 你在服务器上配了一个伪装网站

看起来没问题？但GFW可以做以下事情：

主动探测（Active Probing）：

1
2
3
4
5
6
7
8
9
10
11

GFW探测器: "我来连一下这个IP的443端口，看看它到底是什么。"
GFW探测器: → TLS ClientHello (SNI: my-proxy.example.com)
你的服务器: ← TLS ServerHello + 证书 (Let's Encrypt证书)
GFW探测器: → HTTP GET /
你的服务器: ← 200 OK, 一个简陋的 "Hello World" 页面

GFW判定: "这个IP是某个国外VPS提供商的。
         绑定的域名几乎没有任何流量。
         网站内容只有一个空白页面。
         但这个IP却有大量来自中国的TLS连接。
         → 高度可疑，加入观察名单 / 直接封禁IP。"

这就是为什么即使你的Trojan协议做到了和HTTPS流量完全一致，GFW仍然可以通过域名信誉度 + 流量模式分析来判定你的服务器。

3.2.2 REALITY的核心思想：偷天换日

RPRX在2023年初正式发布了REALITY协议。 它的核心思想只有一句话：

“我不需要自己的域名和证书。我让GFW以为我就是www.microsoft.com（或任何一个大型网站）。”

这听起来像是天方夜谭？让我们看看它是怎么做到的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

sequenceDiagram
    participant C as 客户端
    participant S as 你的服务器
    participant M as microsoft.com
    participant G as GFW

    C->>S: TLS ClientHello (SNI: www.microsoft.com)
    S->>M: 转发 ClientHello
    M->>S: ServerHello + 微软真证书
    S->>C: 转发 ServerHello + 微软真证书
    Note over G: GFW看到：客户端在和微软服务器握手<br/>证书是微软的真实证书<br/>看起来完全合法！
    
    Note over C,S: 但客户端和服务器之间有预共享密钥<br/>在TLS握手的特定字段中暗藏
    C->>S: 用预共享密钥派生的密钥加密<br/>真正的代理数据开始传输

关键技术细节

1. 服务器证书从哪来？

REALITY服务端在收到客户端的ClientHello后，会像一个反向代理一样，把这个ClientHello转发给一个预设的**”目标网站”（比如www.microsoft.com）。目标网站返回的真实证书和ServerHello，被服务端原样转发**给客户端。

所以GFW如果截获了这个TLS握手，它看到的证书是微软的真实证书，完全合法。

2. 客户端怎么知道这不是真的微软？

这就是预共享密钥的作用。REALITY客户端在配置时就已经拥有了服务端的公钥。在TLS握手过程中，通过巧妙利用TLS扩展字段，客户端和服务端完成了一次独立于目标网站的密钥交换。

简单来说：

• 从GFW的视角：这是一次标准的客户端 ↔ www.microsoft.com的TLS连接
• 从客户端和服务端的视角：TLS握手借用了微软的证书做”门面”，但实际的加密通道是用预共享密钥建立的

3. 如果GFW自己来连你的服务器呢？（主动探测防御）

这是REALITY最精妙的设计之一：

1
2
3
4
5

GFW探测器: → TLS ClientHello (SNI: www.microsoft.com)
你的服务器: 检查 → 这个ClientHello中没有合法的预共享密钥
你的服务器: → 直接将整个TLS连接透传给真正的www.microsoft.com
GFW探测器: ← 收到了www.microsoft.com的真实响应
GFW探测器: "嗯，这就是一个正常的微软服务器/CDN节点，没有异常。"

换句话说：对于没有正确密钥的访问者，你的服务器就是一个彻头彻尾的微软（或任何目标网站的）反向代理。它返回的内容、证书、TLS指纹，全部是真实的。

3.2.3 REALITY的配置要素

一个典型的REALITY配置包含以下关键字段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "protocol": "vless",
  "settings": {
    "clients": [
      {
        "id": "你的UUID",
        "flow": "xtls-rprx-vision"
      }
    ]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "dest": "www.microsoft.com:443",
      "serverNames": ["www.microsoft.com"],
      "privateKey": "服务端私钥",
      "shortIds": ["abcdef1234"]
    }
  }
}

注意几个要点：

• 不需要域名：你的服务器可以是一个纯IP的VPS
• 不需要证书：不需要Let’s Encrypt，不需要任何证书管理
• dest（目标网站）的选择：应该选择一个大型、稳定、支持TLS 1.3和H2的网站

选择dest的最佳实践：

常见选择：www.microsoft.com、www.apple.com、gateway.icloud.com、www.samsung.com

3.2.4 REALITY对GFW的降维打击

让我们重新审视GFW的所有攻击手段，看看REALITY是如何逐一化解的：

三维评价：VLESS + REALITY

🚀 3.3 Sing-box：新一代内核之王

3.3.1 为什么需要一个新的内核？

到2022年，翻墙世界已经有了多个内核：

这时候，一个新项目悄然崛起——Sing-box。

Sing-box由开发者SagerNet创建，它的设计理念是：

“用现代Go语言的最佳实践，从零开始构建一个高性能、模块化、易扩展的代理内核。”

3.3.2 Sing-box的核心优势

1. 架构设计

Sing-box采用了完全模块化的架构：

1
2
3
4
5
6
7
8
9
10
11
12
13

┌─────────────────────────────────────────────────────────────┐
│                      Sing-box 架构                          │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐       │
│  │  Route  │  │  DNS    │  │  Inbound│  │ Outbound│       │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘       │
│       │            │            │            │             │
│       └────────────┴────────────┴────────────┘             │
│                          │                                  │
│                    ┌─────┴─────┐                           │
│                    │  Context  │                           │
│                    └───────────┘                           │
└─────────────────────────────────────────────────────────────┘

每个模块都可以独立配置、独立测试、独立更新。这带来了几个好处：

• 易于调试：问题可以快速定位到具体模块
• 易于扩展：添加新协议只需实现对应的接口
• 易于维护：代码结构清晰，新人容易上手

2. 性能优化

Sing-box在性能上做了大量优化：

3. 协议支持

Sing-box支持的协议列表（2025年）：

关键点：Sing-box是第一个原生支持REALITY的内核（甚至早于Xray官方）。

3.3.3 Sing-box vs Xray：全面对比

结论：2024年后，Sing-box已经成为社区推荐的首选内核。

🌸 3.4 百花齐放：新协议的崛起

3.4.1 Hysteria2：QUIC的速度革命

背景：为什么需要基于QUIC的协议？

TCP有一个致命问题：队头阻塞（Head-of-Line Blocking）。

当你在TCP连接上传输多个请求时，如果一个数据包丢失，后续所有数据包都要等待它重传。这在翻墙场景下尤其致命——GFW会故意丢包来干扰连接。

QUIC（Quick UDP Internet Connections）是Google开发的传输协议，它解决了这个问题：

• 基于UDP，避免TCP的队头阻塞
• 内置加密（TLS 1.3）
• 支持多路复用
• 快速连接迁移

Hysteria2的工作原理：

Hysteria2是基于QUIC的代理协议，它的核心特点是Brutal模式：

1
2
3
4
5
6
7
8
9

传统拥塞控制（BBR/Cubic）：
  根据网络状况动态调整发送速率
  优点：公平，不会抢占过多带宽
  缺点：在丢包严重的网络下速度骤降

Hysteria2 Brutal模式：
  不管网络状况，强制以设定的速率发送
  优点：在弱网环境下速度极快
  缺点：需要用户知道自己带宽的上限

三维评价：Hysteria2

3.4.2 TUIC：优雅的QUIC实现

TUIC（Transparent UDP-based Internet Connector）是另一个基于QUIC的协议，与Hysteria2的设计理念不同：

三维评价：TUIC v5

3.4.3 NaïveProxy：Chrome网络栈的终极伪装

NaïveProxy走的是一条完全不同的路：不跟GFW玩加密花活，直接用Chrome的网络堆栈。

它直接把Chromium的网络库（cronet）打包进客户端，流量行为（HTTP/2复用、TLS参数、乱序、重传、窗口一切）与真实Chrome一模一样。

1
2
3
4
5
6
7
8
9

graph LR
    A[你的应用] --> B[NaïveProxy客户端]
    B --> C[Chrome网络栈<br/>cronet]
    C --> D[HTTPS流量]
    D --> E[GFW]
    E --> F[看起来就是<br/>正常的Chrome浏览器]
    
    style C fill:#4caf50
    style F fill:#c8e6c9

NaïveProxy的特点：

三维评价：NaïveProxy

3.4.4 ShadowTLS：Trojan的最佳搭档

ShadowTLS是一种协议伪装层，它可以套在任何代理协议外面：

1
2
3
4
5
6
7

传统Trojan：
[你的数据] → [Trojan协议] → [TLS] → 发送

Trojan + ShadowTLS v3：
[你的数据] → [Trojan协议] → [ShadowTLS伪装层] → [TLS] → 发送
                                    ↓
                          模拟真实TLS握手的时序和特征

ShadowTLS的核心价值：

• 模拟真实TLS握手的时序特征
• 对抗GFW的主动探测
• 可以与任何代理协议组合

三维评价：Trojan + ShadowTLS v3

3.4.5 Juicity：2025年的新贵

Juicity是2025年新出现的协议，它结合了QUIC和自定义混淆：

| 特点 | 说明 |
|:—|:—|:—|
| 基于QUIC | 继承QUIC的所有优点 |
| 自定义混淆 | 流量特征更难识别 |
| 快速迭代 | 社区活跃，更新频繁 |

三维评价：Juicity

📱 3.5 客户端生态：Clash的兴衰

3.5.1 Clash for Windows：一代霸主

2021-2023年，Clash for Windows（CFW） 几乎垄断了中国翻墙用户的桌面。它凭什么？

2023年11月2日，Clash for Windows从GitHub消失。

开发者没有给出任何解释，项目就这样消失了。社区猜测纷纷，但真相至今不明。

3.5.2 Clash Meta（FlClash）：浴火重生

Clash for Windows消失后，社区迅速转向了Clash Meta（后更名为FlClash）。

Clash Meta的特点：

• 基于Clash Premium内核
• 支持Sing-box的所有协议
• 规则系统更强大
• 跨平台支持

3.5.3 客户端生态现状（2025年）

🏆 3.6 2025年终排行榜

S级（神级，几乎不可能被墙）

A+级（极强，基本不会被封）

A级（还能用，但开始吃力）

已死协议（2025年完全不可用）

📊 3.7 协议演进时间线

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

timeline
    title 翻墙协议演进时间线（2020-2025）
    
    section 2020
        Xray分裂 : RPRX Fork v2ray-core
        VLESS发布 : 为XTLS而生的精简协议
        XTLS-Origin : 零拷贝概念验证
    
    section 2021
        XTLS-Splice : Linux零拷贝实现
        Clash称霸 : CFW占据90%桌面
    
    section 2022
        XTLS-Vision : 解决TLS Record断层
        Sing-box崛起 : 新一代内核诞生
        Hysteria2 : QUIC速度革命
    
    section 2023
        REALITY发布 : 隐蔽性终极形态
        CFW消失 : 11月2日从GitHub消失
        Clash Meta : 浴火重生
    
    section 2024
        Sing-box称王 : 成为社区首选内核
        TUIC v5 : 优雅的QUIC实现
        NaïveProxy普及 : Chrome指纹伪装
    
    section 2025
        Juicity : 新贵崛起
        协议成熟 : S级组合几乎无敌

🎯 总结：我们赢了，但也输了

技术层面：全面胜利

2025年的今天，我们确实拥有了历史上最强、最快、最隐蔽的翻墙协议：

现实层面：门槛提高

但我们也输了。输在这一切太复杂，太内卷，太烧钱。

一个普通用户要享受这种自由，起码要：

这已经不是技术问题，而是阶层问题。

历史意义

翻墙，从来不只是技术问题。它一直是，而且永远都会是，一场关于自由与权力的博弈。

从Shadowsocks的”让GFW看不懂”，到REALITY的”让GFW以为我是微软”，我们走过了十五年。这十五年里，无数开发者贡献了他们的智慧和汗水，让每一个普通人都有了触碰自由的可能。

这，就是技术的意义。

（第三章完）

📚 延伸阅读

• Xray官方文档
• Sing-box官方文档
• REALITY协议详解
• Hysteria2项目
• NaïveProxy项目