---
title: "2025 年 GFW 泄露事件：积至与 MESA 资料揭示了哪些审查技术细节"
date: 2026-10-19
updated: 2026-10-19
categories:
  - GFW 与审查
tags:
  - GFW
  - DPI
  - 检测
  - 封锁
  - 隐私
  - 泄露事件
excerpt: "2025 年 9 月，积至（Geedge Networks）与中科院信工所 MESA 实验室的大批内部资料被公开。本文梳理 InterSecLab、国际特赦组织和 USENIX 论文等公开分析，区分有佐证的事实与文件所称，并说明它对用户和开发者的意义。"
index_img: /images/posts/gfw-leak-2025.svg
---

> **摘要**：2025 年 9 月，一批来自积至（Geedge Networks）和中国科学院信息工程研究所 MESA 实验室的内部资料被公开散布，总量约 600 GB，GFW Report 称之为防火长城历史上规模最大的文档泄露。InterSecLab、国际特赦组织、Justice For Myanmar 等机构据此披露了该公司以「天狗安全网关」（TSG）为核心的产品线，以及它向哈萨克斯坦、埃塞俄比亚、巴基斯坦、缅甸输出的情况；2026 年的一篇 USENIX Security 论文更进一步，在实验室里编译运行了 TSG，并测到它与 GFW 部分组件高度一致的指纹。本文只依据这些公开分析，梳理事件经过、产品与能力、出口国家，以及它与站内六层检测、TLS 指纹、全加密检测等文章的对应关系。先说结论：泄露资料没有让任何主流协议一夜失效，它更像一份迟到的说明书，印证了大量既有测量，也指出了哪些特征最容易被写成签名。

---

## 先说明：信息来源与本文的边界

本文不直接链接任何提供下载的页面，也不转载或指引获取泄露原始文件（部分论文的参考文献会引用散布方页面，请勿循此获取），只引用对这批资料做过分析的公开报告与论文，并尽量标明每个说法出自谁。主要来源如下：

| 来源 | 性质 | 发布时间 | 依据 |
|------|------|---------|------|
| InterSecLab《The Internet Coup》 | 数字取证研究机构的技术报告 | 2025-09-09 | 来源方共享的 10 万余份文件；作者声明未对源代码做全面审查 |
| 国际特赦组织《Shadows of Control》 | 人权组织调查报告，聚焦巴基斯坦 | 2025-09-09 | 泄露文件、贸易记录、访谈 |
| Justice For Myanmar《Silk Road of Surveillance》 | 倡导组织报告，聚焦缅甸 | 2025-09-09 | 泄露文件 |
| Follow the Money 等媒体联合调查 | 新闻报道 | 2025-09-09 | 泄露文件、向相关企业求证 |
| GFW Report 分析文章 | 审查研究团队的初步分析 | 2025-09-12 | 公开散布的文件 |
| FOCI 2026 论文《Geedge Cases》 | 同行评审论文，侧重域名与测量 | 2026-02 | 572 GiB 泄露数据与实地测量 |
| USENIX Security 2026 论文 | 同行评审论文，源代码分析 | 2026-08 | 编译运行 TSG，并在多国测量 |

阅读时请记住三点：

1. **报道称不等于已证实**。关于客户、功能的大部分描述来自内部文件本身，文件里写了某项功能，不代表它在现实中一定如此运行。下文用「据某机构」标注出处，有独立测量或第三方回应佐证的会单独说明。
2. **数据有截止时间**。USENIX 论文称泄露中最新的文件到 2024 年 11 月，InterSecLab 也说缅甸相关文件不覆盖 2024 年 12 月之后的事件。现在的系统未必与当时相同。
3. **这是一家供应商的视角**。GFW 由多套设备共同组成，TSG 只是其中可能的一部分，不能把它等同于 GFW 的全部。

---

## 事件经过：先有调查，后有公开

这次泄露有两条容易混淆的时间线：一是调查机构提前拿到资料并分析，二是资料被公开散布。

| 时间 | 事件 | 来源 |
|------|------|------|
| 2018 年 | 积至在海南成立 | GFW Report、InterSecLab |
| 约 2019 年 | 与首个海外客户哈萨克斯坦开始合作 | InterSecLab |
| 2021 至 2023 年 | 先后进入埃塞俄比亚、巴基斯坦、缅甸；InterSecLab 认为 2022 年起在国内省份开展项目 | InterSecLab、国际特赦组织 |
| 2024 年 11 月前后 | 泄露资料中最新文件的时间 | USENIX 论文 |
| 公开前约一年 | 一个未公开身份的来源把资料交给 InterSecLab 等合作方，多家机构联合分析；具体移交日期未公开 | InterSecLab 方法论（来源方）；USENIX 论文、国际特赦组织（约一年） |
| 2025-09-09 | InterSecLab、国际特赦组织、Justice For Myanmar、Follow the Money、The Globe and Mail、DER STANDARD 等同日发布调查，合作项目名为 Great Firewall Export | 各机构发布页 |
| 2025-09-11 | 黑客行动主义团体 Enlace Hacktivista 公开散布资料 | GFW Report、FOCI 2026 论文 |
| 2025-09-12 | GFW Report 发布初步分析，说明源代码部分尚未细看，并提醒只在断网的隔离环境中处理这些文件 | GFW Report |
| 2026-02 | FOCI 2026 论文《Geedge Cases》发布 | GFW Report 等 |
| 2026-08 | USENIX Security 2026 发表首份 TSG 源代码分析 | USENIX |

按 USENIX 论文的统计，572 GiB 的资料大致分四块：一个约 463 GiB 的 RPM 软件包仓库（打包好的防火墙、检测器等组件），约 59 GiB 的 MESA Git 仓库（底层平台、协议插件、规则引擎、构建镜像等），约 46 GiB 的 Confluence 文档（其中有 VPN 签名更新日志、Psiphon 误伤分析），以及约 2.5 GiB 的 Jira 工单（包括缅甸、埃塞俄比亚的部署工单）。资料是如何流出的，目前没有任何一方公开说明。

