翻墙技术详解：从代理与 VPN 到现代抗封锁网络

很多人第一次接触“翻墙”，面对的是几个开关：系统代理、全局、规则、TUN。能打开网页，就算成功；打不开，就换一个节点。

但这些开关背后，其实藏着几组完全不同的问题：地址有没有查对？数据包能不能到达？连接是否被识别？谁能看见访问目标？网页内容由谁解密？网站还能不能认出自己？

理解这些问题，需要从网络本身讲起。软件会更替，理解连接、加密边界和信任关系的方法可以一直用下去。

一、先把“翻墙”拆成四件事

“翻墙”是日常用语。在技术讨论中，更接近它的说法是网络审查规避（censorship circumvention）：当某条通信路径受到有选择的限制时，改变路径、封装、可见信息或连接方式，让通信仍然能够完成。

这里至少有四个目标，它们有关联，却不能互相替代。

可以借用寄信来理解：绕路送达、把信封封好、让信件外观不显眼、让寄件人与收件人的关系难以追踪，是四项不同的工作。

HTTPS 主要保护通信内容；单跳代理主要改变谁替你访问网站；VPN 通常把选定的网络流量送进受保护的隧道；匿名网络尝试分散不同节点掌握的信息；抗封锁传输则关注这条隧道在网络上是否容易被认出来。

因此，“这是 VPN 吗”“用了几层加密”都不是充分的问题。更有用的问题是：它解决哪个目标，在什么假设下有效，又把信任交给了谁？

二、打开一个网页，连接可能在哪一步被拦住？

假设我们访问一个虚构网站 library.example。浏览器并不会把一个完整的“网页请求”直接扔到互联网另一端；它需要经过一系列步骤。实际浏览器还会缓存、复用连接、并行发起请求，下面把过程展开，是为了看清各个干预位置。

图 1：检查点是逻辑划分，不意味着网络上有五台依次排列的审查设备。缓存和连接复用也可能跳过部分步骤。

2.1 地址簿：DNS 解析

域名便于记忆，网络转发通常需要 IP 地址。DNS 承担了“名字对应哪个地址”的查询工作。

干预可以发生在解析器，也可以发生在查询路径上。例如，路径上的设备观察到某个明文查询后，注入伪造响应；如果客户端接受了错误答案，后续连接就会走错地方。常说的“DNS 污染”往往包含这种现象，但不同网络和实现的干预方式不完全相同。

这里有一个关键区别：拿到了正确地址，只说明地址簿这一步成功，并不说明通往该地址的路是畅通的。 关于中国 DNS 审查的系统测量，可以看 Hoang 等人的研究（2021）。

2.2 道路与门牌：IP、端口和路由

即使 DNS 完全正确，某个目标 IP 或某类端口的流量仍可以被丢弃。实现可能是过滤规则、路由策略，也可能是其他网络设备的干预；仅凭用户端超时，不能断言背后一定用了“空路由”。

按 IP 阻断的优点是判断成本低。缺点是 IP 和网站不是一一对应：同一个地址可能承载很多域名，整段地址也可能属于一个大型云平台。封得越粗，越容易影响其他业务。

不过，误伤成本高，不等于不会封。 这是技术方案经常被宣传过头的地方。对方能接受多大范围的连带影响，属于封锁策略的取舍。

2.3 连接过程：TCP 重置、丢包与 UDP 限制

TCP 用握手建立连接，用序号、确认和重传维持有序字节流。路径上的干预者可以丢弃数据，也可能在满足接收条件时注入重置报文，让端点认为连接已中断。RST 并不需要先解密网页。

UDP 没有同样的 TCP 握手，但它也不是“没有规则的自由通道”：UDP 数据包仍然有 IP、端口和可观察的大小、时序，仍可以被限速或丢弃。QUIC 就建立在 UDP 之上，这个事实既带来设计空间，也带来对 UDP 可用性的依赖。

2.4 自报家门：HTTP Host 与 TLS SNI

明文 HTTP 请求中，域名、路径和内容可能直接暴露。HTTPS 把 HTTP 放进 TLS 保护之内，路径、请求正文等内容不再直接显示给普通路径观察者。

但普通 TLS 握手仍可能携带明文的 SNI（Server Name Indication，服务器名称指示），告诉服务端“我想访问哪个域名”。在同一 IP 承载多个网站时，这有助于服务端选择正确的站点。

TLS 1.3 加密了更多握手内容，包括服务端证书，但不自动加密最初的 ClientHello 中的 SNI。 所以“看不见网页正文”和“看不见访问域名”必须分开。TLS 1.3 标准与 ECH 标准的背景说明解释了这一边界。

2.5 行为：协议指纹、流量统计与主动探测

