REALITY 是 Xray-core 团队在 2022 年底推出的一种创新型传输协议，旨在彻底解决传统代理协议在 TLS 流量伪装上面临的主动探测和 TLS 指纹识别问题。REALITY 的核心思想是“无服务器指纹，无 TLS 握手特征，无需伪装域名和证书”，它通过重用目标网站的 TLS 证书和握手，将代理流量伪装成访问真实网站的流量，从而达到前所未有的隐蔽性。

核心思想：服务器不再持有自己的 TLS 证书和域名，而是被动地作为中继，复用一个真实存在且受欢迎的 HTTPS 网站的 TLS 证书和握手，将代理流量伪装成访问该网站的流量，从而达到极高的隐蔽性，并且不再需要自签证书和伪装域名。

一、为什么需要 REALITY？

尽管 VLESS+XTLS 和 Trojan 等协议已经提供了很强的隐蔽性，但它们仍面临一些挑战：

  1. TLS 指纹识别 (TLS Fingerprinting)：即使使用合法证书，客户端（如 Xray 客户端）在进行 TLS 握手时，其行为模式（支持的密码套件、扩展顺序、记录大小等）可能与主流浏览器存在细微差异，形成独特的“TLS 指纹”。审查者可以分析这些指纹来识别非浏览器流量。
  2. 证书和域名管理：部署这些协议通常需要一个真实的域名和合法 TLS 证书（例如 Let’s Encrypt），这增加了配置复杂性。同时，域名和证书本身也可能成为被封锁的对象。
  3. 主动探测：审查系统可能主动连接代理服务器，尝试多种探测方法。即使服务器配置了回落（Fallback），但如果回落目标网站本身被封锁或无法访问，也可能引发怀疑。
  4. 服务器暴露：代理服务器始终拥有自己的 IP 地址和 TLS 证书。这意味着审查者只要能够识别出其代理身份，就可以直接封锁 IP 或域名。

REALITY 旨在彻底颠覆这些挑战，提供一种“零可见度”的代理解决方案。

二、REALITY 协议的核心原理

REALITY 的核心在于其被动服务器和复用真实网站 TLS的设计。

2.1 无服务器指纹 (No Server Fingerprint)

这是 REALITY 最革命性的特点。REALITY 服务器不再拥有自己的 TLS 证书和域名。当客户端连接时，服务器不会进行独立的 TLS 握手。相反，它会充当一个中间人，将客户端的 TLS 握手请求转发给一个预设的真实网站 (Decoy)。

  • 优势：由于服务器不参与 TLS 握手过程，它自然就不会暴露任何服务器端的 TLS 指纹（如证书信息、服务器支持的密码套件等）。这使得代理服务器在网络层面看起来完全不存在 TLS 服务。

2.2 重用真实网站 TLS 握手 (Reusing Real Website’s TLS Handshake)

  1. 伪装目标 (Decoy)：REALITY 客户端和服务器之间会预先协商一个真实存在的、访问量大、且不易被封锁的 HTTPS 网站作为伪装目标 (Decoy)。例如：www.microsoft.com。
  2. 客户端行为：当客户端发起连接时，它构造的 TLS 握手数据包，看起来就像是正在访问这个伪装目标网站。
  3. 服务器行为：REALITY 服务器接收到客户端的连接后，它不会像传统协议那样自己进行 TLS 握手。而是：
    • 提取客户端的 TLS 握手数据包。
    • 将这些数据包转发给真实的伪装目标网站。
    • 从伪装目标网站接收响应的 TLS 握手数据包，并将其转发回客户端。
    • 在这个过程中，服务器会巧妙地替换掉伪装目标网站响应中的关键信息（如 ClientHello 中的 SNI），以确保后续的流量被正确引导到代理路径，而不是真正的伪装目标。
  • 优势：
    • 客户端完成的 TLS 握手，其另一端是真实的、权威的 Web 服务器。这意味着客户端看到的证书是真实网站的证书，握手过程和指纹也与访问真实网站无异。
    • 从审查者的角度看，客户端正在正常地访问一个著名的网站，因此不会产生任何怀疑。