### 各方说法不一致的地方

| 项目 | 说法 A | 说法 B | 说明 |
|------|--------|--------|------|
| 泄露规模 | GFW Report：据称超过 500 GB，全部文件约 600 GB | FOCI 与 USENIX 论文：572 GiB | 572 GiB 约合 614 GB，差异主要来自单位与统计口径 |
| 方滨兴的角色 | GFW Report、InterSecLab：首席科学家 | Follow the Money、FOCI 2026 与 USENIX 2026 论文（作者含 GFW Report 成员）：公司由他于 2018 年创立 | InterSecLab 的依据是一篇 2024 年的新闻稿；两种身份可以同时成立，论文没有给出创立说的具体依据，本文不作判断 |
| 哈萨克斯坦起始时间 | InterSecLab：约 2019 年 | 项目代号 K18 | InterSecLab 自己指出，代号末两位不一定是起始年份 |
| 福建项目起始时间 | InterSecLab：2022 年试点 | FOCI 论文引用的泉州部署文档，文件名日期为 2021-10-24 | 文档日期不等于项目上线时间 |
| 与 GFW 的关系 | InterSecLab（2025-09）：无法确认积至是否复制了 GFW，或二者如何相关 | USENIX（2026-08）：测量结果表明泄露的 TSG 代码或其近似版本部署在 GFW 的一部分上 | 后者基于源代码与实测，证据更强，但范围限定为一部分 |

### 哪些有佐证，哪些只是文件所称

| 说法 | 证据类型 | 强弱 |
|------|---------|------|
| 资料确实来自积至与 MESA 的开发环境 | 研究者从中编译出可运行的 TSG；多家机构交叉核对 | 强 |
| TSG 或其衍生版本用于 GFW 的部分组件 | 源代码与多地实测指纹吻合 | 较强；论文措辞为 suggest（表明）与 strongly indicating（强烈指向） |
| 积至使用 Thales 的软件授权管理产品 | 代码中的授权检查，加上 Thales 向媒体确认积至是其客户 | 强；Thales 否认其产品与监控功能有关 |
| 缅甸 2024 年 5 月起的 VPN、Tor、Psiphon 封锁与积至系统有关 | 内部文件，加上 OONI、Tor 指标和 Psiphon 内部数据的时间吻合 | 较强 |
| 向四个国家供货 | 内部文件，加上贸易记录、媒体采访等旁证 | 中到较强，各国程度不一 |
| 用户信誉分、基站定位、恶意代码注入、DDoS 平台等能力 | 内部文档描述 | 报道称，未见公开的独立验证 |
| 积至员工可访问客户国数据，部分数据样本流向 MESA 学生 | 内部文档 | 报道称 |
| 代号 A24 的客户身份、招聘广告中提到的国家 | 线索不足 | 未知 |

---

## 涉及的机构与产品

### 两个主体

- **积至（Geedge Networks）**：据 GFW Report，公司全称积至（海南）信息技术有限公司，2018 年成立，CTO 郑超曾是 MESA 团队成员。GFW Report 把它描述为 GFW 背后的核心技术力量之一，国际特赦组织则认为它提供的是商业化版本的「防火长城」。
- **MESA 实验室**：英文名 Massive Effective Stream Analysis。据 GFW Report，它是中科院信息工程研究所的一个处理架构团队，2012 年组建并命名。USENIX 论文则称 TSG 的底层报文平台 SAPP 自 2005 年起由 MESA 开发，早于团队命名时间，可能指其前身，公开资料对此没有说清。InterSecLab 称两家关系密切：MESA 的学生参与产品研发，部分真实客户数据样本被用于研究如何阻断翻墙工具。

### 产品线

据 InterSecLab 与 Follow the Money，积至以整套方案出售，主要组件如下：

| 组件 | 报道描述的作用 |
|------|---------------|
| 天狗安全网关（Tiangou Secure Gateway，TSG） | 旗舰产品，运营商级防火墙：DPI、应用识别、封锁 VPN 与翻墙工具、限速、按用户拦截 |
| TSG-X 与 TSG-OS | TSG 的硬件形态与操作系统；TSG-OS 基于 RHEL，转发面 MARSIO 基于 DPDK |
| Central Management（内部旧称 Bifang） | 集中管理节点集群、下发策略 |
| TSG Galaxy | 基于 Kafka 等组件的数据仓库，记录 TCP、UDP 会话与 SIP 通话元数据 |
| Cyber Narrator | 面向非技术分析人员的界面，可按用户查询，结合基站 ID 定位手机用户 |
| Sanity Directory | 对接运营商的认证计费系统，把流量对应到具体用户和 SIM 卡，并维护信誉分 |
| Network Zodiac（内部称 Nezha） | 网络设备监控 |
| Ether Fabric | 自研的流量分发硬件，按五元组哈希把流量分给多个节点 |
| AppSketch 与 AppSketch Works | 应用与 VPN 指纹库；后者是尚处早期、用于自动生成签名的沙箱 |

以上均为报道依据内部文档的描述。InterSecLab 明确说没有对源代码做全面审查，所以「文档写了某功能」与「该功能在现实中被如何使用」之间还隔着一步。

---

## 技术拆解：TSG 如何看、如何判、如何拦

这一节主要依据 USENIX Security 2026 论文。研究者从泄露的构建仓库中编译出 TSG 最新的标记版本，在隔离的 Docker 环境中运行测试，这是目前公开资料里关于 TSG 内部机制的直接证据。论文按 DPI 的通用流程把 TSG 拆成四个阶段：

1. **接入**：接收串联或镜像过来的流量；
2. **处理**：重组数据流、解析协议字段、维护连接状态；
3. **判定**：把提取出的属性与策略规则比对；
4. **干预**：阻断、降速或终止被判定违规的连接。

### 协议解析：SAPP 与插件

SAPP（Stream Analysis Process Platform）是用 C 语言写的底层平台，负责二到四层解析以及 VLAN、PPPoE、VXLAN 等封装，再把重组后的数据流交给各个插件：