如果内容已经加密，识别并不会因此结束。观察者还可以分析握手结构、首批报文的字节特征、包长、方向、连接持续时间和出错时的反应。

另一种方法是主动探测：先发现一个疑似入口，再以探测客户端的身份连接它，观察是否出现某种特有响应。它像是先在路口看见一个可疑门牌，再亲自敲门试探。

这不等于“已经破解加密”，也不需要把一切归因于 AI。2023 年公开的一项研究分析了自 2021 年 11 月观察到的全加密流量封锁，发现该系统可以用相对简单的启发式规则，豁免像常见协议的流量，再处理剩余流量。这个结论应放在论文的测量范围内理解。研究论文

公开研究也说明，网络审查可能由多套机制共同组成。HTTP、TLS、DNS、QUIC 的名单、部署位置和行为未必一致。把它想成一台无所不知、对所有连接采用同一规则的机器，会妨碍理解真实现象。GFWeb，USENIX Security 2024

三、技术的发展史：从“请人转交”到“保护入口本身”

翻墙技术没有一个唯一的发明日期。代理、安全隧道、匿名通信和网络审查，原本就有各自的发展历史，后来逐渐交汇。

下面选取一些可以查证的节点。标准发表年份不等于技术首次出现的年份，论文发表年份也不等于其中测量事件发生的年份。

图 2：这些路线长期并存。时间线展示问题如何扩展，不表示旧技术被新技术依次淘汰。

时间线依据：SOCKS5、Tor 历史、Tor 设计论文、早期网桥阻断研究、域名前置论文、AWS 公告、Shadowsocks 2022 规范。其余标准及研究在下文对应章节列出。

3.1 第一条主线：从访问目标，转向访问一个中间人

最直观的办法，是找一个既能被自己访问、又能访问目标网站的服务器，请它转发。

这一步改变了网络路径。在受限制的那一段，外层连接的目标变成代理入口，而不是最终网站。但如果入口公开、固定、容易识别，封锁者可以转而阻断入口。

所以“再找一个代理”可以解决一次故障，却没有回答入口为什么会不断失效。

3.2 第二条主线：从保护内容，转向保护连接外观

安全隧道让路径上的人读不懂通信内容。随后，识别者开始利用“这看起来是什么协议”来决策，而不必知道里面说了什么。

抗封锁设计于是扩展到两个方向：一种让载荷尽量没有稳定的明文特征；另一种借用真实、常见的协议栈，让通信更接近普通网络活动。二者各有约束，不能简单说成“随机流量落后，HTTPS 流量先进”。

3.3 第三条主线：从单条连接，转向入口分发和整体运营

如果一个入口地址已被收集，协议再精巧也可能受到直接封锁。于是网桥、临时代理、分发渠道和共享基础设施变得越来越重要。

这也是为什么“我知道协议原理”仍不足以判断整个系统是否可靠。用户怎样获得入口，入口能用多久，失效后怎样恢复，和加密算法一样属于系统设计。

四、先看懂两层加密：隧道保护到哪里，HTTPS 又保护到哪里？

假设浏览器通过一个加密代理访问 HTTPS 网站，存在两段不同含义的保护：

1. 浏览器与网站建立的 HTTPS，通常一直延伸到网站的 TLS 终止点。
2. 设备与代理之间另有一层加密，用来承载前面的通信。

把它想成“装着密封信件的运输箱”会比较直观：代理打开运输箱后，里面的信仍然是封着的。

图 3：示意的是正常验证证书、代理只转发字节的连接。网站的 CDN 可能就是其 TLS 终止点；能够解密网页内容的中间服务不属于这个“只转发”的假设。

这个图可以回答三个常见疑问。

代理知道我要访问哪里吗？ 单跳代理通常需要目标地址才能建立出站连接，因而可能知道目标 IP；使用域名寻址或远端解析时，还可能直接知道域名。加密隧道把这些信息对路径观察者隐藏起来，并没有让代理自己失去路由所需的信息。

代理能看到我的 HTTPS 密码吗？ 在端点安全、证书验证正常、代理不终止网站 TLS 的前提下，单凭转发身份不能直接读到 HTTPS 正文。它仍可能观察目标、时序和流量大小。若安装了受信任的拦截证书、忽略证书错误，或者改用会代取并重写网页的服务，信任关系就变了。

既然代理连接加密了，目标网站可以用 HTTP 吗？ 隧道只保证它覆盖的那一段。流量离开代理之后，如果访问的是明文 HTTP，后续链路与出口仍可能看到或修改内容。多套一层隧道，不会自动为最后一段补上 HTTPS。

HTTP CONNECT 的标准模型就是建立双向转发隧道；它本身与隧道内是否运行端到端 TLS 是两个问题。RFC 9110，第 9.3.6 节

