基于代理服务器翻墙的工具与协议

现今最为可靠、使用最为广泛的翻墙手段就是使用代理服务器。

代理

代理（proxy）允许客户端通过代理服务与服务器进行非直接的连接，提供代理服务的电脑系统或其它类型的网络终端称为代理服务器。一个完整的代理请求过程为：客户端首先根据代理服务器所使用的代理协议，与代理服务器建立连接，接着按照协议请求对目标服务器建立连接、或者获得目标服务器的指定资源。一些代理协议允许代理服务器改变客户端的原始请求、目标服务器的原始响应，以满足代理协议的需要。

在阅读本文内容之前，强烈推荐事先对 OSI 模型这个概念建立初步的了解。

非加密类协议

非加密类代理是指不会对传输数据进行加密的代理，但无法有效对抗 GFW，因为所有数据在传输过程中都是明文可见的。这类代理主要用于局域网连通、用户访问控制、网络爬取等场景，并非为对抗审查而设计。但是，因为此类代理实现逻辑简单，通常很容易理解，这对于之后理解现代翻墙协议有非常大的帮助。

HTTP 代理

HTTP 代理接收并转发客户端的 HTTP 请求，主要经由以下步骤实现：

客户端浏览器向 HTTP 代理服务器发送访问请求，而不是直接发送到目标服务器；
代理服务器接收到请求后，使用自己的 IP 地址向目标服务器获取数据；
目标服务器将数据返回给代理服务器，代理再将数据转发给客户端浏览器。

HTTP 代理一般运行在应用层。

Socks 代理

Socks 代理的名字名字取自 SOCKetS，与只处理 HTTP 请求的 HTTP 代理相比更加通用。Socks 协议的最新版本 Socks5 可以处理包括 TCP 和 UDP、HTTP、FTP、SMTP 等在内的各种协议的流量。

Socks 代理运行在会话层。

VPN

VPN（Virtual Private Network，虚拟专用网）可以在客户端与 VPN 服务器之间创建一个加密的安全隧道，从而实现使在公共网络上的客户端能够访问到 VPN 服务器所在的专用网络中的内容（专用网络通常不直接对公共网络开放），就像将专用网络延伸到公共网络上，让客户端的设备直接连接到专用网络上一样。

VPN 最常见的使用场景是提供对内部网络的访问，例如需要访问企业内部资源的居家远程办公人员，或是需要获得校内网提供的服务的高校学生。VPN 也可以用于连接复数个局域网，例如将一个办公室的工作网络扩展到不同位置的办公室，或将一组工作网络扩展到一个数据中心。

VPN 通常只允许使用隧道协议和加密技术的认证远程访问，即使流量在数据包层面被嗅探到（遭遇深度包检测），攻击者也只能看到加密的数据。然而，常用的 VPN 协议由于并非为突破审查设计，本身的流量特征过于明显，非常容易被如今的 GFW 识别。不过，由于 VPN 曾被用作主流的翻墙手段，因此「VPN」本身也变成了翻墙或梯子的代名词。

广泛流行的 VPN 协议主要有：PPTP（点对点隧道协议）VPN、IPsec（互联网协议安全）VPN（通常与 L2TP（第二层隧道协议）搭配使用，称为「L2TP/IPsec」）、SSL/TLS（传输层安全）VPN（包括 OpenVPN 项目和 SoftEther VPN 项目）、DTLS（数据报传输层安全）VPN（包括 Cisco AnyConnect VPN 项目）、Secure Shell（SSH）VPN、WireGuard VPN 等。

传统的 VPN 通常运行在网络层或数据链路层，从而实现处理设备所有传出传入的网络流量（透明代理）的效果，不过一些以突破审查为目的设计的现代 VPN 为了实现精细的流量控制，也会运行在应用层、表示层或会话层。

全加密类协议

全加密协议对数据包有效载荷的每一个字节都进行加密以对抗 GFW 的审查。

Shadowsocks

Shadowsocks（SS）是一种基于 Socks5 代理方式的，用于突破 GFW 的封锁的加密传输协议，也可以指实现这个协议的各种开发包，或是由作者开发的配套服务器端和客户端工具。

SS 的运行原理与其他代理工具基本相同，使用特定的中转服务器完成数据传输，不过，SS 为了达到突破 GFW 的目的，设计了以下主要特性：

