深度包检测（DPI）机制

位置：背景知识层 | 难度：中等 | 前置：GFW 审查机制、TLS 1.3 深入源码证据：USENIX Security '23 论文 Algorithm 1、GFW Report IMC '20、Geedge TSG 泄露文件 外部参考：USENIX Security '23 (Wu et al.)、GFW Report 系列测量研究

1. DPI 在审查体系中的位置

DPI 不是一种单一的检测技术，而是一个执行平台。它接收网络数据包，在上面运行一系列的检测规则，然后根据规则的匹配结果执行动作（放行、阻断、限速、标记）。

在 GFW 的架构中，DPI 是规则执行引擎，它承载了以下检测能力：

DPI 引擎
├── 熵检测规则     (来自 Algorithm 1 Ex1)
├── ASCII 特征规则  (来自 Algorithm 1 Ex2-Ex4)
├── 协议指纹库     (来自 Algorithm 1 Ex5)
├── SNI 过滤规则   (黑名单域名匹配)
├── TLS 指纹匹配   (JA3/JA4 规则库)
├── 包长度统计规则  (按协议分类的包大小分布)
├── 主动探测触发    (可疑流量标记后触发)
└── 动作执行       (丢弃 / RST / 限速 / 标记)

2. GFW Algorithm 1：全加密流量被动检测

2021 年 11 月，GFW 部署了新的被动检测能力，能够在不发送主动探测包、不解密任何数据的情况下，实时识别并阻断全加密协议流量（Shadowsocks、VMess、Obfs4 等）。

USENIX Security '23 论文（Wu et al.）通过大规模网络测量实验，逆向推断出了 GFW 的检测算法。实验在 2023 年 3 月仍能复现阻断行为。

2.1 核心算法

论文中的 Algorithm 1（原文引用）：

Algorithm 1: The GFW uses at least five heuristic rules to detect
and block fully encrypted traffic.

Input: the first TCP payload (pkt) sent by the client.

Allow a connection to continue if pkt satisfies ANY of:
  Ex1: popcount(pkt)/len(pkt) ≤ 3.4  or  popcount(pkt)/len(pkt) ≥ 4.6
  Ex2: The first six (or more) bytes of pkt are in [0x20, 0x7e]
  Ex3: More than 50% of pkt's bytes are in [0x20, 0x7e]
  Ex4: More than 20 contiguous bytes of pkt are in [0x20, 0x7e]
  Ex5: It matches the protocol fingerprint for TLS or HTTP

Block if NONE of the above hold.

核心设计思想：否定式检测。GFW 不定义"什么流量该被阻断"，而是定义"什么流量确定无害"——豁免所有满足条件的数据包，剩下的全部阻断。

2.2 Ex1：比特熵检测

popcount(pkt) / len(pkt)

popcount(pkt) 统计数据包中所有字节的二进制位中 1 的数量。对于一个字节 0x00 = popcount 0，0xFF = popcount 8，随机数据 ≈ popcount 4。

直观理解：

纯 ASCII 文本（如 GET /index.html）：每个字节的高位都是 0 → popcount 偏低 → 约 3.0-3.4
随机加密数据（如 AES 密文）：每个比特都是均匀随机的 → popcount ≈ 4.0
大量 0xFF 填充的数据：popcount 偏高 → > 4.6

检测逻辑：popcount/len 在 (3.4, 4.6) 范围内的数据被认为是"随机加密流量"。

各协议的 popcount/len 值：

流量类型	首个数据包内容	popcount/len	Ex1 豁免？
TLS 1.3 ClientHello	版本 + 密码套件 + SNI(ASCII) + 扩展	~3.0-3.3	是（< 3.4）
HTTP GET 请求	`GET / HTTP/1.1\r\nHost: ...`	~2.5-3.0	是（< 3.4）
Shadowsocks AEAD	Salt(16B 随机) + GCM 密文(18B 随机)	~4.0	否
VMess AEAD 头	AuthID(16B 密文) + ALength(18B 密文)	~4.0	否
REALITY ClientHello	同 TLS 1.3 ClientHello	~3.0-3.3	是（< 3.4）

2.3 Ex2-Ex4：ASCII 字符检测

ASCII 可打印字符范围是 [0x20, 0x7e]（空格到波浪号）。

Ex2 (ASCII 前缀)：前 6 个字节（及以上）全部是可打印 ASCII → 豁免。

TLS ClientHello 的前几个字节是什么？

TLS 记录头：[0x16] [0x03] [0x01/0x03] ...

0x16 = 22 → 不在 [0x20, 0x7e] 范围内
所以 TLS ClientHello 不满足 Ex2

但 TLS 通过 Ex1 和 Ex5 豁免，所以没问题。

HTTP 请求：

"GET /"  → 全是 ASCII → 满足 Ex2

Ex3 (ASCII 比例)：超过 50% 的字节是 ASCII → 豁免。