五、方式一：修复解析、加密 DNS 与 ECH

这组技术容易被混为“一键解决域名封锁”，实际分别作用于不同环节。

5.1 更换解析结果：针对地址错误

如果故障只有错误解析，取得正确结果确实可能恢复连接。然而，直接更换一个仍通过明文访问的 DNS 服务器，并不能保证查询路径不再受到干预；手工固定地址也会遇到服务迁移、负载均衡和共享站点等问题。

在 HTTPS 环境里，正确的网站名称还参与证书验证与站点选择。因此“知道 IP，直接把域名换成 IP”通常不是等价访问。

5.2 DoT 与 DoH：给查地址这一步加保护

DoT 用 TLS 承载 DNS，DoH 用 HTTPS 承载 DNS。它们在正确认证的前提下，可以减少客户端到所选解析器这一段的窃听和篡改。DoT：RFC 7858，DoH：RFC 8484

优点是针对明确、协议标准化，能够改善地址查询这一环的隐私。局限同样明确：解析器仍需要处理查询，解析器本身可能不可达，而且查到地址后，后面的 IP、SNI 和传输路径仍可能受限。

DNSSEC 也不是“加密 DNS”。 它主要验证 DNS 数据的真实性与完整性，不负责隐藏查询内容。拒绝一条伪造回答，与成功拿到一个可用回答，仍然是两回事。

5.3 ECH：把敏感的握手信息也放进信封

ECH，即 Encrypted ClientHello，用加密的内部 ClientHello 保护真实 SNI 等敏感字段，同时保留用于外层连接的公共信息。它在 2026 年 3 月正式成为 RFC 9849。

它的价值是减少直接按明文握手域名识别的机会。边界是：目标 IP、服务提供方、流量时序等并不会因此消失；明文 DNS 也可能从另一条渠道暴露域名。客户端、服务端、配置获取与部署方式需要共同配合，支持 TLS 1.3 并不代表已经成功使用 ECH。

适合怎样理解这组方案？ 它们像是修好地址簿、封好询问信件、减少握手时自报的信息。若道路本身被封，仍需要其他路径。它们是隐私与抗干预的组成部分，不能单独代表完整的通用翻墙系统。

六、方式二：HTTP／SOCKS 代理与网页中转

6.1 代理是一种转发职责，不是一种加密承诺

常见的 HTTP 代理与 SOCKS 代理，让应用把连接请求交给中间服务器。SOCKS5 是一个代理协议框架，包含寻址、命令与认证协商，不能仅凭“SOCKS5”这个名字就断定链路已被加密。RFC 1928

它们的优势是模型清楚、可以按应用使用、便于控制转发范围。局限是应用需要正确接入，未受保护的代理协商可能暴露目标，固定入口也可能直接被阻断。

还需要区分两个经常都被称为“HTTPS 代理”的概念：代理能够转发 HTTPS 网站，不一定意味着客户端与代理之间另有 TLS 保护。前者可能只是允许 CONNECT，后者才涉及外层代理连接的保护。

举个例子：浏览器先明文告诉代理“请连接某域名”，随后在代理建立的通道里与网站进行 TLS 握手。网页正文可以是加密的，但最初的目标声明仍然可能被观察。只有画清每一层连接，才能知道到底藏住了什么。

6.2 网页中转站与字节转发代理，信任边界不一样

有些服务让用户在一个网页里输入网址，由它代取页面再展示。这类服务使用方便，但可能需要解析、重写页面，甚至处理登录与脚本；它与浏览器直接向原站建立 HTTPS 的模型并不相同。

这种方式通常对复杂交互、跨域资源、实时连接和现代网站登录的兼容性较弱，且中转服务可能接触页面明文。它更像“请别人打开信件并转述”，不能因为用户到中转站之间有 HTTPS，就认定原站内容对中转方保密。

主要取舍： 普通代理的优势是简单和范围可控，弱点是默认不提供完整的抗识别能力，也不自动提供匿名性。网页中转还额外改变了谁在替用户处理内容。

七、方式三：SSH 隧道与传统 VPN

7.1 SSH 隧道：借用安全远程连接承载其他通信

SSH 的本来任务是安全远程访问，也有转发其他连接的能力。把应用通信放进 SSH 连接，可以保护到 SSH 服务端这一段，并由它继续连接目标。SSH 架构：RFC 4251

它的优点是边界明确、技术成熟，适合解释“先连到一个可信远端，再从那里出发”。但 SSH 自身具有可识别的协议行为，固定服务端也不因隧道加密而变得隐形；一个常见连接方式不等于为强审查环境专门设计的抗封锁方式。

7.2 VPN：把选定的网络流量接入一个虚拟网络

