当前选择与通信方式谱系
翻墙纪 · 协议
先比较今天值得考虑的协议与组合，再沿着通用代理、VPN、HTTPS 代理、 QUIC 与 Tor 抗封锁传输的主要路线，了解它们为什么演变至今。
当前选型 · 编辑推荐
现在用什么协议？
先看使用场景，再选客户端支持的方案。评分针对下列具体组合，满分 5 分。
日常直连先看 VLESS + Vision + REALITY。
高延迟、丢包UDP 通畅时看 Hysteria 2 或 TUIC v5。
浏览器流量外观看 NaïveProxy；需要 HTTP CDN 时看 XHTTP 组合。
核对。 评分是基于公开设计、实现支持与维护成本的编辑判断，未做跨地区网络实测，不代表速度、连接成功率或安全认证。查看评分方法
按综合推荐分排序，同分不分先后。先满足网络与客户端条件，再比较分数。
11 个方案 · 筛选不改变评分VLESS + Vision + REALITY
通用直连优先看推荐评分4.5/ 5适合谁日常浏览、视频，希望兼顾流量特征处理与客户端选择。
使用前提与限制两端支持 Vision 与 REALITY，并正确配置密钥、目标站与名称。
这里评的是直连组合，不适用于普通 HTTP CDN；目标站与参数仍需维护。
评分依据、客户端与来源：VLESS + Vision + REALITY
抗识别设计5 / 5
REALITY 处理握手与探测，Vision 针对 TLS 套 TLS 的特征做填充和转发优化。多项设计有公开说明。
传输能力4 / 5
优化 TLS 流量转发，可结合 XUDP；底层仍走 TCP，丢包时受 TCP 重传影响。
客户端支持5 / 5
Xray、sing-box 与 Mihomo 均有 VLESS / Vision / REALITY 支持，客户端选择较多。
使用维护3 / 5
无需为 REALITY 单独购买域名和维护常规网站证书，但密钥、目标站及版本配对需要理解。
客户端与内核：Xray、sing-box、Mihomo 系客户端；具体应用需支持完整组合。
Hysteria 2
UDP 通畅时的弱网候选推荐评分4.5/ 5适合谁高延迟、丢包链路，以及需要同时转发 TCP 和 UDP 的应用。
使用前提与限制本项按常规 QUIC / UDP 配置评分，要求客户端到服务器的 UDP 通畅。
UDP 被封或限速时优势可能消失；带宽与拥塞控制需匹配线路。Mimic 等特殊传输另行评估。
评分依据、客户端与来源：Hysteria 2
抗识别设计4 / 5
协议定义 HTTP/3 服务行为与认证后的代理语义，可选混淆；这些机制不保证 UDP 流量不会被限制。
传输能力5 / 5
QUIC 多流、TCP / UDP 转发与可配置拥塞控制提供了较完整的传输工具。
客户端支持5 / 5
有官方跨平台实现，也被 sing-box 与 Mihomo 收录；应确认使用第二代协议。
使用维护4 / 5
官方配置文档完整，但需配置 TLS、开放 UDP，并合理选择带宽与拥塞控制。
客户端与内核：Hysteria 官方实现，以及 sing-box、Mihomo 等兼容实现。
NaïveProxy
重视浏览器流量外观推荐评分4.0/ 5适合谁以网页和其他 TCP 流量为主，愿意维护浏览器网络栈与服务端。
使用前提与限制使用兼容的 Chromium 网络栈实现及配套服务端；UDP 受限时使用 HTTP/2。
主要承载字节流。部分实现支持 UDP over TCP，需两端兼容；不等于原生 UDP 转发。
评分依据、客户端与来源：NaïveProxy
抗识别设计5 / 5
复用 Chromium 网络栈，结合 HTTP CONNECT、前置服务和长度填充，针对多类指纹与探测给出设计。
传输能力4 / 5
HTTP/2 或 HTTP/3 多路复用，适合流式应用；UDP 能力取决于额外封装和两端实现。
客户端支持3 / 5
跨平台可用，但集成真实网络栈有构建要求，不能把任意 HTTPS 代理当作 NaïveProxy。
使用维护3 / 5
需维护证书、配套前置服务，并跟进基于 Chromium 的稳定版本。
客户端与内核：官方 NaïveProxy 与明确集成其网络栈的客户端；sing-box 有平台及构建要求。
AnyTLS + TLS
支持它的客户端值得考虑推荐评分4.0/ 5适合谁希望使用 TLS、连接复用与可调整填充，且客户端已完整支持。
使用前提与限制使用维护中的兼容实现并验证 TLS 证书；两端支持相同的会话与填充机制。
默认填充只是示例；TLS 握手外观还取决于实现。UDP 通过 TCP 承载，受其重传影响。
评分依据、客户端与来源：AnyTLS + TLS
抗识别设计4 / 5
可调整包长模式以缓解嵌套 TLS 特征，但协议本身不负责全部 TLS 指纹处理。
传输能力4 / 5
会话管理与连接复用是设计重点；支持 UDP over TCP，但不是原生 UDP 传输。
客户端支持4 / 5
已被 sing-box、Mihomo 及多款客户端接入，仍需核对应用版本与实现细节。
使用维护4 / 5
兼容内核可统一管理 TLS 和代理；示例程序及默认填充不应被当成适合所有网络的成品配置。
客户端与内核：sing-box、Mihomo；官方说明另列了部分 Apple 平台客户端的支持情况。
TUIC v5
QUIC 转发的另一选择推荐评分4.0/ 5适合谁UDP 通畅，且已有成熟 TUIC v5 客户端与服务端的场景。
使用前提与限制两端明确支持协议 v5，常规 QUIC 配置要求 UDP 可达。
QUIC 不等于普通浏览器 HTTP/3；拥塞控制、UDP 模式及 0-RTT 配置需按实现核对。
评分依据、客户端与来源：TUIC v5
抗识别设计3 / 5
使用 TLS 加密的 QUIC 承载；规范重点是转发机制，并不将流量定义为完整的普通 HTTP/3 网站行为。
传输能力5 / 5
多流转发、UDP 数据报及会话管理较完整，实现提供拥塞控制与 UDP 模式选择。
客户端支持4 / 5
主流综合内核有兼容实现，但旧 TUIC 代际不能直接互通。
使用维护3 / 5
需核对协议代际、证书、拥塞控制及 UDP 转发模式，两端参数不能只靠协议名称判断。
客户端与内核：sing-box、Mihomo 等；协议 v5 与软件版本号不是同一件事。
VLESS + XHTTP + TLS
需要 HTTP CDN 时考虑推荐评分3.5/ 5适合谁确实需要 HTTP 反向代理、CDN 或上下行分离，能接受更多配置。
使用前提与限制两端支持 XHTTP；中间服务支持所选请求模式。UDP 受限时选 HTTP/2。
CDN 兼容性取决于模式、超时和服务规则。这里不将 Vision / REALITY 直连配置套在 CDN 上。
评分依据、客户端与来源：VLESS + XHTTP + TLS
抗识别设计4 / 5
HTTP 承载、头部填充和上下行分离提供多种流量组织方式；代理内容仍需安全层保护。
传输能力4 / 5
支持多种 HTTP 模式、连接复用与上下行分离，但中间服务会引入额外约束。
客户端支持4 / 5
Xray 和现行 Mihomo 文档均有支持，较旧客户端或订阅格式可能无法表达完整参数。
使用维护2 / 5
证书、域名、中间服务、请求模式和超时需要协同维护，排查链路更长。
客户端与内核：支持 XHTTP 的 Xray 或 Mihomo 系客户端，需确认应用内核版本。
Trojan + TLS
优先兼容现有客户端推荐评分3.5/ 5适合谁已有稳定 Trojan 服务，或者更看重广泛的客户端兼容性。
使用前提与限制正确校验 TLS 证书，按实现配置回落服务。
基础 Trojan 不包含 Vision 或 AnyTLS 的填充设计；使用 TLS 本身并不消除所有流量特征。
评分依据、客户端与来源：Trojan + TLS
抗识别设计3 / 5
真实 TLS 与失败请求回落有明确设计，但基础规范缺少针对嵌套 TLS 长度特征的专门机制。
传输能力3 / 5
支持 TCP 和封装后的 UDP 请求，基础转发能力完整，但仍受底层 TCP 队头阻塞影响。
客户端支持5 / 5
多个主流综合内核及独立客户端长期支持，迁移和接入选择较多。
使用维护4 / 5
配置相对成熟，需要持续维护域名、TLS 证书与回落行为。
客户端与内核：Xray、sing-box、Mihomo 及多款独立客户端。
Shadowsocks 2022 + ShadowTLS v3
保留 SS 生态，增加 TLS 外观推荐评分3.5/ 5适合谁已有 SS2022 使用需求，并且两端都支持 ShadowTLS v3 组合。
使用前提与限制SS2022 负责代理和负载加密；ShadowTLS v3 负责外层握手与流量外观。
ShadowTLS 不能单独当作加密代理；此组合的 UDP 转发路径需要另外核对。
评分依据、客户端与来源：Shadowsocks 2022 + ShadowTLS v3
抗识别设计4 / 5
ShadowTLS 使用真实站点参与握手，再承载 SS2022 加密流量；不能仅靠 SS 的随机字节流实现同样外观。
传输能力3 / 5
本项主要评价经 ShadowTLS 承载的 TCP 路径，不将 SS 原生 UDP 能力自动算作外层组合能力。
客户端支持4 / 5
主流综合内核有两个组件的实现，但需确认它们能按预期组合及使用 v3。
使用维护2 / 5
多一层服务、目标站及认证参数，排查时需要分别检查 SS 与 ShadowTLS。
客户端与内核：支持对应 SS2022 加密方式与 ShadowTLS v3 的 sing-box、Mihomo 系客户端。
Shadowsocks 2022
轻量转发，按网络条件选推荐评分3.5/ 5适合谁希望使用简单的预共享密钥代理，且当前网络允许其流量外观。
使用前提与限制两端使用相同的 2022 加密方式与合规密钥；不要与旧 SS 配置混用。
流量呈随机字节流，没有 HTTPS 外观；规范明确不提供前向保密。
评分依据、客户端与来源：Shadowsocks 2022
抗识别设计2 / 5
随机字节流与重放保护有明确规范，但不模拟网站 TLS / HTTP 行为。
传输能力4 / 5
支持 TCP 与独立 UDP 会话，协议开销较精简；不自带 QUIC 的传输控制。
客户端支持4 / 5
多个实现支持 2022 代际，但仅标注“支持 SS”的旧客户端可能不兼容。
使用维护4 / 5
无常规证书续期负担，需要正确管理预共享密钥并确认加密方式一致。
客户端与内核：支持 AEAD-2022 的 Shadowsocks 实现、sing-box、Mihomo 等。
Snell v5
Surge 用户按需选择推荐评分3.5/ 5适合谁主要使用 Surge，重视配套体验、错误提示和配置便利性。
使用前提与限制本项以官方稳定下载 v5.0.1 为依据；客户端支持协议 v5。
官方明确取舍了前向保密和专门的重放保护。v5 的 QUIC Proxy 仅针对 QUIC 流量，v6 仍列为测试版。
评分依据、客户端与来源：Snell v5
抗识别设计2 / 5
v5 主要着重低开销转发，不将 v6 测试版的协议多样化能力计入稳定版评分。
传输能力4 / 5
动态记录大小、连接复用与针对 QUIC 的转发模式提供性能机制；其他 UDP 仍经 TCP。
客户端支持4 / 5
有 Surge 官方配套及 Mihomo 兼容支持，仍需确认版本和特定扩展能力。
使用维护5 / 5
官方提供单文件服务端与向导，配套客户端有明确错误反馈，维护步骤较少。
客户端与内核：Surge；Mihomo 文档也列有 v5 支持，扩展能力需分别核对。
Mieru
已有兼容环境时尝试推荐评分3.5/ 5适合谁希望使用独立的 TCP / UDP 代理设计，且愿意核对实现支持。
使用前提与限制使用 Mieru 官方实现或兼容客户端；UDP 受限时选择 TCP 传输。
自有加密与填充不等于 HTTPS 外观；不同实现的握手、复用与流量配置需匹配。
评分依据、客户端与来源：Mieru
抗识别设计3 / 5
自有认证加密与填充方案有文档，但不使用 TLS，也不能据此推断真实网络的抗封锁率。
传输能力4 / 5
同时提供 TCP 和 UDP 传输设计，兼容实现提供复用与握手模式选择。
客户端支持3 / 5
已有官方实现及 Mihomo 支持，通用客户端覆盖仍比 VLESS / Trojan 少。
使用维护3 / 5
需管理两端传输、认证、握手与流量参数，并核对各实现跟进情况。
客户端与内核：Mieru 官方实现、Mihomo 等已明确提供该协议的客户端。
这份推荐分是怎么算的？
以个人日常代理选型为范围，四项各给 1–5 分，2 分和 4 分表示相邻档位之间。 综合分 = 各项分数 × 权重后相加，四舍五入到 0.5 分；同分不分先后。 网络前提不满足时，再高的分数也不适用。高分表示更值得在所列场景中考虑，不表示更难被封锁的实测结论。
抗识别设计35%
看公开设计如何处理握手、探测与流量特征；不代表实测抗封锁率。
1 分：缺少针对性设计；3 分：有部分措施；5 分：有多项具体且公开的应对机制。
传输能力25%
看 TCP / UDP 转发、复用与弱网机制；网络能否连接另列为使用前提。
1 分：用途受限；3 分：满足常规转发；5 分：TCP / UDP 能力及传输控制较完整。
客户端支持25%
看现有内核、客户端与平台支持；支持内核不等于每个应用都已更新。
1 分：实现很少；3 分：有可用实现但选择受限；5 分：多个主流内核与客户端支持。
使用维护15%
看部署步骤、证书、版本配对与日常维护负担；越省心分数越高。
1 分：复杂或实验性强；3 分：需维护若干组件或参数；5 分：配置与维护较简单。
每项评分是本站编辑判断；引用用于核对机制与支持情况，原作者并未给出这些分数。线路质量、服务器负载、IP 可达性与配置都会改变实际体验。
其他协议怎么选？
- WireGuard / OpenVPN / IKEv2
- 适合 VPN、远程接入和组网，目标与本表的日常抗审查代理选型不同，暂不混入评分。参见 VPN 历史与官方资料。
- Tor obfs4 / Snowflake / meek
- 用于接入 Tor；需要 Tor 的匿名路由时再按其接入条件选择。参见 Tor 传输与官方资料。
- SOCKS5 / HTTP CONNECT / MTProxy
- 前两者常用作本地接口或代理基础能力；MTProxy 服务于 Telegram。用途不同，不能单凭名称替代本表中的完整组合。参见 通用代理、MTProxy。
- VMess AEAD
- VMess 需区分旧认证方式与 AEAD，不能因协议出现较早就一概归为旧方案。 选型还要看搭配的传输、安全层及两端实现；已有稳定环境可继续按需使用。参见 VMess AEAD 的代际说明与官方资料。
- VMess AEAD + HTTPUpgrade + TLS
VMess 负责代理认证与转发，HTTPUpgrade 负责 HTTP/1.1 升级后的连接承载，TLS 提供外层保护。适合两端支持完整组合、使用兼容 CDN 或 Nginx 反代且线路实测稳定的环境；需校验 TLS 证书，并确认中间服务的升级请求支持、超时和服务规则。
Xray 官方 HTTPUpgrade 文档说明它省去 WebSocket 的其他协议部分，可减少封装开销，并提示流量特征、 建议换用 XHTTP。未启用 ECH 时，握手中的 http/1.1 ALPN 是其提示的特征之一；启用 ECH 后需区分内外握手，见下方说明。 这些设计差异不能直接推导出跨线路速度或抗封锁率排名。
暂不评分：尚未完成与上表同等的组合兼容性及维护评估，也没有跨线路对比实测。 具体体验取决于线路、CDN、客户端与配置；支持 VMess 不等于支持 HTTPUpgrade。参见 Xray 官方 VMess 配置文档。
- HTTPUpgrade + ECH + Cloudflare
ECH 加密部分 TLS 握手信息，保护客户端到 Cloudflare 边缘这一段的真实 SNI。需客户端实现与版本支持 ECH、站点边缘启用 ECH，并取得有效的 ECHConfig；只打开站点开关不能证明客户端已成功协商。Cloudflare 官方说明也指出，网络中间方仍可看出连接到了 Cloudflare。
Xray 现行 TLS 文档明确：其 uTLS 实现启用 ECH 时，外部 ALPN 显示为 h2,http/1.1， HTTPUpgrade 的 http/1.1 放在加密的内部握手中。 因此不能继续把该内部值当作明文可见特征；这也不代表流量大小、时序等特征全部消失。
ECH 提供握手隐私，不增加 CDN 配额或改变服务规则，也不保证提速、连接成功或免于封锁。 它不负责 Cloudflare 到源站这一段的安全配置；DNS 查询的隐私也需另行考虑。 本页不据此提高组合评分。
- SSR / 旧版 Shadowsocks / Hysteria 1
- 历史和兼容记录继续保留。已有稳定环境可按需使用；新选型优先核对本表中当前代际和兼容实现，不因历史收录而默认推荐。参见下方各代际的原始资料。
- ShadowQUIC / Sudoku / TrustTunnel 等新方案
- 已有公开实现，继续在历史中记录。本轮尚未建立与上表同等的兼容性与维护评估，暂不评分；不据发布时间推定优劣。参见 ShadowQUIC、Sudoku、TrustTunnel。
组合结构
先分清协议、安全层与承载传输
认证、目标与转发
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 隧道、承载传输及安全与伪装机制；名称相似不代表兼容或代码血缘。
原始资料优先
日期对应标准发布、版本发布、官方支持或保留的历史提交，不一律代表诞生时间。 仅能确认月份时只展示到月；现行设计也不全部倒推到早期版本。
不承诺绝对隐蔽
设计目标不等于在所有网络中无法识别；本站不把项目自述写成普遍保证。