TLS ClientHello 包含 SNI（ASCII 域名）+ ALPN（ASCII）→ 通常 > 50% ASCII → 满足 Ex3
纯随机数据的 ASCII 比例 ≈ 95/256 ≈ 37% → 不满足 Ex3

Ex4 (ASCII 连续性)：存在超过 20 个连续字节全是 ASCII → 豁免。

TLS ClientHello 的 SNI 字段（如 www.microsoft.com = 19 字节）+ 其他扩展 → 通常 > 20 → 满足 Ex4
纯随机数据中连续 ASCII 的概率极低 → 不满足 Ex4

2.4 Ex5：协议指纹

GFW 维护一个已知协议指纹库。如果首个数据包的开头几个字节匹配已知协议特征，直接豁免。

已知匹配的协议指纹（来源：论文实验确认）：

TLS：首个字节 = 0x16（TLS Handshake 记录类型）
HTTP：前几个字节匹配 GET 、POST、HEAD 等方法

Ex5 的关键特性：它只检查前几个字节，所以即使后面的数据是加密的也没关系——只要开头能识别为 TLS 或 HTTP 就豁免。

2.5 各协议在 Algorithm 1 中的豁免路径

Shadowsocks AEAD:
  Ex1: popcount/len ≈ 4.0  → 不豁免
  Ex2: 首字节是随机数       → 不豁免
  Ex3: ASCII ≈ 37%          → 不豁免
  Ex4: 无连续ASCII          → 不豁免
  Ex5: 不是 TLS/HTTP        → 不豁免
  → 阻断

VMess AEAD:
  同上，所有规则都不豁免
  → 阻断

Trojan (TLS 握手后):
  Ex1: ClientHello 的 popcount/len ≈ 3.0-3.3  → 豁免 ✓
  → 通过！（但 TLS-in-TLS 的其他特征在后续被检测）

REALITY:
  Ex1: popcount/len ≈ 3.0-3.3  → 豁免 ✓
  → 通过！（且没有 TLS-in-TLS 特征）

2.6 为什么 GFW 选择"豁免"而非"匹配"策略

论文作者提出的解释：

可扩展性：新增一个已知协议的豁免规则（如 QUIC）简单，不需要更新"阻断规则库"
误伤控制：宁可漏掉一些代理流量，也不能阻断正常流量。豁免规则保证正常的 TLS/HTTP 绝对不受影响
协议指纹的前向兼容性：未来出现的新协议只要前几个字节像 TLS/HTTP 就能豁免

2.7 主动探测系统与被动检测的协同

USENIX Security '23 论文第 8 节揭示了 GFW 的两个并行系统：

系统	触发方式	使用规则	延迟
被动检测	实时（每个连接）	Algorithm 1 的 5 条规则	实时阻断
主动探测	可疑 IP 被标记后	Algorithm 1 的 5 条规则 + 1 条额外的载荷长度规则	异步（分钟级）

主动探测系统的额外规则：只对首个数据包载荷长度为 200 字节的连接触发主动探测。这意味着 GFW 的主动探测系统不是盲目向所有可疑 IP 发包——它首先检查是否有连接触发了长度条件。

重要的规避含义：如果代理协议能设计得让首个数据包的载荷长度不落在主动探测触发的范围内（如使用可变长度前缀），就能同时规避被动和主动两套系统。

3. Geedge TSG 的 DPI 能力（泄露文件印证）

2025 年 9 月的 Geedge Networks 泄露文件（572 GiB）包含了 TSG 网关的内部设计文档和工作记录，直接印证了 GFW 级别的 DPI 设备具备的能力：

3.1 SSL/TLS 解密

"TSG 能够解密 SSL 和 TLS 加密流量，绕过安全证书，在无法解密时捕获元数据，并镜像解密后的流量进行分析。"（来源：美国国会听证会证词，Xiao Qiang, 2024 年 7 月）

这意味着 TSG 在特定条件下（如企业/政府部署了受控 CA 证书的设备上）可以进行完整的 TLS MITM。但在没有 CA 证书植入的环境中，TSG 只能分析元数据（SNI、TLS 版本、密码套件等）。

3.2 应用识别和控制

泄露文件显示 TSG 的应用防火墙可以"控制和识别 1000+ 应用"，包括对 VPN 和代理应用的针对性封锁。

3.3 指纹识别

Geedge Wikipedia 条目确认 TSG "能够识别 TLS 与 QUIC 指纹"。泄露文件中的 Jira 工单显示工程师对一些流行代理工具进行了针对性的反向工程和指纹提取。

3.4 用户行为关联

TSG 的 Cyber Narrator 界面可以将：

用户的地理位置（基于蜂窝定位）
SIM 卡身份信息
上网记录
VPN 使用检测

全部关联到单个用户画像。

3.5 模式切换

泄露文件记录了 TSG 在埃塞俄比亚的部署中，系统在"被动监控"和"主动阻断"模式之间切换了 18 次。证明 DPI 系统不是静态配置，而是可以根据运营需要动态调整阻断策略。