VPN 是一个比日常“翻墙软件”更宽泛的术语。企业站点互联、远程办公、私有网络访问，都属于它的重要应用。常见的安全 VPN 可以保护设备到网关之间的流量，并让网关处理后续转发；IPsec 是这类体系的重要代表。IPsec 架构：RFC 4301

VPN 并不必然接管所有流量。 是否全隧道、是否只传企业网段、DNS 怎么走、IPv6 是否覆盖，都由路由和实现决定。“全局”是流量策略，不是 VPN 三个字自带的属性。

它的优势在于适合网络级接入，能覆盖不主动支持代理的应用，且已有成熟的认证、密钥管理与运维体系。代价是对路由、MTU、DNS、设备权限及重连行为的处理更复杂。

7.3 密码学安全与抗封锁，是两条评价轴

一个 VPN 协议可以在密码学上很可靠，同时容易被识别。识别者可能不必解密任何数据，只需要判断“这是我决定阻断的协议”或“这是已知入口”。

2022 年研究者通过协议特征与主动探测研究 OpenVPN 的可识别性。这个案例说明了“有加密”和“难以分类”之间的距离，但不能把论文中针对特定配置的实验结果推广成“所有 VPN 在所有网络上都必然失效”。OpenVPN is Open to VPN Fingerprinting

主要取舍： SSH 与 VPN 很适合安全隧道和远程接入；如果任务包含抗封锁，还要另外评价传输外观、入口暴露和当地网络条件。企业 VPN 连接正常，也不意味着任意境外 VPN 都会有同样表现。

八、方式四：轻量加密代理与“看起来像随机数据”

专门的加密代理通常在设备端和远端之间建立受保护的转发通道。Shadowsocks 是这条路线的典型例子：本地组件接收应用流量，远端组件解密并连接目标。它可以向本地应用提供 SOCKS 接口，但跨网络的协议不能简单等同于明文 SOCKS5。官方原理说明

8.1 它试图解决什么？

直观目标是减少显眼的固定明文标记，让未掌握密钥的观察者难以直接读出目的地址和内容。相比完整虚拟网络，应用代理也可以有较清楚的处理范围。

这里“像随机数据”描述的是可观察载荷的设计方向，不是一个经过证明的“不可检测”保证。一段流量没有可读文字，仍可能在包长、握手、重放反应或统计分布上表现出规律。

8.2 为什么加密协议还要不断更新？

保密只是一部分，还需要验证消息没有被修改、区分合法与非法请求、限制重放、处理会话状态。Shadowsocks 的 AEAD 与 2022 版演进，就包含这类安全和工程改进。SIP022 规范

AEAD 可以理解为“加密同时带校验标签”：接收者不只拿到一堆解密结果，还要验证这条消息是否通过认证。但某个协议具备 AEAD，并不意味着重放处理、实现质量和抗探测行为也自动完善。

8.3 “什么都不像”也可能变成一种外观

想象一个门卫不认识所有可能的访客，但很熟悉送货员、住户和维修人员。他可以先放过这些容易确认的群体，再检查剩下的人。

某些流量分类也可以采用类似策略。2023 年的全加密流量研究提醒我们，避开已知明文签名，只解决了一类识别问题；与常见协议不同的统计表现，可能形成新的筛选依据。USENIX Security 2023

主要取舍： 轻量、便于转发与集成，是这类方案的吸引力；持续抗封锁则取决于协议版本、实现细节、入口地址及部署环境。不能只根据“加密强度”判断它能用多久。

九、方式五：TLS 封装与接近常见网络行为的传输

这条路线的思路是：既然“随机得很特别”也可能被挑出来，能否让连接使用真实、常见的协议机制？

9.1 真正使用 TLS，比把端口改成 443 多做了很多事

端口号只是门牌上的数字。把某个私有协议放到常见 HTTPS 端口，并不会让它自动变成 HTTPS。

基于 TLS 的代理传输则真的进行 TLS 握手，之后把代理请求放到加密通道里。有些设计还让未通过代理认证的连接进入普通 Web 服务，使主动连接入口的人不容易直接获得“这里运行了代理”的响应。Trojan 的协议文档就是一个典型设计实例。协议说明

这种设计可以减少简单探测的辨识力，但“有一个正常网页”不构成完整的不可区分性证明。服务端如何处理异常输入、客户端握手是否常见、连接持续多久、数据怎样成批发送，都可能影响观察结果。

9.2 TLS、HTTP、WebSocket 是不同层的东西

TLS 提供受保护的通道；HTTP 规定请求和响应的语义；WebSocket 提供一种可经 HTTP 握手建立的双向通信机制。可以把代理通信承载在这些机制中，但每多加一层，就增加一组要处理的约束。

