通信方式谱系
代理协议与抗审查传输变迁史
从通用代理与 VPN 隧道，到 Shadowsocks／SSR、HTTPS 代理、QUIC 与 Tor 抗封锁传输，沿着主要路线与关键代际，解释通信方式为何改变。
- 时间范围
- 1996—2026
- 收录节点
- 51 个节点
- 资料版本
- 第二版
组合结构
先分清协议、安全层与承载传输
认证、目标与转发
Shadowsocks、VMess、VLESS、Trojan、AnyTLS 等定义怎样请求代理。
加密并降低特征
认证加密、TLS、REALITY 与 ShadowTLS 等承担不同的保护或伪装职责。
真正搬运字节与数据报
TCP、WebSocket、HTTP/2、gRPC 与 QUIC 提供底层传输能力。
按类别快速定位 · 51 个节点
关键节点
从通用隧道到代理协议与抗封锁传输
安全与伪装 Finalmask 扩展可组合的流量外观处理
Xray v26.3.27 的发布说明记录 Finalmask 增加自定义头、Sudoku，以及迁入的 TCP 分片和 UDP noise，并扩展到更多传输组合。
Finalmask 是附加的最终伪装配置，不是新代理协议。这一节点说明 2026 年的演进仍包括流量外观与承载组合，而不只是增加协议名称。
VPN 与隧道 TrustTunnel 公开版本延续基于 HTTPS 的 VPN 路线
TrustTunnel 的现存发布记录包含 v0.9.74。项目说明该 VPN 协议源自 AdGuard VPN，支持 TCP、UDP 与 ICMP 流量，通过 HTTP 系列承载，并可提供系统隧道或本地 SOCKS5 入口。
日期指这个可验证版本，不是 AdGuard VPN 或其私有协议的起点；“类似 HTTPS”是设计方向，不能改写为无法检测的保证。
安全与伪装 Sudoku 探索可定制的低熵流量外观
Sudoku 发布 v0.0.1。项目说明使用 4×4 数独映射对字节流进行编码，使同一数据具有多种表示，并允许调整外部字节分布；后续形成代理实现与 Mihomo 支持。
核心创新是流量编码与混淆，完整代理实现还要承担认证、加密和目标转发。低熵或 ASCII 外观不等于自动安全或无法被检测。
代理协议 VLESS Encryption 加入可选的协议层加密
Xray 合入 VLESS Encryption，PR 描述了基于 ML-KEM-768 的密钥交换与 AEAD 加密设计，包括不同的 1-RTT 与 0-RTT 模式。
“VLESS 自身不加密”只能概括早期或未启用扩展的配置。此节点不代表所有 VLESS 实现自动获得加密能力，仍需核对版本、模式与双方支持。
代理协议 · QUIC ShadowQUIC 把 QUIC 代理与 JLS 伪装结合
ShadowQUIC v0.1.0 发布，列出 TCP Connect 与 UDP Proxy 支持。现行项目文档将其描述为结合 JLS 的 QUIC 代理，提供用户认证与独立协议说明。
ShadowQUIC、ShadowTLS 和 Shadowsocks 是不同项目与机制；共享名称片段不表示同一协议或版本关系。
代理协议 AnyTLS 发布以填充与连接复用为重点的参考实现
AnyTLS v0.0.5 的发布记录提供了早期公开版本依据。协议在 TLS 之上定义认证、会话、代理流与可调整的分包填充策略，设计目标是缓解 TLS in TLS 握手特征。
AnyTLS 是有自身认证与代理请求语义的协议，不能与 TLS 本身混称；项目的设计目标也不等于在所有网络中都能避免识别。
承载传输 SplitHTTP 演进为 XHTTP，上下行可以分别承载
Project X 维护者的 XHTTP 设计文章回顾 2024 年中出现的 SplitHTTP，以及随后加入上下行分离、流式上传和多种 HTTP 模式的过程。
日期采用这篇设计说明的发表日。XHTTP 是承载传输，可以与 VLESS、TLS 或 REALITY 组合；它不是取代这些不同层组件的新代理协议。
开放标准 CONNECT-IP 把 HTTP 隧道扩展到 IP 数据包
RFC 9484 定义经 HTTP 代理任意 IP 数据包的机制，补充仅面向 TCP 或 UDP 的代理语义。MASQUE 路线因此也覆盖 IP 隧道。
CONNECT-IP、CONNECT-UDP 与 HTTP/3 不处于同一层级：前两者定义代理或隧道语义，HTTP/3 提供 HTTP 的承载方式。
代理协议 · QUIC Hysteria 2 以标准 QUIC 和 HTTP/3 伪装重新设计
Hysteria 2.0.0 正式发布。协议规范要求基于 RFC 9000 QUIC 与不可靠数据报扩展，实现 TCP、UDP 代理，并要求服务端在未通过认证时表现为标准 HTTP/3 Web 服务。
Hysteria 2 与 Hysteria 1 的协议不兼容。它把代理语义、标准 QUIC 承载、HTTP/3 伪装和可选混淆层组合为一套新协议，而不是 1.x 的普通版本升级。
代理协议 · QUIC Juicity 扩展 QUIC 代理的实现路线
Juicity 发布 v0.1.0。项目明确说明其受 TUIC 启发，提供自己的 QUIC 代理协议与规范，关注 UDP 转发及 Go 客户端的一致性。
受 TUIC 启发不等于与 TUIC 协议兼容，也不直接证明代码 fork 关系；此处记录独立的协议与实现路线。
代理协议 · QUIC TUIC v5 发布与旧版不兼容的新实现
TUIC server 1.0.0 的发布说明指出：项目重构并拆分为四个 crate，基于 TUIC 协议版本 5，且与旧版本不兼容。
TUIC 0.1.0、软件 1.0.0 与协议 v5 不是同一套编号；仅列出 TUIC 首发会掩盖这次重要的协议代际切换。
安全与伪装 ShadowTLS v3 单独升级认证与完整性保护
ShadowTLS v0.2.14 加入 v3 协议；官方设计文档说明它调整认证与数据完整性校验，以处理此前版本的安全问题。
软件版本 v0.2.14 与协议版本 v3 是两个编号。官方明确 v2 与 v3 不能互通，v3 仍需要内层协议承担负载加密和代理请求语义。
安全与伪装 REALITY 作为独立安全与伪装层公开
REALITY 的初始说明在这一天公开，设计目标是让服务端借用目标网站的 TLS 特征和证书行为，减少独立代理站点暴露出的服务端特征，并可与 VLESS 等代理协议组合。
REALITY 不是负责目标转发语义的代理协议。常见配置“VLESS + XTLS Vision + REALITY”包含多个不同层级，不能简写成一个协议的代码血缘。
安全与伪装 XTLS Vision 将 TLS 内层识别与握手填充结合
Xray 1.6.2 加入 xtls-rprx-vision 实验流控：识别内层 TLS 1.3 流量，减少重复加密，并对内层握手长度进行填充，以缓解 TLS in TLS 的部分特征。
Vision 是流控与流量处理方式，不是 VLESS 的同级代理协议；也不能与后来公开的 REALITY 混为同一个安全层。
安全与伪装 ShadowTLS 通过真实 TLS 握手提供外层伪装
ShadowTLS v0.1.1 的公开发布记录标记了这条路线的早期实现。项目说明通过转接真实站点的 TLS 握手呈现有效证书，并在握手后转发内部流量。
ShadowTLS 不提供负载加密和代理请求封装，通常搭配 Shadowsocks 等加密代理；不能把它当作独立完成目标转发的代理协议。
开放标准 MASQUE 的 CONNECT-UDP 标准化 HTTP 中的 UDP 代理
RFC 9298 定义通过 HTTP 建立 UDP 隧道的扩展，把 HTTP 代理的能力从传统 CONNECT 的 TCP 转发扩展到 UDP。
MASQUE 是一组 HTTP 代理与隧道标准的工作方向，不是 QUIC 的别名；HTTP/3 与数据报扩展可以作为实现基础。
开放标准 HTTP/3 标准化在 QUIC 上承载 HTTP
RFC 9114 定义 HTTP/3，把 HTTP 语义映射到 QUIC 的连接与流上。它为基于 HTTP/3 的代理隧道以及 Web 服务外观提供共同基础。
HTTP/3 与 QUIC 不是同义词；Hysteria 2 的 HTTP/3 伪装、NaïveProxy 的 CONNECT 隧道也不代表二者使用相同的代理协议。
代理协议 SIP022 提出 Shadowsocks 2022 协议世代
Shadowsocks 官方仓库提交 SIP022 提案，引用 2022 Edition 规范。新世代调整密钥派生与请求头，要求完整的重放保护，并引入会话式 UDP 代理。
Shadowsocks 2022 是明确的新协议世代，不是给旧版 Shadowsocks 换一个加密方法名称；它也不等于 ShadowsocksR。
代理协议 · QUIC TUIC 发布首个 QUIC 代理协议实现
TUIC 发布 0.1.0。其协议目标包括以低往返开销转发 TCP 与 UDP、支持 UDP 会话，并利用 QUIC 的加密传输、多路复用、用户态拥塞控制与连接迁移能力。
TUIC 在 QUIC 之上定义代理命令和转发语义；两者不是可以互换的名称。当前协议规范已与具体实现分离，并由多个内核和客户端实现。
代理协议 Mieru 发布独立加密代理实现
Mieru 发布 v1.0.0。现行协议文档描述了基于 TCP 或 UDP 的加密通道、分段传输、填充及用户认证，客户端与服务端分别称为 mieru 和 mita。
它有自己的线上协议，不只是另一款 SOCKS5 客户端；SOCKS5、HTTP 是它向本地应用提供的入口。现行设计细节不全部倒推到首版。
安全与伪装 Snowflake 以 WebRTC 与志愿者代理扩展 Tor 接入
Tor Browser 10.5 将 Snowflake 作为稳定版网桥选项。Snowflake 使用 WebRTC 连接到志愿者运行的临时代理，再接入 Tor 网桥，使入口分发不再只依赖固定网桥地址。
这是稳定版集成日期。WebRTC 是通用通信技术，Snowflake 是使用它构成的抗封锁接入系统，两者都不等于 Tor 的匿名路由协议。
开放标准 QUIC 由 RFC 9000 标准化
IETF 发布 RFC 9000，把基于 UDP 的安全连接、多路复用流、可靠传输和连接迁移等能力定义为开放标准，为后续 Hysteria 2、TUIC 等代理设计提供共同承载基础。
QUIC 是通用传输协议，不是翻墙协议。代理工具可以在它之上定义认证、目标地址、TCP 转发和 UDP 转发语义。
代理协议 VMess AEAD 改变请求认证方式
V2Fly 4.28.1 的发布说明明确：alterId 为 0 时使用 VMess AEAD，并修复 AEAD IV 的使用问题。VMess 的历史因此不能只记录 2015 年的起点。
这是新认证方式的启用节点，不是新的独立协议名称；配置兼容性需要看 VMess 实现及版本。
代理协议 VLESS Preview 将代理语义与外层安全进一步拆开
V2Ray 在这一天合入 VLESS Preview。现行 Project X 文档将 VLESS 描述为无状态的轻量传输协议，并明确要求在不可信公网链路上配合外层传输安全或启用相应加密能力。
VLESS 负责认证与代理请求语义，TLS、XTLS 或 REALITY 等负责外层安全和伪装；因此“VLESS + REALITY”是组合关系，不是两个同级代理协议。
代理协议 · QUIC Hysteria 开始探索面向弱网的 QUIC 代理
Hysteria 发布首个公开版本。后续 1.x 文档把项目描述为基于定制 QUIC、面向跨境高延迟、拥塞或丢包网络优化的代理工具，并同时提供 TCP 与 UDP 转发入口。
这一方向把目标从“建立加密连接”进一步扩展到弱网吞吐和拥塞控制；早期 Hysteria 使用的是标准化完成前后的 QUIC 实现，不应倒推成当时已经采用后来的 Hysteria 2 协议。
承载传输 dnstt 把 DNS 隧道扩展到 DoH 与 DoT 递归解析器
dnstt 项目页记录这一天的首次公告。它利用递归 DNS 转发建立隧道，支持 DoH、DoT，并在隧道两端提供加密与认证。
DNS 隧道早于 dnstt。dnstt 提供本地与远端 TCP 端口之间的隧道，不自带 SOCKS 或 HTTP 代理接口；DNS 解析器仍能看见其中的 DNS 查询。
VPN 与隧道 WireGuard 1.0 随 Linux 5.6 进入主线
WireGuard 作者公告 Linux 5.6 已包含 WireGuard 1.0.0。这条路线以加密 IP 隧道为中心，和按应用连接转发的代理协议形成不同层级。
这是进入 Linux 主线的节点，不是 WireGuard 的发明时间；它本身也不提供把流量伪装成普通 HTTPS 的承诺。
代理协议 Snell 进入 Surge 的代理协议支持列表
Surge iOS 3.6.0 的官方更新记录明确加入 Snell。Surge 团队将其定义为轻量加密代理协议，后续版本继续扩展 UDP 转发与连接复用。
这里采用官方客户端支持日期，不推断为首次设计日期。Snell 的协议身份与实现是否公开是两个不同问题，不能因为缺少完整开源实现就漏掉协议。
代理协议 NaïveProxy 以 Chromium 网络栈探索 HTTPS 代理
现存发布记录中的 NaïveProxy v71.0.3578.98-1 在这一天发布。项目路线复用 Chromium 网络栈，在 HTTP CONNECT 隧道内增加填充，降低客户端握手和数据长度暴露出的差异。
这是可验证的公开版本节点，不是项目创建时间。NaïveProxy 是带有专用填充约定的 HTTPS 代理方案，不能简化为任意 HTTP/2 或 QUIC 连接。
开放标准 TLS 1.3 更新加密握手与安全传输基础
RFC 8446 标准化 TLS 1.3，更新客户端与服务端之间的握手和记录保护机制，为现代 HTTPS、QUIC 与多种 TLS 代理提供安全基础。
TLS 早于这个节点。TLS 1.3 是安全协议，不负责代理目标转发，也不保证使用它的代理连接无法被识别。
代理协议 Telegram MTProxy 公开专用代理实现
Telegram 官方 MTProxy 仓库在这一天建立，提供转发 Telegram MTProto 通信的专用代理，并在项目文档中说明代理密钥、连接方式和随机填充。
MTProto 是 Telegram 通信协议，MTProxy 是其代理实现；这一专用路线不能当作能代理任意网站的 SOCKS5 替代品。
代理协议 Trojan 把真实 TLS 握手与代理认证结合
Trojan 的协议文档在这一天加入仓库。客户端先进行真实 TLS 握手，再发送密码摘要、类似 SOCKS5 的目标请求与负载；不符合代理结构的连接可被转交给预设服务。
Trojan 是代理协议，TLS 是保护并承载它的安全层。把二者区分开，才能解释为什么“使用 TLS”并不意味着这些工具共享同一种代理协议。
代理协议 Shadowsocks AEAD 补上认证加密这一代演进
shadowsocks-libev 3.0.0 加入 SIP004 定义的 AES-GCM 与 ChaCha20-Poly1305 等认证加密方法，并弃用 OTA。Shadowsocks 的协议演进从早期流加密进入 AEAD 世代。
AEAD 同时保护机密性与完整性。它属于 Shadowsocks 的协议版本演进，不能直接与后来的 AEAD-2022 视为兼容。
承载传输 gRPC 1.0 发布，流式 RPC 成为另一种承载选择
gRPC 发布首个正式可用的 1.0.0 版本，提供流式远程调用机制。V2Ray 系列后来将 gRPC 用作代理数据的承载方式。
这里标记通用框架的正式发布，不是代理内核首次支持 gRPC 的日期；gRPC 不定义 VLESS 或 VMess 的代理语义。
承载传输 mKCP 用 UDP 承载可靠数据流
V2Ray 保留的 KCP 传输历史在这一时期持续改进缓冲与校验；V2Fly 文档把 mKCP 描述为以额外带宽换取较低延迟的 UDP 传输，并说明它对 KCP 的协议头、确认与连接状态处理进行了调整。
这是可核查的实现演进节点，不是 KCP 算法的发明时间。mKCP 属于承载传输，通常仍需组合上层代理协议。
代理协议 ShadowsocksR 的保留历史记录混淆插件扩展
ShadowsocksR 保留的历史提交在这一天加入 obfs 插件，后续形成分别配置加密方法、protocol 与 obfs 的路线，扩展了 Shadowsocks 的认证与流量外观处理。
引用的是后续维护仓库保留的原始提交，不把 2017 年仓库建立时间当作 SSR 的诞生时间；SSR 也不能与原版 Shadowsocks 或 Shadowsocks 2022 混用名称。
代理协议 VMess 随 V2Ray 的模块化体系出现
V2Ray 的初始提交提出自有 VMess 协议，并把协议、传输与路由组织为可组合模块。V2Fly 文档将 VMess 定义为 V2Ray 原生的加密通信协议。
这条路线强化了“代理协议不等于底层承载”的结构：同一种代理语义可以由核心配置到不同的传输和安全层之上。
安全与伪装 域前置把“借用公共云入口”系统化
研究论文系统描述了域前置：连接在外部可见的域名与加密请求内部指向的域名不同，借助内容分发网络等共享基础设施抵抗按域名封锁，并记录了 meek、Psiphon 与蓝灯中的部署。
域前置不是负责目标地址转发的代理协议，而是一种隐藏真实后端的抗封锁机制；它能与不同代理工具组合，也受云平台策略约束。
开放标准 HTTP/2 为多路复用代理承载提供基础
RFC 7540 发布 HTTP/2，在单一连接内使用多个并发流，并规定 CONNECT 在 HTTP/2 中的语义。它成为 NaïveProxy 和 gRPC 等路线的重要基础。
HTTP/2 不是独立翻墙协议；普通 HTTP/2 服务也不自动具有代理转发能力。
安全与伪装 obfs4 与早期混淆传输形成清晰代际
Tor Browser 4.5 引入 obfs4，并包含以 Go 重写的 obfs2、obfs3、ScrambleSuit。官方公告将 obfs4 的目标描述为提高对深度包检测和主动探测的抵抗能力。
此处日期是稳定版集成时间，不是所有这些传输的起源。obfs4 负责 Tor 网桥接入的流量变形，不替代 Tor 的匿名路由协议。
安全与伪装 meek 随 Tor Browser 4.0 进入稳定版
Tor Browser 4.0 加入三种 meek 可插拔传输，把 Tor 接入流量包装成 HTTP 请求，并利用共享 Web 基础设施建立连接。
这是稳定版收录节点。meek 是 Tor 的接入传输，域前置是它曾使用的机制；二者不是同义词，域前置也早于后来的论文发表。
代理协议 Shadowsocks 形成轻量加密代理路线
Shadowsocks 原始公开仓库在这一天建立。官方协议说明把它定义为受 SOCKS5 启发的安全分离式代理：本地组件接受代理请求，并与远端组件之间建立加密转发。
Shadowsocks 既有协议，也有服务端、命令行程序和图形客户端。这里关注客户端与服务端之间的协议语义，不重复应用或内核的项目史。
开放标准 WebSocket 提供可承载代理流量的双向通道
RFC 6455 定义由握手与消息帧组成的 WebSocket，在 TCP 上提供双向通信。代理实现后来可以把自身协议包装在这个通道内。
WebSocket 是通用承载协议，不定义代理认证和目标地址；WS 与 WSS 的区别也包含是否使用 TLS。
通用基础 SSH 连接协议标准化 TCP 端口转发
RFC 4254 定义 SSH 连接协议，在加密连接中复用会话，并支持 TCP 端口转发。它为通过远端主机转发网络连接提供了通用基础。
这是 SSH 连接协议的标准化节点，不是 SSH 的诞生日期。SSH 的主要用途是安全远程访问，不以隐藏代理流量特征为默认目标。
VPN 与隧道 IPsec 架构更新，IKEv2 定义认证与密钥协商
RFC 4301 更新 IP 层安全架构，RFC 4306 发布 IKEv2，用于相互认证以及建立、维护安全关联。这解释了系统 VPN 中常见的 IKEv2/IPsec 组合。
IPsec 早于 2005 年；此处是架构修订与 IKEv2 发布节点。IKEv2 管理安全关联，实际业务流量由 IPsec 机制保护。
VPN 与隧道 OpenVPN 1.0 加入 TLS 认证与密钥交换
OpenVPN 1.0 的更新记录明确加入基于 TLS 的认证和密钥交换，使加密 IP 隧道的会话建立方式继续演进。
TLS 在此承担认证与密钥协商，不表示 OpenVPN 的数据流就是普通 HTTPS；同样使用 TLS 的 VPN 与代理协议仍有不同的线上格式。
VPN 与隧道 OpenVPN 以 UDP 上的加密 IP 隧道起步
OpenVPN 官方保留的 ChangeLog 将 0.90 初版记在这一天，说明它通过 UDP 建立 IP 隧道，并使用加密与 HMAC 保护数据。
OpenVPN 是 VPN 协议与实现路线，不是 SOCKS5 式应用代理。首版尚未包含后来加入的 TLS 认证与密钥交换，不能把今天的完整能力倒推到 2001 年。
VPN 与隧道 L2TP 把二层 PPP 会话封装为隧道
RFC 2661 定义 L2TP，在中间网络上透明传送 PPP 会话。它与应用层代理的逐连接目标转发不同，是二层隧道机制。
L2TP 自身不提供负载机密性；常见名称 L2TP/IPsec 指隧道与 IPsec 安全保护的组合。
VPN 与隧道 PPTP 的 PPP 隧道规范公开
RFC 2637 以信息性文档记录 PPTP：通过 IP 网络承载 PPP，把 PPP 会话延伸到远端网络。它代表了早期系统 VPN 的一条路线。
PPTP 是隧道协议；该 RFC 明确不是互联网标准。收录用于解释 VPN 历史，不意味着推荐今天继续使用。
通用基础 HTTP CONNECT 记录通用隧道请求语义
RFC 2616 的 HTTP/1.1 文档记录 CONNECT 方法：请求代理切换为隧道，常见用途是经 HTTP 代理建立 HTTPS 连接。后来的 HTTP/2、HTTP/3 代理继续扩展这条路线。
这里采用 RFC 文档时间，不是 HTTP 代理的发明时间；CONNECT 本身不加密隧道内容，HTTPS 代理还需要 TLS。
通用基础 SOCKS5 成为通用代理协议基础
IETF 发布 RFC 1928，定义客户端如何通过代理请求 TCP 连接、监听端口或转发 UDP。后来许多本地代理端口与目标地址格式都沿用或借鉴了 SOCKS5。
SOCKS5 本身不负责加密，也不是为突破网络审查设计；把它放在这里，是为了交代后续代理协议经常承接的本地接口与请求语义。
收录原则
层级、来源与边界
本页覆盖公开可验证的主要协议路线与关键代际，包括通用代理、VPN 隧道、 专用代理与抗封锁传输，不是一份穷尽所有协议和实验方案的名录。 应用名称、内核名称、拥塞控制算法与本地网络接口不单独当作代理协议。
先判断层级
分别说明代理语义、VPN 隧道、承载传输及安全与伪装机制；名称相似不代表兼容或代码血缘。
原始资料优先
日期对应标准发布、版本发布、官方支持或保留的历史提交，不一律代表诞生时间。 仅能确认月份时只展示到月；现行设计也不全部倒推到早期版本。
不承诺绝对隐蔽
设计目标不等于在所有网络中无法识别；本站不把项目自述写成普遍保证。