使用自行设计的协议进行全加密通信，加密算法有 AES-GCM、ChaCha20-Poly1305 等，允许用户自行选择加密算法。
引入配置文件（PAC）实现了网络分流，使得用户可以通过编写 PAC 文件指定特定的网站走代理或是走直连。
后续的版本中实现了对插件的支持，插件让 SS 的流量可以通过不同的插件进行混淆加密或其他特殊处理。
通过异步 I/O 和事件驱动程序运行，在运行时占用较少的系统资源，响应速度快。

SS 的原作者 Clowwindy 于 2015 年 8 月 22 日迫于警察压力停止维护 Shadowsocks，并删除了其托管在 Github 上的源代码。不过，这并未影响各类 Shadowsocks 衍生版本的发展。

Shadowsocks 客户端运行在应用层。

ShadowsocksR

ShadowsocksR（SSR）是 breakwa11 发起的 Shadowsocks 知名分支，其在 Shadowsocks 的基础上增加了一些资料混淆方式，称修复了部分安全问题并可以提高 QoS 优先级。

SSR 开始时曾有过违反 GPL、发放二进制时不发放源码的争议，使得原开发作者不满。不过后来 SSR 项目由 breakwa11 转为了与 Shadowsocks 相同的 GPL、Apache 许可证、MIT 许可证等多重自由软件许可协议。

2017 年 7 月 19 日，breakwa11 在 Telegram 频道 ShadowsocksR news 中转发了深圳市启用 SS 协议检测的消息，被大量用户转发进而引发恐慌。7 月 24 日，breakwa11 发布了闭源的 SS 被动检测程序，又引发了不少争议。7 月 27 日，breakwa11 遭到自称「ESU.TV（恶俗TV）」的不明身份人士人肉搜索，对方宣称如果不停止开发并阻止用户讨论此事件将公开作者个人信息。breakwa11 表示遭到人肉搜索的并非自己本人，为了防止对方继续伤害无关人士，breakwa11 删除了 SSR 在 GitHub 上的所有代码，并解散相关交流群组。

SSR 停止维护后，依然有不少基于 SSR 协议的延伸版本，例如较为知名的 ShadowsocksRR（SSRR）。

SS2022

SS2022 是 Shadowsocks 的另一条知名分支，在 2022 年发布，旨在解决旧版协议存在的安全问题，如 AEAD 加密漏洞和重放保护的缺失，也对代理性能做了提升。

尽管 SS 为了代理性能的提升做了很多努力，不过受限于其握手使用自行设计的加密套件，使得其代理性能天然不如使用现成的加密套件（如 TLS）的代理协议。

重放攻击

重放攻击（Replay attack）是一种恶意或欺诈的重复或延迟有效数据的网络攻击形式，是中间人攻击的一种。GFW 大量使用重放攻击实现对翻墙服务器的主动探测，具体详见墙的封锁手段 - 主动探测。

VMess

VMess 协议是由 Project V 项目原创并使用于该项目核心工具 V2Ray 的加密传输协议，如同 Shadowsocks 一样，是为了对抗墙的深度包检测而研发的。

VMess 采用加密技术以避免被检测和封锁。同时，为了实现身份验证并抵御重放攻击，VMess 基于用户 ID 和系统时间进行动态密钥交换，要求客户端和服务器之间的系统时间的误差保持在 90 秒以内。

VMess 是一个无状态协议，即客户端和服务器之间不需要握手即可直接传输数据，因此性能比起 SS 类协议有显著提升，不过其本身的协议标准混乱，存在一些兼容性问题。

2019 年，Project V 项目创始人 Victoria Raymond 突然在网络上失踪，V2Ray 社区在原作者失踪后重组成立了 V2Fly 项目。

TLS 类协议

TLS 类协议使用现成的 TLS 加密套件对流量进行加密，并使加密流量伪装成普通 HTTPS 流量以对抗 GFW 的审查。

VLESS

VLESS 协议是 Project V 开发的另一种网络传输协议，旨在改进和替代 VMess 协议。比起 VMess，VLESS 更加专注于数据传输的本身，简化了配置，并提高了性能。同时，VLESS 也通过支持用户添加扩展模块来实现数据的安全传输。

VLESS 保持了 VMess 无状态协议的特点，但不再依赖于系统时间同步，不过基于用户 ID 的验证特性依旧得到了保留。