例如，使用 Web 基础设施可能带来连接时限、中间代理缓冲、握手开销、流控以及额外的故障点。封装能改变外观或兼容性，不能无条件提高速度。

同样，使用真实 TLS，只能证明用了真实 TLS；是否像普通浏览器访问，还要看整段可观察行为。 审查者也可能完全不分析外观，只按已经收集到的入口地址进行阻断。

9.3 避免把“提高识别成本”说成“无法识别”

这类方案的优势，是借助广泛使用的协议栈，减少一些粗糙过滤规则的效果。局限是它需要维护协议行为、证书和服务端，且仍有元数据与入口暴露。

如果一个入口专门属于某个代理服务，封锁该 IP 未必会影响很多普通网站。只有实际共享了地址或基础设施，才可能出现更高的误伤成本；“外观像 HTTPS”本身没有制造这种共享关系。

主要取舍： 常见协议封装可能改善抗探测与网络兼容性，但增加实现和运维复杂度。可靠判断应来自明确的威胁模型与观测，而不是“完美伪装”“与浏览器完全一致”等宣传语。

十、方式六：CDN 中转与域名前置

10.1 CDN 中转并不自动等于域名前置

CDN 在客户端与源站之间提供共享接入、缓存或反向代理等能力。如果某种转发协议受平台支持，它可以借用这条路径。

域名前置（domain fronting）则有更特定的含义：连接不同层呈现的域名不同，路径观察者看到前置名称，而服务平台根据加密层内部的另一个名称选择后端。前提是平台确实允许这种路由行为。Fifield 等，PETS 2015

图 4：概念示意，不是可直接套用的服务配置。平台若检查域名、证书与账户归属，示意中的跨名称转发就可能被拒绝。

10.2 它为什么曾经有吸引力？

这类设计尝试把规避流量与大量正常业务放到共同的基础设施上。若外部很难只挑出目标连接，直接封锁前置平台就可能波及其他访问。

但平台能看到路由所需的信息，也能改变接入规则。AWS 在 2018 年公开宣布加强针对域名前置的限制，是一个明确的历史例子。AWS Security Blog，2018-04-27

因此，不能拿一篇旧教程中某个云平台的成功案例，推断今天任何 CDN 都支持这种用法。

10.3 它把哪些成本转移给了基础设施？

共享入口可能提高封锁成本，却也引入平台政策、带宽计费、账户稳定性、连接限制和服务故障等依赖。数据是否对 CDN 保密，还取决于 TLS 在哪里终止、其内部是否另有端到端加密。

主要取舍： 这条路线展示了“利用网络共享关系”与“单纯换一种加密算法”的区别。它的有效性不仅取决于密码学，还取决于商业平台愿意承载什么，以及封锁方愿意接受多少连带影响。

十一、方式七：Tor、网桥与临时代理

这一组技术必须把匿名网络内部怎样转发与用户怎样进入网络分开看。

11.1 多跳匿名：让不同节点只掌握一部分关系

在典型的 Tor 公网访问路径中，用户经由入口、中间和出口中继访问网站。分层加密使单个中继通常只掌握局部路径：入口接近使用者，出口接近目标，二者的信息分布不同。Tor 第二代设计论文

这种安排降低了对一个中间人的集中信任，却不能消除端点风险、身份登录或大范围流量关联。能同时观察两端的强观察者，仍可能根据时间与流量模式寻找关联。多个节点如果受同一方控制，也不能简单视为多个独立信任主体。

公网网站若使用 HTTPS，出口通常只转发加密内容；明文 HTTP 则会暴露给出口和出口后的路径。洋葱服务采用另一种通信结构，不需要普通公网出口，不能把公网浏览的出口模型照搬过去。

11.2 为什么还需要网桥？

匿名网络可以在内部提供分散信任，但用户首先必须连上它。若公开中继地址容易收集，入口就可能被阻断。

网桥的设计，是让部分入口不以普通公开中继名单的方式传播，并通过分发机制提供给用户。Tor 在 2007 年开始发展这条路线。网桥不是隐形服务器，泄露、枚举和主动探测仍然是问题。Tor 历史

可插拔传输进一步改变用户到入口的通信外观。它解决的是“怎样进入”，并不代替匿名网络内部的路径与信任设计。Tor 可插拔传输规范

11.3 Snowflake：把入口变成大量临时转发者

Snowflake 的系统设计使用大量临时 WebRTC 代理，由它们把受限制客户端的流量转发到网桥。其思路是降低成为临时代理的成本，并提高入口的数量和变化速度。Snowflake，USENIX Security 2024

图 5：虚线表示协调与发现，实线表示简化的数据路径；实际连接还涉及 NAT 穿透等机制。临时代理并不因为负责转发，就能解开内层 Tor 通信。

