代理协议推荐、使用条件与对比
按网络环境、客户端支持与部署前提比较协议和传输组合，不把单一测试结果扩大为普遍结论。
当前选型 · 编辑推荐
现在用什么协议？
先看使用场景，再选客户端支持的方案。评分针对下列具体组合，满分 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 提供底层传输能力。
按类别快速定位 · 52 个节点
协议与传输发展历程
默认最新在上。日期对应可核验的历史节点，不一定是协议诞生时间；点击条目查看完整说明、背景与来源。
20262 个节点
20255 个节点
ShadowQUIC 把 QUIC 代理与 JLS 伪装结合ShadowQUIC v0.1.0 发布，列出 TCP Connect 与 UDP Proxy 支持。现行项目文档将其描述为结合 JLS 的 QUIC 代理，提供用户认证与独立协议说明。
20241 个节点
20236 个节点
Juicity 扩展 QUIC 代理的实现路线Juicity 发布 v0.1.0。项目明确说明其受 TUIC 启发，提供自己的 QUIC 代理协议与规范，关注 UDP 转发及 Go 客户端的一致性。
20226 个节点
20213 个节点
20205 个节点
VMess AEAD 改变请求认证方式V2Fly 4.28.1 的发布说明明确：alterId 为 0 时使用 VMess AEAD，并修复 AEAD IV 的使用问题。VMess 的历史因此不能只记录 2015 年的起点。
20192 个节点
20182 个节点
20172 个节点
20162 个节点
20155 个节点
VMess 随 V2Ray 的模块化体系出现V2Ray 的初始提交提出自有 VMess 协议，并把协议、传输与路由组织为可组合模块。V2Fly 文档将 VMess 定义为 V2Ray 原生的加密通信协议。
HTTP/2 为多路复用代理承载提供基础RFC 7540 发布 HTTP/2，在单一连接内使用多个并发流，并规定 CONNECT 在 HTTP/2 中的语义。它成为 NaïveProxy 和 gRPC 等路线的重要基础。
obfs4 与早期混淆传输形成清晰代际Tor Browser 4.5 引入 obfs4，并包含以 Go 重写的 obfs2、obfs3、ScrambleSuit。官方公告将 obfs4 的目标描述为提高对深度包检测和主动探测的抵抗能力。
20141 个节点
20121 个节点
20111 个节点
WebSocket 提供可承载代理流量的双向通道RFC 6455 定义由握手与消息帧组成的 WebSocket，在 TCP 上提供双向通信。代理实现后来可以把自身协议包装在这个通道内。
20061 个节点
20051 个节点
20021 个节点
OpenVPN 1.0 加入 TLS 认证与密钥交换OpenVPN 1.0 的更新记录明确加入基于 TLS 的认证和密钥交换，使加密 IP 隧道的会话建立方式继续演进。
20011 个节点
19993 个节点
19961 个节点
收录原则 · 层级、来源与边界
收录原则
层级、来源与边界
本页覆盖公开可验证的主要协议路线与关键代际，包括通用代理、VPN 隧道、 专用代理与抗封锁传输，不是一份穷尽所有协议和实验方案的名录。 应用名称、内核名称、拥塞控制算法与本地网络接口不单独当作代理协议。
先判断层级
分别说明代理语义、VPN 隧道、承载传输及安全与伪装机制；名称相似不代表兼容或代码血缘。
原始资料优先
日期对应标准发布、版本发布、官方支持或保留的历史提交，不一律代表诞生时间。 仅能确认月份时只展示到月；现行设计也不全部倒推到早期版本。
不承诺绝对隐蔽
设计目标不等于在所有网络中无法识别；本站不把项目自述写成普遍保证。