| 插件 | 提取的信息 |
|------|-----------|
| DNS | 查询的域名与类型，应答中的各类记录 |
| SSL（TLS） | SNI、密码套件、扩展长度，并直接计算 JA3 与 JA4 指纹；证书的主体、签发者、有效期、SAN |
| QUIC | SNI、User-Agent、版本号；能解析明文和加密的 Initial 包 |
| HTTP、邮件、SIP、FTP 等 | 对应协议的字段 |

规则引擎名为 Maat，可以从 Redis、JSON 或文件加载规则。可匹配的属性相当宽泛：内外层 IP、GRE 端点、端口、FQDN 与 SNI、ASN、国家，以及双向首个数据包的载荷。论文表 2 给出了一条以 JSON 模式配置、用来封锁 blocked.com 的示例规则。原文是嵌套的 JSON，还有 uuid、after_n_packets 等字段，下面只节选关键字段，缩进表示层级：

```text
# 论文表 2 的字段节选，原为嵌套 JSON，缩进表示层级
rule_table_name: SECURITY_RULE
action: Deny
action_parameter:
  sub_action: drop
  send_tcp_reset: 1
and_conditions[0]:
  attribute_name: ATTR_SERVER_FQDN
  objects[0]:
    expression: blocked.com
    match_method: full
    format: uncase plain
```

意思是：服务器域名不区分大小写、完整匹配 blocked.com 时，丢弃该连接并发送 TCP RST。

### 应用识别：三套检测器，两套来自第三方

| 检测器 | 来源 | 特点 |
|--------|------|------|
| CBD（Context-Based Detector，前身为 AppSketch） | 积至自研 | 加载签名，内置签名与用户自定义签名按应用 ID 区分 |
| Glimpse | 基于开源的 libprotoident（怀卡托大学） | 基础引擎 libprotoident 主要依据双向首个载荷的前 4 个字节，辅以首包载荷长度与端口；另含改自 2022 年版 nDPI 的 OpenVPN 识别代码，以及单独的 DNS、QUIC 识别 |
| QDPI | 基于商业 DPI 库 Qosmos ixEngine | 据称可分类 4700 多种协议与应用 |

论文的判断是：三套识别系统有两套依赖第三方库，说明即便是资源充足、与国家关系密切的供应商，从零做全面的协议分类也很昂贵。研究者已把代码被使用的情况告知 libprotoident 团队和 Qosmos 的母公司 Enea。

### 签名长什么样

Confluence 里一份 VPN 签名更新日志，记录了 2024 年 3 月到 11 月的签名更新，共 29 条，风险等级从 3 到 5，其中 21 条为 5 级。被点名的主要是商业 VPN 与知名翻墙工具，例如 ExpressVPN、NordVPN、Psiphon、Tor Browser、Ultrasurf、WARP、Refraction Networking 等。论文列举的签名条件包括：

| 条件类型 | 论文中的例子 |
|---------|-------------|
| TLS 指纹 | ExpressVPN：JA3 指纹匹配 |
| 证书字段 | Flash VPN：证书签发者的通用名与组织名匹配特定字符串 |
| 载荷长度与固定字节 | HideMe：UDP 首包长度恰为 54 字节，并含固定字节串 |
| 域名模式 | Ultrasurf：服务器域名匹配 8 种模式之一，同时 JA3 匹配 |
| IP 段加白名单 | Psiphon：匹配 1023 个 CDN IP 段，同时排除 5.6 万多个已知正常域名 |

论文还在 Jira 中检索 vpn 一词，得到约 700 条结果，分属 182 个问题，其中缅甸 440 条、埃塞俄比亚 53 条。几个例子很能说明签名是怎样「磨」出来的：缅甸客户反馈，Signal 开启「审查规避」选项后封锁失效，工单要求参考 K 项目（论文认为很可能指哈萨克斯坦）的经验处理，并应客户要求把 LetsVPN 的优先级排在 Lantern 之前；埃塞俄比亚的一张工单则记录了封锁 Psiphon 时误伤其他应用；工单里的测试结果，以及 Confluence 文档《GTN498 Psiphon3 封锁误伤分析》描述的做法是：因为 Psiphon 缺少明显特征，改为结合客户端 IP 列表与服务器 IP 来识别，并对访问热门 SNI 的连接加白名单保护。论文据此认为，翻墙工具签名是在客户反馈失败、提出优先级、报告误伤的循环中迭代出来的。

### 拦截手段

| 手段 | 说明 |
|------|------|
| 丢包 | 丢弃整条流或当前包，需要串联部署 |
| TCP RST | 默认发 1 个 RST+ACK，可配置为 1 到 3 个 |
| HTTP 拦截与重定向 | 返回 200、204、403、404，或用 302、303 跳转 |
| DNS 重定向 | 返回伪造应答 |
| 邮件与 SIP 拦截 | 注入特定的错误响应 |
| 限速 | 会话级令牌桶，或丢弃超过阈值的包 |
| 篡改 | 交换载荷首尾各两个字节后重新发送 |
| 延迟拦截 | 处理够指定数量的包之后才执行规则 |

其中篡改和延迟拦截值得留意：它们会让连接表现为「握手成功但随后出错」或「用了一会儿才断」。这为一些难以解释的故障提供了一种可能性，但不能据此认定某一次故障就是它造成的。

### 部署形态：旁路镜像与串联

据 InterSecLab，积至系统有两种部署模式：

- **镜像（文档中称 passive）**：通过分光或光旁路设备（InterSecLab 称为 optical bypass switch，即光旁路开关）把流量复制给设备，设备故障不影响上网，但只能靠注入数据包来阻断连接；
- **串联（文档中称 active）**：流量必须穿过设备，可以直接丢弃，但设备故障会导致断网，也会增加延迟。

InterSecLab 注意到，埃塞俄比亚的修订日志共记录了 18 次切换到串联模式的操作，其中两次发生在 2023 年 2 月当地网络限制之前的 Safaricom 机房，它据此认为模式切换与准备断网存在关联。这是相关性推断，并非文件中的明确说明。