优势是入口更分散、更容易变化，难以只靠一份静态地址清单完整覆盖。代价是临时节点会离线，网络质量不一，建立连接需要协调，NAT 与 UDP 条件也会影响结果；网桥和协调系统仍然属于依赖。

因此，“临时入口很多”与“系统没有中心依赖”不是一回事。“用了 WebRTC”也不等于其全部行为就与普通音视频会话无法区分。

主要取舍： 多跳匿名网络更重视分散信任与降低关联，通常要付出更长路径和资源开销；网桥与临时代理提高的是入口韧性。它们可以组合，但不能用一个“速度快不快”的分数评价全部目标。

十二、方式八：基于 QUIC／UDP 的传输

12.1 QUIC 的价值首先在传输层

QUIC 把可靠传输、多路复用与安全握手结合在 UDP 之上。不同流的数据交付可以相对独立，避免一个流的丢包必然在传输交付层堵住另一个流；但多个流仍共享路径、带宽与拥塞控制，并不互不影响。RFC 9000

对于规避系统，这提供了新的传输选项，可能有利于多路复用、连接迁移或特定丢包环境。然而，网络若限制 UDP，这些优点就难以发挥；CPU 开销、MTU、实现质量和拥塞算法也会影响结果。

不能把“使用 UDP”简单解释为“更快”。没有公平、有效的拥塞控制，短时测速可能很好看，却给同一链路上的其他流量造成更严重的排队和丢包。

12.2 最初的 QUIC 报文，并不是一个只有双方能开的保险箱

QUIC Initial 包虽然经过包保护，其密钥却可以从公开连接信息导出。路径观察者可以恢复其中的初始握手信息；在没有额外保护相关字段的情况下，SNI 仍可能被提取。这是协议设计的边界，不是 TLS 后续应用数据的密钥被破解。RFC 9001，第 5 节

2025 年的研究分析了中国自 2024 年 4 月 7 日起出现的针对特定域名的 QUIC 封锁，其中包括对 Initial 的处理与 SNI 识别。它直接说明了“QUIC 天然无法按域名识别”这个说法不成立。Zohaib 等，USENIX Security 2025

12.3 传输表现好，未必意味着入口更难封

即使 QUIC 在某条线路上的吞吐更好，它连接的入口 IP 仍然可见。传输优化处理的是“怎样把数据送得更好”，抗封锁还需要处理“入口是否允许到达、行为是否被识别”。

主要取舍： QUIC 是有价值的传输积木。它是否适合某个场景，要分别评价 UDP 可达性、负载特征、拥塞表现与抗识别机制，不能从“新协议”直接推出“更强翻墙能力”。

十三、两条研究支线：不只是在服务器之间多绕一跳

13.1 利用端点与中间设备的解析差异

网络中间设备为了控制资源消耗，未必像真正的通信端点一样维护完整状态。对同一段报文，双方可能因为重组、顺序或协议解析方式不同而产生不同理解。

Geneva 等研究探索自动寻找这种差异，让端点能够完成正常通信，而干预设备没有按预期触发阻断。2019 年的原始研究及后续工作，可以从研究团队论文列表查看。

这种方向的吸引力是，某些情形下可能不必依赖传统远端代理；它的局限是对具体设备、路径和版本敏感，规则变化后可能失效，也不能普遍解决纯 IP 丢弃。这里介绍的是研究思路，不是一个跨网络通用的技巧。

13.2 把转发能力放进网络路径

Decoy Routing 则尝试把规避服务放到支持它的网络路径内部，让表面访问正常目标的连接在合适的位置获得转发能力，从而减少对某个显眼代理地址的依赖。FOCI 2011 原始论文

难点在于部署与路由：需要网络运营方参与，用户路径必须经过相应设施，还要考虑路径调整、覆盖范围和经济成本。这不是用户换一个客户端就自然获得的能力。

这两条路线说明，规避技术的设计空间不仅在密码算法里，也在协议实现和网络拓扑里。

十四、把不同方式放到同一张表里比较

下面比较的是技术思路的典型取舍，不是产品推荐，也不是对某个地区实时可用性的排名。表中的类型可以互相组合：一个系统可以用 TUN 接入流量、用加密代理转发、用 QUIC 传输，再通过临时入口改善可达性。

真正比较一个系统时，还可以逐项问：入口怎样分发？上游看到什么？出口知道什么？是否覆盖 DNS 和 IPv6？失败时怎样处理？它的可用性数据来自什么地方、什么时间？

一个诚实的比较，会保留这些条件。给所有协议打一个“抗封锁 95 分”的绝对分数，往往掩盖了最影响结果的部分。

十五、速度与稳定性：不能只看“节点延迟”

