REALITY 是什么：不需要证书的 TLS 方案如何工作

一句话理解 REALITY

REALITY 让代理节点在不拥有任何域名证书的情况下完成 TLS 握手：节点借用一个真实存在的第三方网站作为“目标”，合法客户端在握手消息里藏入只有节点能验证的认证信息，验证通过就建立代理通道，验证失败就把整条连接原样转交给那个真实网站。这样，任何不知道密钥的访问者看到的都是真实网站。

它解决的是传统 TLS 节点的一个现实问题：节点需要自己的域名和证书，而域名、证书、服务器指纹都可能被分析。REALITY 是一种外层安全方案，常与 VLESS 搭配。本文讲握手原理，不讲部署教程；所属二级专题见 代理协议二级专题，概览见 一级专题的协议章节。

传统 TLS 节点的三个可观察点

要理解 REALITY 改了什么，先看普通 TLS 节点在握手阶段会留下哪些信息：

可以看到，REALITY 在三个位置上都把“节点自己”换成了“目标网站”。这也是它被称为“不需要证书”的原因：证书来自目标网站，节点不必申请。

握手按什么顺序进行

按 Xray 社区公开的设计说明，一次 REALITY 握手大致分五步：

1. 客户端准备。 客户端事先拿到节点的公钥、短 ID 和目标网站域名。握手时，它生成一对临时密钥，用临时私钥和节点公钥算出一个共享密钥。
2. 在 ClientHello 中藏入认证信息。 客户端发出一个外观与浏览器相同的 TLS 1.3 ClientHello，SNI 填写目标网站域名。认证信息（包括短 ID 和时间信息）用共享密钥加密后，放进握手消息中原本就存在的随机字段里，外观上与普通随机数无异。
3. 节点判断来者身份。 节点用自己的私钥和客户端的临时公钥算出同一个共享密钥，尝试解出认证信息。解出且短 ID、时间都合格，就认为是合法客户端。
4. 合法客户端：出示临时证书。 节点现场生成一张临时证书，并用共享密钥对其签名。客户端收到后，用同一共享密钥校验，确认对方确实是持有私钥的节点，而不是中间人。
5. 非法连接：转交目标网站。 如果解不出认证信息，节点不做任何特殊回应，而是把这条连接透明地转发给目标网站，由目标网站完成后续握手并出示它的真实证书。

整个过程中，节点从未出示属于自己的域名证书，旁观者看到的 SNI、证书链也都指向目标网站。

客户端参数各对应哪一步

导入 REALITY 节点时，客户端里会出现几个专门的参数，它们与上面的步骤一一对应：

这些参数一般由订阅自动下发，用户不需要手动填写。但如果订阅转换工具或客户端漏掉了其中一项，节点就会显示超时，日志里往往看不到明确的“密码错误”，因为节点按设计不会告诉非法连接任何信息。

REALITY 的适用条件与局限

REALITY 并不是没有前提的方案：

• 依赖 TLS 1.3。 目标网站需要支持 TLS 1.3，客户端内核也必须实现这一套握手逻辑。
• 对时间有一定要求。 认证信息里包含时间，设备时钟偏差过大时可能被判为不合格，表现与参数错误相似。
• 客户端支持面较窄。 相比 TLS，支持 REALITY 的客户端内核更少，iOS 与部分旧客户端尤其需要确认，可参考 iOS 客户端是否支持 VLESS 与 REALITY 的确认方法。
• 目标网站的选择属于运营方。 节点借用哪个网站、该网站与节点所在地区是否匹配，是运营方的部署问题，用户无法控制，也不应自行更改。

另外，REALITY 只负责外层安全，它不影响线路类型和带宽，也不决定落地 IP 在 AI 或流媒体平台眼中的地区。本站对 17 个品牌均未做解锁实测。

机场资料里看不到 REALITY 时

本站整理的 17 个品牌资料中，有 12 个写明 VLESS，但没有一份资料提到 REALITY 或 TLS 的具体配置。因此，“某品牌是否使用 REALITY”目前属于待核实事项，只能在导入订阅后，从客户端节点详情的安全层一项看到。如果你的客户端不支持 REALITY，建议购买前先问清订阅里是否同时提供其他组合的节点。

确认订阅导入方式，请转到 订阅链接导入与更新；REALITY 常搭配的代理协议，见 VLESS 为什么本身不加密；连接失败时的协议层原因，见 TLS、SNI 与证书校验导致的连接失败。

请遵守所在地法律法规与平台条款。本文只做原理说明，不提供规避监管的部署方法。