### 身份关联与追溯

这是报道中与普通用户关系较大的部分，均为 InterSecLab 依据文档的描述：

- TSG Galaxy 结合运营商信息，把流量对应到 IP、用户 ID、IMEI、IMSI；
- Sanity Directory 为每个用户维护信誉分，文档描述分数过低时可能被断网，并被要求做证件与人脸核验；
- 被标记为已知 VPN 用户的人，其后出现的无法识别的大流量会被视为可疑，以此发现尚未被封的新 VPN，进而波及该 VPN 的全部用户；
- Cyber Narrator 可以回溯查询：某个网站被封之后，找出此前访问过它的人；
- 新疆项目的需求文档还把关系图谱、基于基站的聚集检测、电子围栏，以及标记频繁换卡、常打国际电话、使用翻墙工具的人列为后续开发需求，是否已经实现未见公开证据。

### 报道中风险较高的几项能力

以下同样是 InterSecLab 依据内部文档的描述，未见公开的独立验证，也没有公开证据说明它们在何地、对何人使用过：

- **TLS 中间人**：组件 TFE 可做完整解密，但前提是用户设备安装了自签根证书；更常用的是不解密、只用 DPI 与机器学习提取元数据。
- **在路注入（in-path injection）**：设备位于流量路径上，可在未加密连接上篡改下载内容，涉及 HTML、JS、APK、EXE、DMG、RPM、图片、压缩包、办公文档等格式。
- **DLL Active Defence**：InterSecLab 认为这是一个发起 DDoS 的平台，类似 Citizen Lab 2015 年描述的「大炮」（Great Cannon）。
- 据 InterSecLab 转述，国际特赦组织在一张 Jira 工单里发现了 TSG 在未加密连接上截获的完整邮件内容、附件和邮箱密码。

---

## 出口到哪些国家：逐一核实

| 国家 | 代号（据 InterSecLab） | 报道中的起始时间 | 要点 | 主要来源 |
|------|----------------------|----------------|------|---------|
| 哈萨克斯坦 | K18、K24 | 约 2019 年；网络规划日志始于 2020 年 9 月 | 首个海外客户；2020 年 10 月的文件列出国家中心与另外 17 个城市；贸易记录显示 2024 年仍有发货；InterSecLab 认为这推翻了当地 DPI 源自俄罗斯 SORM 的旧看法 | InterSecLab |
| 埃塞俄比亚 | E21 | 2021 年；修订日志从 2021 年 9 月到 2024 年 6 月 | 部署在包括 Safaricom 在内的运营商机房；2023 年 2 月社交媒体受限期间，积至专家被叫去处理与 YouTube、Twitter 有关的问题 | InterSecLab、Follow the Money |
| 巴基斯坦 | P19 | 2023 年 | 替换加拿大 Sandvine 的旧系统，国际特赦组织称新系统为 WMS 2.0，可封锁 VPN 与被认定为违法的网站；部分运行在 Sandvine 留下的硬件上 | 国际特赦组织、InterSecLab |
| 缅甸 | M22 | 2023 年开始实施，2024 年 5 月后效果明显 | 规划文件列出 6 个城市的 30 个机房；涉及 13 家运营商；军政府提供 55 款高优先级应用清单，含 Signal 与 WhatsApp；Tor 与 Psiphon 受到封锁 | InterSecLab、Justice For Myanmar |
| 未知 | A24 | 2024 年前后 | 只见两次概念验证部署，无法识别国家 | InterSecLab |

补充几点：

- **缅甸**：Justice For Myanmar 称这套系统让军政府可以获取 3340 万互联网用户的网络活动，并点名 13 家运营商。InterSecLab 引用 OONI 与 Tor 的指标称，Tor 自 2024 年 5 月起在缅甸被有效封锁；Psiphon 向其提供的数据显示，2024 年 5 月 30 日起缅甸新增约 50 万用户，服务器发现方式也明显转向抗枚举的类型，说明大量服务器被同时封锁，但用户总体仍能连上。Justice For Myanmar 是呼吁制裁的倡导组织，阅读时应考虑其立场。
- **巴基斯坦**：国际特赦组织称，WMS 2.0 用到了美国 Niagara Networks 与法国 Thales 的软硬件。据 Follow the Money，Sandvine（现更名 AppLogic Networks）确认曾向巴基斯坦供应软硬件，但表示并不知道积至，也不知道其硬件被改作他用；报道则称积至是在 Sandvine 留下的硬件上搭建防火墙，而 Sandvine 看来并不知情。
- **Thales**：InterSecLab 与 Follow the Money 都报道积至用 Thales 的 Sentinel 授权系统控制 TSG 的许可期限，USENIX 论文也在代码中看到了对应的授权检查。Thales 确认积至是其客户，但称积至的软件并不依赖其产品运行，且与监控功能无关。需要注意的是，USENIX 研究者构建 TSG 时发现，SAPP 软件包在构建时启用了 Sentinel 授权校验，运行时每秒校验一次，需先替换授权库才能运行，这与「不依赖其产品运行」的说法存在张力。
- **企业回应**：据 Follow the Money，积至和方滨兴均未回答提问。
- **其他国家**：GFW Report 转引《环球邮报》（The Globe and Mail）称，积至一则提及「一带一路」的招聘广告列出了巴基斯坦、马来西亚、巴林、阿尔及利亚和印度；除巴基斯坦外，其余国家并未被确认为客户。

### 国内：省级防火墙

据 InterSecLab，积至的产品先卖给海外客户，2022 年才开始在国内与省级政府合作。不过 FOCI 论文引用的泉州部署文档日期为 2021 年 10 月，InterSecLab 报告自己的图 3 也记录了 2021 年 3 至 4 月 MESA 人员赴新疆、照片可能摄于 TSG 部署工作期间，因此国内项目的实际起点可能早于 2022 年（文档日期仍不等于正式上线时间）。