15.1 低延迟与高吞吐是两件事

延迟像是第一本书多久送到，吞吐像是整车书每秒能卸多少本。一个入口回得很快，不代表它到目标网站的后半段也快；一个下载很快的出口，也可能交互延迟很高。

页面首次打开的时间，还受到 DNS、连接建立、TLS 握手、目标处理、子资源数量和浏览器缓存影响。复用已建立连接后，一部分开销会消失，所以冷启动和持续传输不能只用同一个数字描述。

可以把链路容量粗略理解为：应用的有效吞吐受到最窄链路和最慢处理环节约束，再扣除封装、重传等开销。 这只是分析模型，不是精确测速公式。

15.2 多绕一跳有时更快，但不是免费加速

代理会增加转发环节，却也可能改变糟糕的原始路由。如果新路径的互联更好，它可能抵消甚至超过绕路成本。反过来，即使协议很轻量，入口拥挤、出口限速、丢包严重，也会让体验恶化。

因此，“用了代理反而更快”可以发生；它说明路径发生了有利变化，不能证明多一次转发普遍提高速度。

15.3 隧道层叠会改变丢包与排队行为

把一个可靠字节流套在另一个可靠字节流里，可能让外层丢包影响内层多个连接的交付；重传、排队与拥塞控制之间还可能相互作用。另一方面，多加封装也会占用 MTU 空间，过大的数据包可能引发额外分片或连接异常。

“加了三层加密”不是性能或安全的直接加分项。每一层都应有明确目的：保护哪一段、隐藏什么、由谁终止，以及它带来了什么新的故障点。

15.4 稳定性包含失效后的恢复

长期可用的系统，不只是某次能跑到高速度。它还需要处理入口下线、地址变更、网络切换、DNS 故障、握手失败和服务端资源耗尽。

评估稳定性时，应关注持续可用的比例、建立连接成功率、恢复时间及性能分布，而不是只展示一次最好的截图。更重要的是，同一环境里的重复观测，才有比较意义。

十六、谁能看见什么：信任不会因为换了 IP 就消失

下图对比单跳代理与典型多跳匿名路径，讨论的是传输可见性；浏览器账号、设备漏洞和恶意页面属于额外的识别渠道。

图 6：信息分散以中继没有协同串通、端点与协议正常工作为前提；不能据此推出对全局观察者绝对匿名。

在普通单跳加密代理或安全 VPN 中，可以用下面的表格检查信息流。

这张表有三个重要前提：所选流量确实进入了隧道；加密与认证没有被绕过；设备、浏览器和服务端没有被攻破。

“不记录日志”是运营承诺，不能改变服务端在实时处理时具备的可见性。 自建入口也只是改变了运营方和资源控制权，并不会让云主机、网络路径和固定地址不复存在。

“开源”有利于审查实现，不代表正在连接的服务一定运行同样的代码与配置。 软件透明度、部署透明度和运营可信度需要分别考虑。

“换 IP”更不等于换身份。 登录账号、已有 Cookie、浏览器特征以及主动提交的信息，都能跨网络路径关联行为。匿名性是端到端的使用与系统问题，不能只由一个代理开关承担。

十七、系统代理、TUN 与分流：它们在另一条坐标轴上

虽然本文不讲软件使用，但这三个词值得解释，因为它们经常被当成协议优劣。

系统代理主要是向遵循相关设置的应用声明“连接可以交给这个代理”。应用是否遵循、使用哪个网络库、是否另有专用连接，都影响实际覆盖。

TUN是一种虚拟网络接口机制，把网络层数据包交给用户态程序处理。它本身不是加密算法，也不是跨网络的代理协议。Linux TUN/TAP 文档

分流则是选择哪些目标或流量走哪条路径的策略。VPN 可以分流，应用代理也可以分流；是否全局与是否使用虚拟网卡，并不是同一件事。

所以，一个应用即使显示“已连接”，也不能据此推断所有协议、DNS、IPv6、局域网连接都已经过同一路径。TUN 能扩大接入范围，实际覆盖仍取决于路由、系统实现和例外规则。

这三个概念可以放进一条清楚的链条：接入机制决定怎样拿到流量，分流策略决定把它送到哪里，代理／隧道协议决定怎样与远端通信。

理解这条链，比记住某个界面的开关名称更有用。

十八、几个常见现象，怎样解释才不容易下错结论？

18.1 “换 DNS 后能打开了，所以之前一定只有 DNS 污染？”

未必。换解析器可能同时改变 CDN 选址和目标 IP，缓存、网络状态也可能变化。这个现象提供了线索，还没有排除所有其他解释。

18.2 “域名不通，IP 通，所以直接用 IP 就好了？”

