2026 年还在用的协议：VLESS+Reality、Hysteria2、AnyTLS 到底解决了什么

先说结论

节点名后面那串协议名到底该选哪个——这篇给你判断依据，不教你怎么搭服务器。

一、它们解决的不是同一个问题，所以没有「最好」。 一句话版：Reality 管的是服务端 TLS 指纹和证书从哪来；Hysteria2 管的是丢包链路上的速度；AnyTLS 管的是嵌套 TLS 的包长和握手特征。选错方向，换了也白换。

二、没有任何一个能「不被检测」，这些项目自己也没这么说。 XTLS/REALITY 的仓库里明写 TLS in TLS 特征「明显且已被针对」；AnyTLS 的官方 FAQ 有一整节「已知弱点」列了十条。第二节把学术界已发表的检测成果摆出来。

三、Hysteria2 快不快，取决于你的网络怎么对待 UDP。 它的固定速率拥塞控制在丢包链路上占优，但如果你的运营商对 UDP 大流量限速，它会更慢。

四、AnyTLS 的参考实现自己说它不是生产级的。 anytls-go 的 README 原文：它「是 AnyTLS 协议的参考实现」，目标是「演示协议细节」而「非提供功能完备的生产级客户端」。日常用的是 sing-box、mihomo 这类第三方实现。

五、维护状态各不相同，这是选之前该看的。 第六节有一张按 GitHub 接口在 2026 年 9 月 21 日当天查到的版本与日期表。

六、结论是备两种，不是挑一种。 原因在第八节。

本文的边界：所有协议事实来自各项目自己的仓库和官方文档，2026 年 9 月 21 日当天获取；版本和发布日期来自 GitHub 接口。所有关于「能不能被检测出来」的说法，只引用已公开发表的审查测量研究。我们没有做任何测量，也不复述任何「实测存活率」。

一、先把问题分开

在比较之前，先看清这三者分别站在哪个战场上。代理流量被识别，大致有三条独立的路：

三条路互相独立。一个协议在第一条路上做得好，不代表它在第三条路上有优势——这是理解这三个名字的关键。至于 GFW 在技术上具体怎么做，背景见 GFW 技术手段解析。

二、检测这件事，已发表的研究说到哪一步

这一节先摆事实，因为它决定了后面每一段该用什么语气。以下三项都是同行评审后公开发表的成果。

① 全加密流量的识别（USENIX Security 2023） 论文《How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic》发现，GFW 使用「crude but efficient heuristics」（粗糙但高效的启发式规则）而不是精确定义。其中一条基于熵：按位计数作为熵的粗略度量，当置位比特的比例平均落在每字节 3.4 到 4.6 之间时连接会被阻断，因为「随机（加密）数据会有接近一半的比特为 1」。另有若干豁免规则（前六个字节是可打印 ASCII、超过一半是可打印字符、连续 20 个以上可打印字节、TLS 与 HTTP 协议指纹等）。研究基于 17 亿条真实连接估算，这些规则会阻断约 0.6% 的 TCP 连接，而 GFW 把它限制在特定机房 IP 段上，实际影响约 26% 的连接。

这解释了一件事：早期那些「看起来完全随机」的协议为什么会被针对——恰恰是因为太随机。

② 嵌套 TLS 握手的指纹识别（USENIX Security 2024） 密歇根大学 Diwen Xue、Merit Network 的 Michalis Kallitsis、UMass Amherst 的 Amir Houmansadr 与密歇根大学的 Roya Ensafi 发表的《Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes》，提出一种与具体协议无关的检测思路：利用一切代理活动共有的「嵌套协议栈」特征，把被封装的 TLS 握手从加密流里分离出来。他们在一个服务百万级用户的中型 ISP 内部署了检测框架，证明即便加了随机填充和多层封装，被代理的流量仍能被可靠识别，且误伤很小。

论文对防御方的结论尤其值得引用：多路复用「shows promise as a viable countermeasure」（是有希望的对抗手段），但仅靠多路复用和随机填充「inherently limited」（存在固有局限），因为它们无法充分「reduce the size of traffic bursts or the number of round trips within a connection」（减少流量突发的大小或连接内的往返次数）。作者建议代理开发者「应当意识到这些局限，预期审查者会利用被封装的 TLS 握手」。

这篇论文正是 AnyTLS 存在的理由——也同时说明了它做不到什么。

③ QUIC 的 SNI 审查（USENIX Security 2025） 《Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China》发现，GFW 自 2024 年 4 月 7 日起开始按域名阻断 QUIC 连接：它大规模解密 QUIC Initial 包、应用过滤规则，并维护一份独立于 TLS／HTTP／DNS 的封锁列表（域名数约为 DNS 列表的 60%）。研究期间测得 Tranco 榜单中 58,207 个 FQDN 在 QUIC 上被封锁。