2.3 无需域名和证书 (No Domain or Certificate Required for Server)

由于服务器不提供自己的 TLS 服务，它不再需要购买域名或申请 TLS 证书。这大大简化了部署过程，降低了成本，并且消除了域名/证书被封锁的风险。

  • 优势：极大降低了部署门槛和维护成本，同时消除了审查者通过封锁域名/证书来阻断代理的手段。

2.4 基于 VLESS 协议 (VLESS-Based)

REALITY 是 VLESS 协议的一个传输层变种。它在 TLS 握手成功后，使用 VLESS 协议来传输实际的代理数据。因此，它也继承了 VLESS 协议简洁、高效、无额外加密/混淆的特点，并通常与 VLESS 的 xtls-rprx-vision 流量控制结合使用，以达到最佳性能。

2.5 嗅探攻击的防御 (Replay Attack / Sniffing Prevention)

REALITY 引入了 shortId 和 fingerprint (TLS 指纹) 等机制来验证客户端，防止重放攻击和非授权连接。

  • shortId：一个简短的十六进制字符串，用于在 TLS 握手后作为客户端的身份标识。服务器会根据这个 shortId 来识别合法的代理连接。
  • fingerprint：客户端可以指定一个特定的浏览器 TLS 指纹（例如 chrome, firefox），服务器会检查客户端发送的 ClientHello 消息是否与这个指纹匹配。这进一步增强了伪装效果。

三、REALITY 的工作流程

流程说明：

  1. TCP 连接建立：客户端发起 TCP 连接到 REALITY 服务器的 IP 地址和端口（通常是 443）。
  2. 客户端发起 TLS 握手：客户端发送 ClientHello 消息，其中包含 SNI（Server Name Indication）字段，指定为预设的伪装目标域名 (Decoy Domain)。同时，客户端的 ClientHello 消息会模拟某种浏览器（如 Chrome）的 TLS 指纹。
  3. REALITY 服务器作为中间人转发：
    • REALITY 服务器接收到客户端的 ClientHello，并不会自己进行 TLS 握手。
    • 它会将客户端的 ClientHello 完整地转发给真实的伪装目标网站。
    • 真实的伪装目标网站会响应 ServerHello、证书等 TLS 握手消息给 REALITY 服务器。
  4. REALITY 服务器修改并转发 TLS 握手响应：
    • REALITY 服务器接收到伪装目标网站的 TLS 握手响应后，会进行巧妙的修改，特别是替换掉 ServerHello 中可能暴露 REALITY 服务器信息的字段。
    • 然后，将修改后的 TLS 握手响应转发给客户端。
    • 客户端收到这些响应后，认为自己已经与伪装目标网站成功建立了 TLS 连接。
  5. REALITY 认证：
    • 客户端完成 TLS 握手后，会发送 ClientFinished 消息。
    • 紧接着，客户端会发送 REALITY 特有的认证信息，包括 shortId 和 VLESS 的 UUID。
  6. REALITY 服务器验证：
    • REALITY 服务器验证 shortId 和 VLESS UUID 是否匹配其配置。
    • 同时，服务器还会验证客户端的 ClientHello 消息的 TLS 指纹是否符合预期（如果配置了 fingerprint）。
  7. VLESS 代理会话：
    • 如果所有认证和验证都通过，REALITY 服务器就会认为这是一个合法的代理连接。
    • 后续的代理流量将使用 VLESS 协议（通常结合 xtls-rprx-vision 流量控制），直接通过已建立的 TLS 加密通道（此时客户端认为这个通道是与伪装目标网站建立的）进行传输。
  8. 请求转发与响应：REALITY 服务器将 VLESS 代理请求转发到实际的目标网站，并将目标网站的响应反向传回客户端。