由于 VMess 本身并不提供流量混淆的功能，因此要实现将流量伪装成正常的 HTTPS 流量以躲避审查，需要额外再用插件或前置代理等手段再套一层 TLS 加密来实现，这样会使得整个加密解密手段变得十分臃肿。而 VLESS 协议的本体虽然也没有流量混淆设计，但原生支持设置 TLS 模块来实现混淆。

XTLS

为了进一步提高使用 TLS 模块时的性能，Project V 社区的 RPRX 开发了 XTLS 来解决这个问题。

当代理软件使用基于 TLS 的代理浏览 HTTPS 网站时，流量其实经历了两层 TLS 加密：外层是代理的 TLS，而内层是网站本身的 TLS。然而这样的两层加密是没有必要的，即便只有单层 TLS 加密，GFW 也无法解密数据。因此，XTLS 就是在代理 TLS 流量时，在检测到客户端与目标服务器建立了 TLS 连接并且完成了握手后，将被代理的 TLS 流量原封不动地转发，而不会再经过代理的 TLS 加密。这样做可以极大地降低加密解密的运算开销，提高代理的性能，并且从外面看起来依然是一条普通的 TLS 连接。

然而，GFW 依然有可能通过其它的特征（如数据包的传输方向和长度等）识别出 TLS 套娃的代理行为。为此，XTLS 还推出了 XTLS Vision，以针对握手过程中较短的数据包进行填充，从而模糊数据包的长度特征，但是对于传输方向特征，XTLS Vision 并没有做处理，存在被 GFW 识别的风险。

2020 年 11 月，因为 XTLS 使用专有许可证，V2Fly 的 Debian 平台的软件包维护者与 RPRX 发生了围绕软件许可证适用的争议，最终 XTLS 社区投票决定在 V2Fly 移除 XTLS 协议。此后，RPRX 分叉了 V2Fly 项目，并改名 Xray，以便在其中继续提供 XTLS，区别于 Project V 的 Project X 也就此形成。

Trojan

Trojan 是一种结合了 Socks5 和 TLS 加密避开 GFW 的协议，使用 TLS 加密的 Trojan 流量与 HTTPS 流量的特征和行为高度相似。

Trojan 的巧妙之处在于，当 GFW 主动对 Trojan 服务器进行嗅探时，Trojan 会将非 Trojan 协议的流量代理到一个由用户设置的在同一个服务器上的正常的网页。在 GFW 看来，因为该服务器的行为和一个普通的 HTTPS 网站行为完全相同，因此难以判断其是否为 Trojan 代理服务器。

不过，Trojan 的流量虽然经过了 TLS 加密，但没有掩盖内层流量特征，GFW 可以通过分析 TLS 握手消息的固定长度、请求的目标域名等手段来对其实现识别与封锁。

Trojan 协议本身是由 C++ 实现的，后来衍生出了兼容性强、易用性更好的 Trojan-Go 等版本。此外，Trojan 协议本身也被整合进了如 V2Ray、Xray、Clash、sing-box 等更强大的代理工具中，形成了不少以 Trojan 为基础的混合代理方案。

NaïveProxy

NaïveProxy 使用 Chrome 的网络堆栈来伪装自身流量，在 GFW 面前的流量行为与 Chrome 与常见网页服务器（如 Caddy、HAProxy）之间通信的 HTTPS 流量是高度相似的。

NaïveProxy 的原理和 Trojan 差不多，因此都需要自行配置用于伪装的伪装网站服务器。

ShadowTLS

Trojan 为了有效实现对 GFW 的伪装，最好要由用户自己提供合法的域名与证书来搭建伪装网站，这使得 GFW 能够经过分析得知用户长时间大流量访问一个小众网站，而这本身就是一种异常行为。

为了解决这个问题，ShadowTLS 协议提供了一种全新的伪装方案：将代理流量伪装成前往第三方域名的流量（如某些大公司或机构的域名）。

当用户发起代理连接请求时，客户端会使用用户设定好的伪装域名来与其完成一次真正的 TLS 握手，然而，这只是给 GFW 做的一次表演，在握手结束后，客户端和服务端就会切换模式，使用 TLS 加密后的流量运行代理。由于用户可以设置任意域名作为伪装域名，因此也能解决诸如遭遇到 SNI 白名单之类的问题。

不过，尽管解决了伪装域名的可信度问题，ShadowTLS 存在着诸多可被探测的弱点，因为其本身是一个使用 Shadowsocks 和 TLS 加密的复合协议，与 Trojan 一样无法做到完美伪装 TLS 指纹。