这条直接关系到 Hysteria2：QUIC 首包不是黑盒，审查方能读。

一句话总结这一节：没有一个协议处在「检测不到」的状态，区别在于当前针对它的成本有多高、以及针对它会误伤多少正常流量。任何说某协议「绝对安全」的内容，都比这些项目自己的说法更乐观。

三、VLESS + Reality：借一张真证书

它想解决什么

用 TLS 伪装的代理有两个老问题：你得有一个域名和证书，而且你那台服务器的 TLS 指纹是你自己的——它和真实网站不一样，也和其他用同款软件的服务器一模一样。

Reality 的思路是：不自己做 TLS 服务端，而是把握手指向一个真实存在的第三方网站。按 XTLS/REALITY 仓库的原文：

「若用 REALITY 取代 TLS，可消除服务端 TLS 指纹特征，仍有前向保密性等，且证书链攻击无效，安全性超越常规 TLS」

「可以指向别人的网站，无需自己买域名、配置 TLS 服务端，更方便，实现向中间人呈现指定 SNI 的全程真实 TLS」

客户端一侧用 uTLS 库模拟浏览器的 TLS 指纹，仓库里写明默认模拟 chrome。

代价和边界

仓库本身把限制写得很清楚，这几句话比任何第三方评测都可信：

• 目标网站有硬性要求：「国外网站，支持 TLSv1.3 与 H2，域名非跳转用」。加分项包括 IP 相近、Server Hello 之后的握手消息一起加密、有 OCSP Stapling。选错目标站，伪装就是失败的。
• TLS in TLS 特征仍在：仓库原文——「REALITY 也可以搭配 XTLS 以外的代理协议使用，但不建议这样做，因为它们存在明显且已被针对的 TLS in TLS 特征」。也就是说，Reality 解决的是服务端指纹，不是第二节②那篇论文讲的流量形态。
• 有些配置项本身就是特征：仓库在讲回落限速参数时直接写「回落限速是一种特征，不建议启用」，并要求一键脚本开发者务必随机化这些参数。这说明伪装质量高度依赖部署细节，而这些细节你作为用户看不到。
• 客户端如果收到的是目标网站的真证书（而不是临时可信证书），意味着服务端拒绝了握手、或者中间有人把你重定向了——Reality 客户端会据此进入爬虫模式或直接断开。

对你意味着什么

• 它在握手层做得好，适合你的链路对 TCP 友好、但对可疑 TLS 握手敏感的环境。
• 它不解决速度问题，也不解决丢包问题。
• 你无法从节点名判断它配得好不好——目标站选得烂的 Reality 节点，和配得好的 Reality 节点，在你的客户端里长得一模一样。

四、Hysteria2：把速度问题和审查问题分开看

它想解决什么

按官方中文文档的原文，Hysteria 2「基于魔改的 QUIC 协议」，目标是「即使在最不稳定和容易丢包的网络环境中也能提供无与伦比的性能」。项目 README 的英文表述是「Powered by a customized QUIC protocol, Hysteria is designed to deliver unparalleled performance over unreliable and lossy networks.」

关键在它的拥塞控制。官方文档描述 Brutal：

「Brutal operates on a fixed rate model and does not reduce its speed in response to packet loss or RTT changes」（Brutal 按固定速率模型工作，不会因为丢包或 RTT 变化而降速）

这就是它在丢包链路上明显好过 TCP 的原因——TCP 遇到丢包会主动退让，Brutal 不会。

代价和边界

同一份官方文档给出的限制同样直白：

• 必须准确填带宽：Brutal「this only works if you know (and accurately specify) the theoretical maximum speed of your current connection」（只有在你知道并准确指定当前连接的理论最大速度时才有效）；并且警告「DO NOT set it higher than what’s possible, as this will result in a slow, unstable connection and wasted data」（不要设得比实际可能的更高，否则会导致连接缓慢、不稳定并浪费流量）。填错了会更慢，这是最常见的误用。
• 服务端带宽限制只对 Brutal 生效：文档明写「The server’s bandwidth limit only applies to Brutal at the moment. It has no effect on BBR or Reno.」
• 伪装依赖配置：文档说明 masquerade 让服务器像普通 Web 服务器一样回应 HTTP 请求，是其抗审查能力的关键之一；如果不配 masquerade，Hysteria 会对所有 HTTP 请求一律返回 404 Not Found——这本身就是一个可被识别的行为。
• 它跑在 UDP 上。项目自称协议「旨在伪装成标准的 HTTP/3 流量，无论中间人还是主动探测，都很难分辨和封锁」——这是项目的说法。把它和第二节③那篇 2025 年的论文放在一起读：GFW 已在大规模解密 QUIC Initial 包并维护独立封锁列表。所以更准确的表述是：它把自己放进了 HTTP/3 这个庞大的正常流量池里，代价是误伤成本，而不是「看不见」。