| 地区 | 代号与时间 | 报道要点 |
|------|-----------|---------|
| 新疆 | J24；2022 年 4 月起先做网络性能监测试点，2024 年 3 月 29 日停用后启动 J24 | 一份文档称有 17 个运营商中心，分布在电信、移动、广电、联通的机房；2024 年 6 月的会议记录称国家防火墙正从集中式走向分布式，新疆要成为省级建设的样板 |
| 福建 | 2022 年试点，未见代号 | 设备位于泉州、福州、漳州、宁德、厦门；工单显示客户为省级政府部门 |
| 江苏 | 2023 年 2 月测试环境上线，据称最迟于 2024 年 3 月 15 日进入生产 | 合作方为江苏省公安厅，文件中所述的合作理由是打击网络诈骗 |

这和 GFW Report 等团队 2025 年的研究《A Wall Behind A Wall》相呼应：该研究发现河南有一套独立于国家级 GFW 的省级防火墙，只过滤从河南发往省外的流量。在 2023 年 12 月至 2025 年 3 月对约 2.27 亿个域名的每周测试中（2024 年 3 月至 10 月有中断），河南防火墙累计封锁约 420 万个域名，是同期测得的 GFW 累计封锁数（约 74 万）的 5 倍以上。InterSecLab 认为泄露资料印证了这种地区化趋势；它还注意到，同一研究从美国测往江苏时多测到 29 个被封域名（440 个，测往其他地区均为 411 个），可能对应积至在江苏的早期部署，但这仍是推测。另外要注意：河南并不在泄露资料点名的省份之列，USENIX 论文对河南的测量也没有观察到与 TSG 吻合的 RST 种子特征，因此不能说河南用的是积至的设备。

---

## 与 GFW 的关系：测量给出的证据

USENIX 论文的研究者在郑州、北京、阿拉木图、仰光、卡拉奇、伊斯兰堡等地设置测量点，用自己控制的服务器做测试，结果如下：

| 测试项 | TSG 的特征 | 实测对应 |
|--------|-----------|---------|
| DNS 注入 | 应答标志位为 0x8180，使用压缩指针，解析查询时最多允许 17 次指针跳转 | 只有 GFW 的第二个 DNS 注入器同时吻合这三点 |
| IP 分片重组 | 每个重组队列最多处理 101 个分片 | GFW II 的边界为 102，非常接近 |
| TCP RST 注入 | 用自定义伪随机算法生成 IPID、窗口、TTL，默认种子为 13 | GFW II 与 GFW III 都稳定推算出种子 13 |
| TLS ClientHello 长度字段解析 | 对异常长度字段的处理方式 | GFW II 与旧版 TSG 的 SSL 模块行为一致 |
| QUIC 解析 | 支持的版本、1200 字节下限等 | GFW 与哈萨克斯坦拦截的测试向量与 TSG 相同，但支持的 QUIC 版本不同，无法完全对上；哈萨克斯坦的解析指纹与旧版 TSG 一致；缅甸支持的版本一致，但解析指纹不同，无法确认 |

TCP RST 那一项最有说服力。论文给出的生成逻辑大致是：

```text
win  = val + (dip mod k)
ipid = M - val * k + (sip mod win)
# k 即种子，默认 13；M 默认 65535；sip、dip 为连接两端的 IP
```

针对同一对 IP，取同一个注入器伪造的两个 IPID 与窗口值都不同的 RST 包，就能解方程反推出 k（窗口值始终相同时 k 无法确定）。论文对每个注入器诱发了大量 RST，两两估计 k，再检验结果是否始终一致。论文估计，一个注入器偶然稳定地呈现某个常数种子的概率约为 10 的负 44 次方，更别说恰好是 TSG 的默认值 13。

论文的结论措辞是：这些结果表明，泄露的 TSG 代码或与之接近的衍生版本，确实部署在中国国家防火墙的一部分上。这里有两个限定。其一，GFW 由多台各司其职的设备组成，吻合的是特定注入器，不是全部。其二，GFW II 也有与 TSG 不同的地方，比如 TTL 固定为 255，而 2023 年 12 月的旧测量数据中它的 TTL 又曾与 TSG 一致，说明实现一直在改。

出于伦理考虑，研究者没有公开泄露的源代码和部署方法。测量数据与扫描脚本已经公开，但他们搭建的 TSG 运行环境只向可信的研究者提供。

---

## 与站内 GFW 检测文章如何相互印证

站内 [GFW 工作原理全解](/posts/gfw-detection-overview/) 把检测拆成六层。对照泄露分析：

| 检测层 | 泄露分析中的对应 | 判断 |
|--------|-----------------|------|
| DNS 污染 | TSG 有 DNS 解析与注入代码，行为与 GFW 的第二个 DNS 注入器吻合 | 印证，并补充了具体是哪个注入器 |
| IP 封锁 | 规则可按 IP、ASN、国家匹配；Psiphon 签名依赖 IP 段；有工具持续抓取服务器列表生成封锁 IP | 印证，并补充了 IP 从哪里来；Psiphon 的 CDN 签名还说明，审查设备不必封整个 CDN，用「CDN IP 段 + 正常域名白名单」即可只拦截 CDN 上的陌生域名（该签名的部署地未确认是中国） |
| DPI | 协议插件加三套应用识别器；InterSecLab 称可识别 IPSec、OpenVPN、WireGuard | 印证 |
| TLS 指纹 | SSL 插件在解析握手时计算 JA3 与 JA4；签名可单独以 JA3 为条件（如 ExpressVPN），也可与域名模式等条件组合（如 Ultrasurf） | 能力层面印证，但需修正：泄露显示的是把特定应用的指纹写进黑名单签名，公开分析中未见「与浏览器指纹库比对、不匹配即可疑」的做法；USENIX 论文对应到 GFW 的是 TLS 长度字段的解析行为，并未测量 GFW 是否执行 JA3 签名 |
| 主动探测 | 本文查阅的公开分析没有把服务器探测作为重点 | 未涉及，不能据此推断有或没有 |
| 行为分析 | 无法识别的大流量可被标记，已知 VPN 用户的新流量被重点关注 | 补充：行为分析可以落到具体的人 |