四、REALITY 的优缺点与适用场景

4.1 优点：

  1. 极致隐蔽性 (Ultimate Obfuscation)：
    • 无服务器 TLS 指纹：服务器不参与 TLS 握手，不暴露任何自己的 TLS 特征。
    • 流量伪装为访问真实网站：客户端的 TLS 握手是与真实存在的网站完成的，从外部看，就是客户端在访问一个著名的网站。
    • 无需域名和证书：部署和维护更简单，避免了域名/证书被封锁的风险。
    • 几乎免疫主动探测：探测者只能看到访问真实网站的流量，无法识别代理服务器。
  2. 安全性高：完全依赖于标准 TLS 协议进行加密，继承了其提供的端到端加密和身份认证能力。
  3. 高性能：基于 VLESS 协议，并利用 XTLS 的免流量加密优化，可以达到接近直连的性能。
  4. 抗审查能力最强：目前被认为是抵抗高级网络审查最有效的协议之一。
  5. 简化部署：无需为代理服务器购买和管理域名、申请和续签 TLS 证书。

4.2 缺点：

  1. 配置相对复杂：虽然不再需要域名和证书，但客户端和服务器的配置项（如 shortId、dest、serverNames、fingerprints、decoy 等）相对较多，需要仔细理解和设置。
  2. 依赖伪装目标的稳定性和可用性：如果选择的伪装目标网站被封锁或不稳定，可能会影响代理服务的可用性。因此，选择一个大型、权威、不易受影响的网站作为 decoy 至关重要。
  3. 要求 Xray-core：REALITY 是 Xray-core 独有的特性，需要使用 Xray-core 及其兼容客户端。
  4. 对时间同步有要求：为了防止重放攻击，REALITY 可能对客户端和服务器的时间同步有一定要求。

4.3 适用场景：

  • 面临最严格网络审查的环境和用户，对代理的隐蔽性有最高要求。
  • 希望简化域名和证书管理，避免相关风险的用户。
  • 追求极致性能和稳定性的用户。
  • 对抗国家级深度包检测和主动探测。

五、部署要点

  1. Xray-core 版本：确保服务器和客户端都使用支持 REALITY 的最新 Xray-core 版本。
  2. 伪装目标 (Decoy)：选择一个真实存在的、访问量大、且不易被封锁的 HTTPS 网站作为 decoy。例如 www.microsoft.com, www.apple.com, www.cloudflare.com 等。
  3. ShortId：生成一个简短的十六进制字符串作为 shortId，客户端和服务器必须一致。
  4. 目标服务器地址 (dest)：这是 REALITY 服务器将客户端流量转发到的实际目标地址和端口（通常是代理服务器的 IP:443）。
  5. TLS 指纹 (fingerprint)：建议在客户端和服务器配置中都指定一个 fingerprint，模拟主流浏览器的 TLS 指纹，例如 chrome 或 firefox。
  6. VLESS UUID：标准的 VLESS 用户认证 UUID 仍然需要。
  7. 服务器 IP 暴露：虽然 REALITY 隐藏了服务器的 TLS 指纹，但服务器的 IP 地址仍然是直接暴露的。建议结合 CDN (如 Cloudflare) 或 WAF 服务来隐藏真实 IP，进一步增强抗封锁能力。

六、总结

REALITY 协议是 Xray-core 在代理技术领域的又一重大突破，它以其独特的“被动服务器”和“重用真实网站 TLS 握手”的设计理念，将代理的隐蔽性推向了新的高度。通过彻底消除服务器的 TLS 指纹、避免域名和证书的需求，并完美伪装成访问真实网站的流量，REALITY 为对抗最先进的网络审查系统提供了一种前所未有的强大工具。对于追求极致抗审查能力和高性能的用户而言，REALITY 无疑是目前最值得关注和部署的代理协议之一。