代理协议条目
当前选型 · 编辑推荐
现在用什么协议？
先看使用场景，再选客户端支持的方案。评分针对下列具体组合，满分 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。
VLESS + Vision + REALITY →
日常浏览、视频，希望兼顾流量特征处理与客户端选择。
通用直连优先看Hysteria 2 →
高延迟、丢包链路，以及需要同时转发 TCP 和 UDP 的应用。
UDP 通畅时的弱网候选NaïveProxy →
以网页和其他 TCP 流量为主，愿意维护浏览器网络栈与服务端。
重视浏览器流量外观AnyTLS + TLS →
希望使用 TLS、连接复用与可调整填充，且客户端已完整支持。
支持它的客户端值得考虑TUIC v5 →
UDP 通畅，且已有成熟 TUIC v5 客户端与服务端的场景。
QUIC 转发的另一选择VLESS + XHTTP + TLS →
确实需要 HTTP 反向代理、CDN 或上下行分离，能接受更多配置。
需要 HTTP CDN 时考虑Trojan + TLS →
已有稳定 Trojan 服务，或者更看重广泛的客户端兼容性。
优先兼容现有客户端Shadowsocks 2022 + ShadowTLS v3 →
已有 SS2022 使用需求，并且两端都支持 ShadowTLS v3 组合。
保留 SS 生态，增加 TLS 外观Shadowsocks 2022 →
希望使用简单的预共享密钥代理，且当前网络允许其流量外观。
轻量转发，按网络条件选Snell v5 →
主要使用 Surge，重视配套体验、错误提示和配置便利性。
Surge 用户按需选择Mieru →
希望使用独立的 TCP / UDP 代理设计，且愿意核对实现支持。
已有兼容环境时尝试