### TLS 指纹：从推测到写进代码

[TLS 指纹识别](/posts/tls-fingerprinting/) 一文讲过 JA3 与 JA4 的原理。泄露分析补上的事实是：TSG 在解析握手时就计算 JA3 与 JA4，签名可以直接拿它们做条件；QUIC 插件则解析 SNI 与 User-Agent，这与 USENIX 论文背景部分引用的研究相符，即 GFW 自 2024 年 4 月起解密 QUIC Initial 包并按 SNI 阻断。对用户而言，一个稳定且少见的 TLS 指纹单独就可能被写成签名（如 ExpressVPN），再配上可枚举的 SNI 或域名模式（如 Ultrasurf）就更容易被精确匹配。

### 全加密流量：识别不了，不等于放行

[GFW 如何识别全加密流量](/posts/fully-encrypted-detection/) 介绍了 2023 年论文发现的启发式规则。InterSecLab 的报告写道：TSG 即使无法识别具体应用，也可以把异常的大流量标为可疑，并配置为一段时间（例如 24 小时）后封锁，它认为这与 GFW 封锁高带宽加密流的观察相符，并在脚注中引用了 2023 年那篇论文。需要说明，这是 InterSecLab 自己的概括，与 2023 年论文并不是同一现象：论文测到的系统只检查客户端发出的第一个 TCP 数据包，看首包的比特分布与可打印字符，命中规则即按约 26% 的概率丢包，并对同一三元组残留封锁 120 或 180 秒，与流量大小和持续时长无关；据作者的跟进测量，这套动态封锁已于 2023 年 3 月 15 日停止，之后未见重新启用的公开测量。本文查阅的公开源代码分析中，也还没有逐条对应那套启发式规则的代码。二者共同指向的一点是：看不出是什么协议，本身就可能成为一个信号。

### 主动探测：泄露揭示的是另一种主动

公开分析很少谈服务器探测，却详细描述了另一种主动手段：直接攻击服务器地址的分发渠道。

- **逆向 VPN 应用**：据 InterSecLab，积至通过反编译寻找返回服务器列表的接口，也会在受控环境中实际运行应用、分析其流量；资料还显示它据称在一些热门 VPN 服务商处持有付费账号。
- **抓取服务器列表**：InterSecLab 称积至开发了内部工具，持续抓取 Psiphon 的混淆服务器列表，生成封锁 IP 并下发到各地节点。
- **现成的地址清单**：FOCI 论文在资料中找到了含 4810 个域名的 NordVPN 服务器列表、Psiphon 的 CDN 域名，以及一个名为 VPN 主机发现、含 7016 个域名的数据集。
- **Tor**：InterSecLab 无法确定积至的网桥地址是自行收集还是从第三方获得；它还称，截至泄露时积至对 WebTunnel 传输尚无有效手段，MESA 的学生做过初步研究。

这说明节点被封未必是因为协议被认出，也可能是地址从客户端或订阅渠道泄露了，可与 [为什么你的节点会被封](/posts/node-blocking-causes/) 对照阅读。

### 地区差异：省级防火墙

站内 [为什么你的节点会被封](/posts/node-blocking-causes/) 与 [敏感时期封锁加强的规律与应对](/posts/sensitive-periods/) 此前把不同省份、不同运营商的封锁差异归因于执行力度不同。泄露资料与河南的测量研究补充了一种结构性原因：部分省份可能有自己的防火墙和规则（河南的这一套只过滤从省内发往外部的流量）。这也意味着同一个节点在不同地区的表现差异，有时并不是「运气」问题。

---

## 对普通用户：该做什么，不必做什么

### 先理性看待

- 资料截至 2024 年底，描述的是一家供应商的产品，公开分析点名的签名主要针对商业 VPN 应用和知名翻墙工具。
- 其中大部分检测手段，如 DNS 注入、按 SNI 阻断、JA3 指纹、IP 列表，此前都已被测量研究记录过。泄露的价值在于把它们串成了完整的图景，而不是揭示了某种无法对抗的新能力。
- 反过来，公开资料没点名某个协议，不等于它没被研究。据 InterSecLab，为一个客户开发的封锁能力，可以通过软件更新提供给其他客户。

### 协议与配置

1. **不必因为这次泄露换协议**。如果你的方案本来就有已知弱点，比如裸 VMess、旧版 Shadowsocks（流加密，以及缺少规范级重放防护的旧 AEAD）、未做指纹伪装的 TLS 代理，那是早该处理的问题，与泄露无关。各协议的取舍见 [主流代理协议横向对比](/posts/protocol-comparison/) 和 [Shadowsocks 2022 与 ShadowTLS](/posts/ss2022-shadowtls/)。
2. **避免特征明显的配置**。对照上面的签名条件：稳定且少见的 TLS 指纹（再配上显眼的 SNI 更容易被精确匹配）、自签证书里写着特殊的签发者名称、首包长度或开头字节固定、域名命名有规律可循，这些都可以直接成为规则的一部分。
3. **客户端与内核保持更新**，使用仍在维护的主流实现，指纹模板和协议细节才能跟上变化。

### 不要使用来路不明的客户端

- 报道称积至会逆向分析 VPN 应用并提取其中的服务器列表。闭源、小众、来路不明的免费 VPN 应用恰恰是这类分析的主要对象，内置的服务器地址也容易被一次性拿走。
- 报道描述的在路注入能力，针对的是未加密连接上下载的安装包。只从 HTTPS 官方渠道下载，并校验哈希与签名，具体方法见 [代理客户端安全自查](/posts/client-safety-check/)。
- 不要安装来历不明的根证书。InterSecLab 描述的 TLS 中间人方案需要用户装上自签根证书；哈萨克斯坦曾多次要求用户安装政府根证书，2019 年在首都推行时被 Mozilla、Google、Apple 等浏览器厂商联合拦截。

### 账号、身份与法律