对你意味着什么

• 你的链路丢包多（移动网络、跨境拥堵时段）→ 它通常明显更好。
• 你的运营商对 UDP 大流量限速 → 它会比 TCP 类协议更差。这一点只能测，不能猜，方法见翻墙慢五步定位第四步。
• 服务商有没有正确设置带宽参数，你测一下就知道——速度长期卡在一个奇怪的固定值，往往就是这里填错了。

五、AnyTLS：冲着「包长和往返次数」去的

它想解决什么

AnyTLS 的定位在 README 第一句就说完了：

「一个试图缓解 嵌套的TLS握手指纹(TLS in TLS) 问题的代理协议。anytls-go 是该协议的参考实现。」

列出的特性是三条：「灵活的分包和填充策略」「连接复用，降低代理延迟」「简洁的配置」。

官方 FAQ 进一步说明它主要负责两件事：「1. 合理的 TCP 连接复用与性能表现；2. 控制数据包长度模式，缓解「嵌套的TLS握手指纹识别」」。加密本身「目前是依赖 TLS 完成的，因此协议取名为 AnyTLS」。

把它和第二节②那篇论文对照着看就很清楚了：论文说多路复用是有希望的对抗手段、随机填充不够；AnyTLS 就是按这个方向做的。

代价和边界

AnyTLS 的官方 FAQ 里有一整节叫「已知弱点」，开头就写「以下弱点目前可能不会轻易引发『被墙』……且修复可能引发协议不兼容，因此 anytls v1 没有对这些弱点进行处理」。其中几条：

• 「TLS over TLS 需要比普通 h2 请求更多的握手往返，也就是说，没有 h2 请求需要这么多的来回握手。」
• 「anytls 没有处理下行流量。」
• 现有的 PaddingScheme 语法对单包长度只有「单一固定长度」和「单一范围内随机」两种模式。
• 「anytls 几乎同时地发送三个或更多的数据包，特别是在 TLS 握手后的第一个 RTT 之内」，因此仍可能被「到达时间 - 包长 - 包数量」这类统计利用。
• 「TLS over TLS 开销导致可见的数据包长度增大和小数据包的缺失」，并「导致数据包持续超过 MTU 限制，这对于原始用户代理来说不应该发生」。
• 「由于这不是 HTTP 服务器，仍然可能存在主动探测问题」。

关于默认参数，FAQ 也说得很实在：「默认 PaddingScheme 只是一个示例。本项目无法确保默认参数不会被墙，因此设计了更新参数改变流量特征的机制。」

这份自陈清单的价值，超过任何第三方的「实测存活率」表格——它告诉你这个设计在哪里还没做完，而不是告诉你它现在有多能打。

实现成熟度：这一条请务必看

anytls-go 仓库自己的说明：

📌「本项目是 AnyTLS 协议的参考实现，核心目标是演示协议细节、交互流程与边界场景，而非提供功能完备的生产级客户端。日常使用推荐第三方兼容软件。」

⚠️「示例服务器和客户端默认采用不安全的配置，该配置假设您不会遭遇 TLS 中间人攻击；否则，您的通信内容可能会被中间人截获。」

README 点名的第三方兼容实现是 sing-box 和 mihomo（两者都包含 anytls 的服务端与客户端）。

六、对比表（2026-09-21 按各项目仓库与接口核对）

版本与日期来自 GitHub 接口当天查询结果：

三者都被主流通用客户端支持：sing-box（v1.14.1，2026-09-15）和 mihomo（v1.19.31，2026-09-14）的文档里都有对应的配置页。客户端本身怎么选、怎么并存多套配置，见 Clash 使用教程。更早一代的 Shadowsocks / V2Ray / Trojan 之间的差异，见 Shadowsocks、V2Ray、Trojan 对比，整个协议家族的总览在 协议专题页。

七、怎么用这张表做决定

先问自己的链路是什么毛病，再挑协议——顺序反过来就会一直换一直失望。

该问服务商的两句话（不需要你懂技术，答案要么是事实，要么是回避）：

1. 「同一个套餐里能不能同时拿到一种 TCP 类和一种 UDP 类协议的配置？」
2. 「Reality 节点的目标站是哪一类？」 —— 不需要他给你具体域名，但一个连「国外站、支持 TLSv1.3 与 H2、非跳转域名」这个标准都答不上的服务商，大概率也没按这个标准配。

八、为什么结论是「备两种」而不是「挑一种」