Reality

Reality 是 Project X 开发的一种加密方案，与 ShadowTLS 相同，也能做到利用第三方网站的域名和证书实现伪装，不过，与 ShadowTLS 不同的是，Reality 实际上本身并非一种协议，而是经由 TLS 修改的，旨在模拟真实 TLS 数据包的传输层加密方案。

使用 Reality 进行代理时的服务端的行为特征与在访问用户设定的伪装目标网站（必须支持 TLS1.3 & HTTP/2）的反向代理（服务端双向转发流量至伪装网站）相同，使得 GFW 难以通过服务端 TLS 流量指纹分析来找出正在运行代理的服务端。

Reality 被设计为默认所有的客户端都是不可信的，比起使用对称加密的协议，Reality 拥有公私钥机制，使得在客户端配置泄漏的情况下，之前的传输内容也是不可见的，也无法明确 Reality 流量具体是哪一条连接。

Reality 常与 XTLS Vision 和 uTLS 一同搭配使用，以消除流量的 TLS 套娃特征与客户端 TLS 指纹特征（uTLS 使客户端能够模拟其他浏览器或工具的 TLS 握手）。

AnyTLS

AnyTLS 同样是一个解决 TLS 套娃问题的代理协议，与 XTLS Vision 的实现方案类似。TLS Vision 能针对握手过程中较短的数据包进行填充，不过填充的长度是无法被自定义的，而 AnyTLS 能够让用户自定义填充数据包的长度，从而进一步加大 GFW 识别 TLS 套娃流量的难度。

QUIC 类协议

QUIC 类协议充分利用 QUIC 协议的特性，在使用 TLS 加密的基础之上，更注重提升代理性能。

Hysteria

Hysteria 是经过修改的 QUIC 协议，QUIC 协议不仅天生基于 UDP 协议以提高 Web 性能和减少网络延迟，也自带 TLS 握手步骤，方便 Hysteria 代理伪装成正常的 HTTP/3 流量。

得益于 QUIC 的特性，Hysteria 协议能在服务端的线路不佳时，同样能发挥出较好的代理表现，相对地，由于 QUIC 允许在两个端点之间建立若干个多路连接传输数据，也更容易遭到 QoS 的限制（被服务商限速等）。

Hysteria 服务端可以像 Trojan 一样将自己伪装成一个由用户设置的在同一个服务器上的正常的网页，也可以像 Reality 一样作为一个第三方网站的反向代理运行。

TUIC

TUIC 与 Hysteria 同样，是基于 QUIC 协议修改的代理协议。

其与 Hysteria 的主要差异是，TUIC 通过充分利用 QUIC 特性追求更短的握手 RTT（0-RTT UDP 中继，1-RTT TCP 中继），以降低代理的延迟。另外，TUIC 还额外支持使用原生 UDP 中继传输数据（与 UDP 协议特性一致，但数据仍被 TLS 加密）。

工具

全局代理

蓝灯、赛风、自由门、VPN

Tip

前面的区域，以后再来探索吧！

GoAgent

GoAgent 主要利用 Google App Engine（GAE）的服务器作为代理服务器。

早期 GFW 在技术上难以完全封锁所有谷歌 IP 地址，或出于其他考虑并没有完全封锁某些 Google 服务，因此，若能找到未被封锁的谷歌 IP 地址，GoAgent 程序便可以正常使用。因此，GoAgent 默认不加密传输数据，仅使用 HTTP 或 HTTPS 方式连接代理服务器，但后续版本加入了 RC4 加密选项。

不过，自 2014 年 5 月底开始，Google 遭到 GFW 更大规模的屏蔽，可用的 IP 地址几乎已被封锁殆尽。2015 年 8 月，GoAgent 停止维护，并被原作者 phuslu 删除，原因与 Shadowsocks 受到警方的压力停更有关。

GoAgent 是开源软件，因此存在很多社区分支，如 XX-Net、GreatAgent、GoAgent+ 等。

GoAgent 运行在应用层。

模块化

V2Ray

V2Ray 是 Project V 项目的核心工具之一，能够通过多种协议实现数据加密传输，从而实现翻墙。它以高度可定制的平台为核心，支持多种入站、出站协议（如 VMess、SS、Vless 等），并提供强大的路由功能，允许用户根据规则自定义流量走向。