- 在宽带与手机卡实名制的环境下，流量可以对应到具体用户，这一点不会因为你用什么协议而改变。报道描述的追溯能力，意味着过去的访问记录也可能被检索。
- 法律提示：《中华人民共和国计算机信息网络国际联网管理暂行规定》第六条规定，任何单位和个人不得自行建立或者使用其他信道进行国际联网；第十四条规定，违反第六条的，由公安机关责令停止联网，给予警告，可以并处 15000 元以下的罚款。公开报道中已有个人仅因使用翻墙工具玩游戏而被依第十四条警告的案例。其他风险说明见 [科学上网是什么](/posts/what-is-proxy/)。本文只讨论技术，不构成法律意见，请了解并遵守所在地的法律法规。
- **不要去下载泄露文件**。GFW Report 提醒这些文件可能含有风险内容，在不安全的环境中打开可能招致监控或恶意软件；持有和传播也可能带来法律风险。

---

## 对代理开发者：这批资料提供了哪些启示

### 签名条件就是设计时要避开的东西

| 签名条件 | 设计上的应对思路 |
|---------|----------------|
| JA3 与 JA4 | 客户端使用与主流浏览器一致的 TLS 行为（例如 uTLS 的 chrome 模板），并跟随上游更新，不要自写 TLS 栈 |
| 证书字段 | 不在证书中留下可识别的固定字符串，避免大量服务器共用同一张特殊证书；或像 Reality 那样直接借用真实站点的证书，见 [VLESS + Reality 深度解析](/posts/vless-reality-deep-dive/)。注意 Reality 解决的是证书与主动探测问题，客户端指纹仍要靠 uTLS 模拟 |
| 首包长度与固定字节 | 避免固定长度的握手和固定魔数；libprotoident 主要依据双向前 4 个字节、首个载荷包长度和端口识别，固定的开头与固定的首包长度最容易被认出 |
| 域名模式 | 避免可枚举的命名规律 |
| IP 段 | 服务器地址不以可批量抓取的形式随客户端分发 |

### 分发渠道是软肋

Psiphon 的混淆服务器列表被持续抓取，VPN 应用被反编译取出服务器接口，都说明审查方会把力气花在地址发现上。InterSecLab 给开发者的建议包括：加固应用以对抗逆向，以及在设计中引入 DNS 与 IP 的动态轮换，让审查方难以一次拿到全部服务器。

### 让识别变贵，让误伤变大

公开分析显示审查方也在意误伤：埃塞俄比亚的工单专门讨论封锁 Psiphon 造成的误伤，Psiphon 因为缺少明显特征，迫使对方改为结合客户端 IP 列表与服务器 IP 来识别，并加白名单保护热门 SNI。2023 年的全加密检测论文也发现，GFW 只对热门 VPS 网段、约四分之一的匹配连接下手；研究者推测这既能节省计算资源，也能减少对正常连接的误伤。混入大流量正常业务、缺少稳定特征的设计，会抬高审查方的成本。

### 解析差异是双刃剑

TLS 长度字段、IP 分片上限、QUIC 版本支持这些解析差异，既能用来给审查设备「验明正身」，也可能成为规避的突破口。GFW Report 对河南防火墙的研究就发现，分段发送 ClientHello 等简单方法即可绕过，已有不少工具实现了类似功能。但这类技巧很脆弱：USENIX 论文附录显示，TSG 的 TLS 解析代码在 2023 年 7 月和 2024 年 9 月都改过相关逻辑，今天有效的方法明天就可能失效。

### 用开源 DPI 做一次自测

可以先用开源 DPI 库看看自己的协议会不会被直接认出来（只抓取你有权抓取的、自己的测试流量）。两个工具一般需要从源码编译，libprotoident 的命令行工具还依赖 libtrace 与 libflowmanager。关键的操作顺序是：**先开始抓包，再建立连接**。这两个库都只看连接开头的若干个包，如果抓包时代理连接早已建好（长连接或多路复用很常见），抓到的流里没有握手和首包，结果只会是 Unknown，容易误以为「没被认出」。

```bash
# Linux/macOS 示例。先用 ip -br link（macOS 用 ifconfig）确认网卡名，网卡名和端口按实际替换
# 先开始抓包，再启动或断开重连代理客户端（临时关闭多路复用），确保抓到握手和首个数据包
sudo tcpdump -i eth0 -w capture.pcap host 203.0.113.10 and port 443
# 在客户端发起几次访问后，按 Ctrl+C 停止抓包

# -v 1 逐条输出每条流的识别结果和风险标记；--cfg 打开全加密启发式（nDPI 4.14 起默认关闭）
ndpiReader -i capture.pcap -v 1 --cfg=fully_encrypted_heuristic,1

# libprotoident 的输入要写成 libtrace URI，pcap 文件用 pcapfile: 前缀
lpi_protoident pcapfile:capture.pcap
```

用 Wireshark 抓包时请另存为 pcap 格式；如果保存的是 pcapng，libprotoident 的输入要改写为 `pcapng:capture.pcapng`。

看结果分三种情况：

| 结果 | 含义 |
|------|------|
| 被识别为 OpenVPN、WireGuard、Tor 等具体协议 | 特征可以直接写成签名，需要优先处理 |
| 只被识别为 TLS、QUIC 等通用协议 | 伪装类协议的预期结果，接下来要关心的是指纹、证书与 SNI |
| 显示 Unknown，尤其带有 Obfuscated Traffic（附注 Fully Encrypted）风险标记 | 属于「看不出是什么」的一类，正是全加密检测针对的对象 |

没被认出也不说明安全：QDPI 这类商业库覆盖的协议要多得多，行为分析与 IP 情报也不依赖协议识别。

### 伦理与法律边界

USENIX 论文的作者选择不公开源代码和部署方法，理由是这会帮助其他审查方。开发者同样不应把泄露代码引入自己的项目，这既有版权与法律风险，也可能把来源不明的代码带进用户设备。

---

## 常见问题（FAQ）

### 泄露资料会让所有协议失效吗？

不会。公开分析没有显示存在针对所有协议的通用解法；点名的签名主要针对商业 VPN 应用与知名工具，依赖的仍是 JA3、证书字段、固定载荷、域名模式、IP 列表这些已知维度。资料截至 2024 年底，系统此后也在变化。真正需要警惕的是那些本就有明显特征的方案，而不是泄露本身。