4. 包长度分析：GFW 的第二层检测

除 Algorithm 1 的熵 + ASCII 分析外，GFW 还使用数据包长度作为检测手段。

4.1 固定长度首包的检测

VMess AEAD 头的总长度 = 16(AuthID) + 18(ALength) + 8(Nonce) + Y(指令密文)

Y 取决于目标地址的长度。对于典型的 IPv4 地址：

Y = 1(版本) + 16(IV) + 16(Key) + 1(RespAuth) + 1(Option) + 1(Sec) + 1(Reserved) + 1(Cmd) + 2(Port) + 1(AType) + 4(IPv4) + 填充 + 4(FNV) + 16(Tag)
Y ≈ 50-65 字节（取决于填充）
总长度 ≈ 90-105 字节

这个固定范围的长度分布与其他协议（TLS、HTTP、DNS）的首包长度分布不同——GFW 可以通过统计学习建立每个协议首包长度的"正常分布"，然后标记异常值。

4.2 TLS-in-TLS 的包长度特征

当代理流量被封装在 TLS 隧道中时，外层 TLS 记录的数据部分包含了原本的 TLS 数据——这导致外层 TLS 记录的长度偏离正常 HTTPS 流量的长度分布。

正常的 HTTPS 请求：ClientHello 的载荷由浏览器构造，长度在特定范围内。代理 TLS 隧道内的 ClientHello：外层 TLS 记录的载荷 = 内层 ClientHello + 代理协议头，长度偏大。

5. Xray-core 各协议对 DPI 的对抗等级

协议组合	Algorithm 1 Ex1 豁免	Algorithm 1 Ex5 豁免	无 TLS-in-TLS	抗主动探测	综合对抗等级
裸 Shadowsocks	否	否	N/A	部分（drainer）	低
裸 VMess	否	否	N/A	部分（时间戳重放窗口）	低
Trojan	是	是	否	部分（回落）	中
VLESS + TLS	是	是	否	部分（TLS 回落）	中
VLESS + XTLS Vision	是	是	是（分流后）	部分	较高
VLESS + REALITY	是	是	是	强（回落+爬虫）	高
VLESS + XTLS Vision + REALITY	是	是	是	强	最高

6. 外部参考资料

资料：How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic 类型：顶会论文（USENIX Security '23, Wu Mingshi et al.）链接：https://www.usenix.org/conference/usenixsecurity23/presentation/wu-mingshi 可信度：A 建议参考：Algorithm 1 完整伪代码、5 条规则的实验验证方法、论文附录的 7 个实验声明（C0-C6）

资料：How China Detects and Blocks Shadowsocks 类型：学术论文（IMC '20, GFW Report）链接：https://gfw.report/publications/imc20/en 可信度：A 建议参考：7 种 GFW 主动探测类型、首包长度和熵的检测方法

资料：Geedge & MESA Leak: Analyzing the Great Firewall's Largest Document Leak 类型：技术调查报告（GFW Report）链接：https://gfw.report/blog/geedge_and_mesa_leak/en 可信度：A 建议参考：TSG 的 DPI 能力清单、部署国家、泄露文件结构

资料：Censorship Measurement Insights from the Geedge Networks Leak 类型：学术论文（FOCI 2026, Sheffey et al.）链接：https://petsymposium.org/foci/2026/foci-2026-0006.pdf 可信度：A 建议参考：6,915,266 个被监控域名的分析

读者自检

Algorithm 1 的五条豁免规则是什么，每条检查什么
为什么 GFW 使用"豁免无害流量"的策略而不是"匹配有害流量"
熵检测（Ex1）如何区分 TLS ClientHello 和 Shadowsocks 数据包
为什么纯随机数据（popcount/len ≈ 4.0）单独使用就无法通过 GFW 被动检测
Geedge TSG 的 DPI 能力如何印证学术论文中推断的 GFW 规则

深度包检测（DPI）机制 ​

1. DPI 在审查体系中的位置 ​

2. GFW Algorithm 1：全加密流量被动检测 ​

2.1 核心算法 ​

2.2 Ex1：比特熵检测 ​

2.3 Ex2-Ex4：ASCII 字符检测 ​

2.4 Ex5：协议指纹 ​

2.5 各协议在 Algorithm 1 中的豁免路径 ​

2.6 为什么 GFW 选择"豁免"而非"匹配"策略 ​

2.7 主动探测系统与被动检测的协同 ​

3. Geedge TSG 的 DPI 能力（泄露文件印证） ​

3.1 SSL/TLS 解密 ​

3.2 应用识别和控制 ​

3.3 指纹识别 ​

3.4 用户行为关联 ​

3.5 模式切换 ​

4. 包长度分析：GFW 的第二层检测 ​

4.1 固定长度首包的检测 ​

4.2 TLS-in-TLS 的包长度特征 ​

5. Xray-core 各协议对 DPI 的对抗等级 ​

6. 外部参考资料 ​

读者自检 ​