IP 层能到达，只说明某个地址上有可响应的服务。HTTPS 的证书、SNI 和 HTTP 站点选择仍可能依赖域名。同一 IP 上的另一个网站可访问，并不意味着原站点也能完整访问。

18.3 “刚开始能用，后来失效，一定被主动探测了？”

主动探测是一种可能，此外还有入口地址被收集、服务端下线、网络拥塞、限流、证书过期与配置不兼容等原因。没有报文、服务端日志或独立测量，不能仅凭“过了一会儿”锁定机制。

18.4 “HTTPS 失败，就说明加密被破解了？”

连接可以在 DNS、IP、端口、SNI 或协议识别环节被阻断，完全不需要破解 TLS。反过来，TLS 成功也不能证明设备与网站都可信。

18.5 “所有海外网站都慢，所以都是审查？”

跨网互联、地理距离、拥塞、目标负载和应用自身都可能影响速度。要区分限制与故障，需要比较多个目标、协议、时间和观测点。OONI 的数据解释文档特别强调：异常测量不自动等于审查证据，应结合重复结果与具体失败类型判断。Interpreting OONI data

18.6 “有一个协议永远不会被封吗？”

任何依赖某条实际路径的系统，都受那条路径的控制条件约束。如果网络只允许很小的目的集合，甚至直接切断外部连接，再好的封装也不能凭空生成带宽和路由。

抗封锁技术通常是在可用性、误伤成本、识别成本和部署成本之间寻找空间。一个系统可以让精细封锁更难、更贵，却不能保证对方永远不采取更粗的措施。

十九、读懂一种新技术，可以沿着这六个问题往下问

1. 它改变了什么？ 是解析、路由、握手、数据外观、入口分发，还是信任结构？
2. 谁必须支持它？ 只需要客户端，还是远端服务器、网站、云平台、网络运营方也要配合？
3. 外界仍能看到什么？ IP、端口、域名、握手、时序、包长，各自被保护到哪一步？
4. 入口怎样被发现？ 对正常用户容易获得，对试图收集入口的人是否同样容易？
5. 代价放在哪里？ 延迟、带宽、CPU、平台依赖、维护工作或集中信任，哪一项增加了？
6. 证据覆盖什么范围？ 协议设计、实验室结果、某地测量和长期运营，是不同强度的证据。

以后再看到“最新协议”“完全隐形”“军用加密”之类描述，可以把它们翻译成这六个问题。能回答得越具体，才越容易判断它的实际价值。

翻墙技术的发展，是人们不断重新处理通信路径、可观察信息和信任分配的过程。它让我们看到，互联网中的“能到达”“能保密”“难识别”“难关联”分别需要怎样的条件。

把这些条件讲清楚，比给某个软件一个长期有效的冠军头衔，更接近技术本身。

参考资料与延伸阅读

以下优先采用协议标准、研究论文和项目的一手文档。正文中的插图为原创概念示意，不是抓包结果或性能测量；表格中的比较由这些机制推导，不代表实时连通性测试。

协议与系统基础

• RFC 1928：SOCKS Protocol Version 5（1996）
• RFC 4251：SSH Protocol Architecture（2006）
• RFC 4301：Security Architecture for IP（2005）
• RFC 7858：DNS over TLS（2016）；RFC 8484：DNS over HTTPS（2018）
• RFC 8446：TLS 1.3（2018）
• RFC 9000：QUIC（2021）；RFC 9001：Using TLS to Secure QUIC（2021）
• RFC 9110：HTTP Semantics，尤其 CONNECT（2022）
• RFC 9849：TLS Encrypted Client Hello（2026）
• Linux Kernel：Universal TUN/TAP device driver

历史与技术设计

• Tor Project：History
• Dingledine 等：Tor: The Second-Generation Onion Router（2004）
• Tor：Pluggable Transport Specification
• Shadowsocks：原理说明与 SIP022：2022 版协议
• Trojan：协议说明
• Fifield 等：Blocking-resistant communication through domain fronting（PETS 2015）
• AWS：Enhanced Domain Protections for Amazon CloudFront Requests（2018）
• Karlin 等：Decoy Routing（FOCI 2011）
• Geneva：原始及后续研究列表

测量与可用性边界

• Winter 与 Lindskog：How the Great Firewall of China is Blocking Tor（FOCI 2012）
• Hoang 等：How Great is the Great Firewall? Measuring China's DNS Censorship（2021）
• Xue 等：OpenVPN is Open to VPN Fingerprinting（USENIX Security 2022）
• Wu 等：How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic（USENIX Security 2023）
• Hoang 等：GFWeb（USENIX Security 2024）
• Bocovich 等：Snowflake（USENIX Security 2024）
• Zohaib 等：Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China（USENIX Security 2025）
• OONI：Interpreting OONI data