### 我该换协议吗？

如果你现在用的方案没有已知弱点、运行稳定，不必因为这次泄露而更换。更值得做的是检查配置：TLS 指纹是否伪装、证书与域名是否有显眼特征、客户端是否来自可信渠道并保持更新。选择方案时参考 [主流代理协议横向对比](/posts/protocol-comparison/)，并保留不同类型的备用线路。

### 泄露出来的 TSG 就是 GFW 本身吗？

不是。USENIX 论文的测量显示，GFW 中至少有一个 DNS 注入器和两个 TCP RST 注入器的行为与 TSG 高度吻合，结论是 TSG 代码或其近似版本部署在 GFW 的一部分上。GFW 由多台设备、多家单位共同组成，这次泄露只照亮了其中一块。

### 我能自己下载泄露文件看看吗？

不建议，本站也不提供任何获取途径。GFW Report 提醒这些文件可能包含恶意内容，只适合在断网的隔离环境中由研究人员处理；持有和传播也可能带来法律风险。想了解内容，阅读本文外部参考中的分析报告即可。

### 报道说能追溯 VPN 用户，我以前用过代理会怎样？

报道描述的回溯查询能力，出现在积至面向客户国的产品文档中，前提是系统长期保存了与用户身份关联的访问记录。这项能力在国内是否以及如何使用，公开资料没有给出证据，本文不做推测。可以确定的是，在实名制网络中，流量能被关联到具体用户，协议加密只能隐藏内容，隐藏不了「你在连接谁」。相关的法律与风险说明见 [科学上网是什么](/posts/what-is-proxy/)。

### 为什么公开分析里多是商业 VPN，很少提 Shadowsocks、VLESS 这类协议？

一方面，客户提交的封锁清单以手机上的 VPN 应用为主，签名开发也围绕这些应用展开；另一方面，已发表的分析只覆盖了资料的一部分，源代码与文档的深入研究仍在进行。没被点名不等于不受关注：针对全加密流量的启发式规则（2021 至 2023 年曾大规模运行）、行为分析和 IP 情报，本来就不需要逐个协议写签名。

### 这次泄露之后，GFW 会改吗？

无法确定。可以观察到的是，审查系统本来就在持续变化：USENIX 论文发现 GFW II 的 TTL 行为在 2023 年 12 月与 TSG 一致，此后又发生了变化。被公开的指纹特征，可能促使开发方调整实现，研究者依据这些特征得出的判断也需要不断复测。

---

## 外部参考

- 研究报告与论文：
  - [InterSecLab：The Internet Coup](https://interseclab.org/research/the-internet-coup/)
  - [USENIX Security 2026：Technical Analysis of the Geedge Networks Firewall Source Code Leak](https://www.usenix.org/conference/usenixsecurity26/presentation/ablove)
  - [FOCI 2026：Geedge Cases: Censorship Measurement Insights from the Geedge Networks Leak](https://gfw.report/publications/foci26b/en/)
  - [USENIX Security 2023：How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic](https://gfw.report/publications/usenixsecurity23/en/)
  - [IEEE S&P 2025：A Wall Behind A Wall: Emerging Regional Censorship in China](https://gfw.report/publications/sp25/en/)
- 调查报道：
  - [国际特赦组织：Shadows of Control（报告页）](https://www.amnesty.org/en/documents/asa33/0206/2025/en/)
  - [国际特赦组织 Security Lab：巴基斯坦大规模监控与审查新闻稿](https://securitylab.amnesty.org/latest/2025/09/pakistan-mass-surveillance-and-censorship-machine-is-fueled-by-chinese-european-emirati-and-north-american-companies/)
  - [Justice For Myanmar：Silk Road of Surveillance 新闻稿](https://www.justiceformyanmar.org/press-releases/report-reveals-how-chinas-geedge-networks-and-myanmar-telecoms-companies-are-enabling-the-illegal-juntas-digital-terror-campaign)
  - [Follow the Money：China exports censorship tech to authoritarian regimes](https://www.ftm.eu/articles/how-china-is-exporting-its-censorship-technology)
- 法规与案例：
  - [《计算机信息网络国际联网管理暂行规定》（国家互联网信息办公室网站）](https://www.cac.gov.cn/1996-02/02/c_126468621.htm)
  - [澎湃号·四川省监狱管理局：依第十四条处罚个人使用翻墙软件的案例（2024-08-06）](https://m.thepaper.cn/newsDetail_forward_28332654)
- 工具：[nDPI](https://github.com/ntop/nDPI)、[nDPI 配置参数说明](https://github.com/ntop/nDPI/blob/dev/doc/configuration_parameters.rst)、[libprotoident](https://github.com/LibtraceTeam/libprotoident)、[libtrace 支持的格式](https://github.com/LibtraceTeam/libtrace/wiki/Supported-Trace-Formats)

说明：GFW Report 2025 年 9 月 12 日的分析博文（标题 Geedge & MESA Leak: Analyzing the Great Firewall's Largest Document Leak）正文直接给出了资料下载地址，FOCI 2026 论文页面的参考文献也链接了散布方页面。本文不提供前者的链接，也请读者不要循参考文献获取原始文件。正文中标注出自 GFW Report 的公司中文全称、MESA 组建时间、CTO 背景、约 600 GB 的总量、隔离环境提醒，以及转引自《环球邮报》的招聘广告信息，只见于该博文，FOCI 与 USENIX 论文并未全部涉及；泄露规模、构成和技术细节则可在上方两篇论文中核对。

**站内相关文章**：

- [GFW 工作原理全解：从 DNS 污染到主动探测的六层检测机制](/posts/gfw-detection-overview/)
- [TLS 指纹识别：JA3/JA4 与反检测策略](/posts/tls-fingerprinting/)
- [GFW 如何识别全加密流量](/posts/fully-encrypted-detection/)
- [代理客户端安全自查](/posts/client-safety-check/)