把前面几节并排放，这个结论几乎是自动的：

• UDP 类怕的是运营商对 UDP 大流量的限速，以及第二节③那种针对 QUIC 首包的按域名阻断。
• TCP/TLS 类怕的是握手特征和第二节②那种基于包长与往返次数的流量形态统计。

这是两套不同的失效原因，它们不同时发生。 当某一类被针对时，同类的节点会一起变差，而另一类可能毫无影响——这也正是 2026 年 4 月大面积断线期间被反复描述的现象（各来源的证据等级见2026 年 4 月「断线潮」的证据核对）。

备两种协议的成本接近于零：它不用多花钱，只需要你在配置里多留一组。收益是你不会在同一天把所有选项用光。真断了之后按什么顺序处理，见机场突然全挂了：30 分钟自救清单。

最后强调一遍第二节的结论：这三个协议没有一个处在「检测不到」的状态，它们自己的文档也都没这么宣称。它们做的是抬高针对成本、扩大误伤面。理解这一点，你就不会为「最新最强协议」多付钱，也不会在某个协议变差时觉得自己被骗了——那是这件事本来的样子。

参考资料

各项目自己的仓库与官方文档（2026-09-21 获取）

• XTLS/REALITY — GitHub 仓库 README（「可消除服务端 TLS 指纹特征」「可以指向别人的网站」；目标站要求「国外网站，支持 TLSv1.3 与 H2，域名非跳转用」；「因为它们存在明显且已被针对的 TLS in TLS 特征」；「回落限速是一种特征，不建议启用」；客户端默认 uTLS 指纹 chrome）（2026-09-21 核查；main 分支最近提交 2026-09-10 UTC，该仓库无 Release）
• XTLS/Xray-core — GitHub 仓库（MPL-2.0；最新正式版 v26.3.27，2026-03-27；其后 v26.6–v26.9 系列标记为预发布，最新 v26.9.9，2026-09-08；main 分支最近提交 2026-09-19 UTC，提交号 dcdfc57c）（2026-09-21 经 GitHub API 核查）
• HyNetworks/hysteria — GitHub 仓库 README（MIT；「Powered by a customized QUIC protocol… over unreliable and lossy networks」；最新版 app/v2.12.3，2026-09-16 发布；master 分支最近提交 2026-09-13 UTC）（2026-09-21 经 GitHub API 核查）
• Hysteria 2 官方中文文档首页（「基于魔改的 QUIC 协议」「即使在最不稳定和容易丢包的网络环境中也能提供无与伦比的性能」「协议旨在伪装成标准的 HTTP/3 流量」）（2026-09-21 核查）
• Hysteria 2 官方文档 — Full Server Config（masquerade 的作用与「未配置时一律返回 404 Not Found」；「The server’s bandwidth limit only applies to Brutal at the moment」；Brutal「operates on a fixed rate model and does not reduce its speed in response to packet loss or RTT changes」；「DO NOT set it higher than what’s possible」）（2026-09-21 核查）
• anytls/anytls-go — GitHub 仓库 README（「一个试图缓解 嵌套的TLS握手指纹(TLS in TLS) 问题的代理协议」；「参考实现……而非提供功能完备的生产级客户端」；「示例服务器和客户端默认采用不安全的配置」；第三方兼容软件列出 sing-box 与 mihomo；最新版 v0.0.13，2026-06-27）（2026-09-21 经 GitHub API 核查）
• anytls-go — 官方 FAQ 文档 docs/faq.md（「已知弱点」十条；「控制数据包长度模式，缓解『嵌套的TLS握手指纹识别』」；「本项目无法确保默认参数不会被墙」）（2026-09-21 核查）
• sing-box 官方文档 — AnyTLS 出站配置（用于确认主流通用客户端对该协议的支持；sing-box v1.14.1，2026-09-15）（2026-09-21 核查）

已发表的审查测量研究（本文所有关于「能否被检测」的说法只引用这些）

• USENIX Security 2023 — How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic（熵启发式：每字节置位比特 3.4–4.6 触发阻断；五条豁免规则；17 亿条连接中约 0.6% 会被规则命中，实际限定在特定机房 IP 段、影响约 26% 的连接）（2026-09-21 核查）
• USENIX Security 2024 — Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes（Diwen Xue、Michalis Kallitsis、Amir Houmansadr、Roya Ensafi；随机填充与多层封装下仍可可靠识别；多路复用与随机填充「inherently limited」）（2026-09-21 核查）
• USENIX Security 2025 — Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China（自 2024-04-07 起按域名阻断 QUIC；大规模解密 QUIC Initial 包；独立封锁列表；测得 58,207 个 FQDN 被封锁）（2026-09-21 核查）