tech/protocol · 集群 A · 主流协议原理 · 6/6
REALITY 是什么:与传统 TLS 证书方案的区别、认证原理与客户端参数
REALITY 是 Xray 项目提出的一种传输安全层,通常与 VLESS 组合使用。它在 TLS 握手的框架内借助 x25519 密钥交换认证客户端,服务端不需要为自己的域名申请证书,未通过认证的连接会被转交给一个真实的目标网站处理。客户端需要支持 REALITY,并使用订阅下发的公钥与 shortId。
REALITY 在协议栈中的位置
REALITY 不是一个代理协议,而是一种传输安全层,位置与 TLS 相同。最常见的组合是 VLESS + TCP + REALITY:VLESS 负责认证与目标地址,REALITY 负责加密与对外的握手形态。
┌─────────────────────────────────┐
│ VLESS 头 + 应用数据 │
├─────────────────────────────────┤
│ REALITY(TLS 1.3 握手框架) │ ← 替代传统 TLS 证书方案
├─────────────────────────────────┤
│ TCP │
└─────────────────────────────────┘
要理解 REALITY 解决了什么问题,需要先看传统 TLS 方案的结构。传统方案中,服务端需要拥有一个域名、为该域名申请证书,客户端连接时在 SNI 中填写这个域名并校验证书。这带来两个部署上的问题:运营者需要维护域名和证书;客户端访问的域名本身就是一个可被观察的特征。
认证原理:在握手里完成的密钥交换
REALITY 的认证思路是:把客户端身份验证嵌入 TLS 1.3 握手的 ClientHello 中,而不是依赖证书链。合法客户端事先知道服务端的 x25519 公钥,在发起握手时利用这个公钥与自己的临时密钥做密钥交换,并在 ClientHello 的特定字段中放入可被服务端验证的信息。
服务端收到 ClientHello 后,尝试用自己的私钥验证这段信息:
| 情况 | 服务端行为 | 结果 |
|---|---|---|
| 验证通过 | 与客户端完成握手,进入代理模式 | 合法用户正常使用 |
| 验证不通过 | 把连接转交给配置的真实目标网站 | 访问者得到目标网站的正常握手与响应 |
这里的「真实目标网站」是服务端配置中指定的一个外部网站,客户端配置中的 serverName 通常与之对应。未通过认证的访问者与该网站完成真实的 TLS 握手,看到的是一个真实存在的网站证书。合法客户端则通过密钥交换确认自己连接的是持有私钥的服务端,从而避免被中间人冒充。
这一设计的意义在于:运营者无需申请证书,也不必暴露自有域名。但同样需要强调,这只是改变了一部分可观察特征,并不意味着无法被识别,协议识别是一个持续演进的领域,原理概述见 协议识别的原理,本站不讨论针对任何系统的规避方法。
客户端参数逐个看
REALITY 节点比传统 TLS 节点多出几个参数,它们全部由服务端决定,客户端必须与之一致。
| 参数 | 含义 | 用户需要知道的 |
|---|---|---|
| publicKey(pbk) | 服务端 x25519 公钥 | 订阅下发,填错无法连接 |
| shortId(sid) | 客户端短标识 | 服务端可配置多个,需匹配其一 |
| serverName(sni) | 握手中使用的目标域名 | 与服务端配置的目标站点对应 |
| fingerprint(fp) | 模拟的 TLS 客户端指纹 | 影响 ClientHello 形态,按订阅填写 |
| spiderX 等 | 扩展参数 | 部分客户端支持,通常保持默认 |
fingerprint 参数涉及 TLS 指纹的概念:不同 TLS 库生成的 ClientHello 在字段顺序、扩展列表上有差异,客户端通过 uTLS 等库生成与常见浏览器一致的 ClientHello,这是 REALITY 能正常工作的前提之一。指纹的原理见 TLS 指纹是什么。
与传统 TLS 方案的对比
REALITY 与传统 TLS 的差异主要在部署与认证方式,而不在加密强度:两者最终都使用 TLS 1.3 的密码学机制保护数据。
| 对比项 | 传统 TLS(如 VLESS + TLS) | REALITY |
|---|---|---|
| 服务端证书 | 需要为自有域名申请 | 不需要 |
| 客户端认证 | 由内层协议(UUID)完成 | 握手阶段即验证 + 内层 UUID |
| 服务端身份校验 | 证书链 | 公钥密钥交换 |
| 未认证访问 | 取决于回落配置 | 转交真实目标网站 |
| 客户端要求 | 支持 TLS 即可 | 需支持 REALITY 的较新内核 |
| 能否经过 CDN | 可配合 WebSocket 等 | 一般不能,需直连或四层转发 |
最后一行值得注意:REALITY 依赖完整的 TLS 握手直达服务端,不能像 WebSocket + TLS 那样通过 CDN 中转。这影响的是服务商的部署方式,用户层面一般无需关心,但它解释了为什么同一服务商可能同时提供 REALITY 与其他形态的节点。
客户端兼容与常见问题
REALITY 需要较新的客户端内核,Xray 系、sing-box、mihomo 支持,原版 Clash 内核不支持。导入后节点缺失或报「unknown security type」之类的错误,通常是内核过旧,升级后即可解决。
REALITY 节点报错
├─ 无法识别 reality 字段 → 内核不支持或版本过旧
├─ 握手失败
│ ├─ publicKey / shortId 与服务端不一致 → 更新订阅
│ └─ 设备时间偏差过大 → 开启自动对时
└─ 偶发超时 → 多为线路或节点负载,转入网络层排查
客户端的选择与升级方法,请参考 桌面客户端 与 移动客户端 专题。
关于 REALITY 的几个常见误解
关于 REALITY,网上流传着一些不准确的说法,弄清楚它们有助于形成合理预期。
误解一:「REALITY 不加密,只是伪装」。实际上合法客户端与服务端之间同样基于 TLS 1.3 的密码学机制建立加密通道,数据受到与常规 TLS 相当的保护,REALITY 改变的是认证方式与对外握手形态,而不是去掉了加密。
误解二:「用了 REALITY 就等于连到了那个目标网站」。并非如此,合法客户端的数据始终发往服务商的节点,目标网站只在未认证访问时才被用来完成握手,它并不承载你的代理流量,也不知道你的存在。
误解三:「REALITY 节点一定比 TLS 节点快」。两者的加密开销相近,速度差异主要来自线路与节点负载,而非安全层类型,本站未实测任何品牌的 REALITY 节点表现。
误解四:「serverName 可以随意改成任何网站」。serverName 必须与服务端配置的目标站点对应,随意修改会导致认证失败,应完全按订阅填写。
品牌资料中的 REALITY
本站品牌库中,12 个品牌资料标注协议为 VLESS,但资料没有说明它们使用的安全层是 TLS 还是 REALITY,本站对此不作推断,以订阅中的实际配置为准;微风网络、飞猫云、星岛梦、灵猫网络、极连云五个品牌协议待核实,同样不推测。所有品牌的连接表现本站均未实测。
理解 REALITY 的意义,在于读懂订阅里那几个陌生参数,并在客户端报错时知道从哪里排查。想查看品牌协议资料,可前往 机场品牌库 或 VLESS 标签 页面;想比较两个品牌的字段,可以使用 对比工具。
常见问题
REALITY 和 TLS 是什么关系?
REALITY 在 TLS 1.3 握手的框架内工作,对外形态是 TLS 握手,但认证方式不同:它不依赖服务端自有证书,而是用预先分发的公钥在握手过程中验证客户端。
REALITY 为什么不需要证书?
服务端在握手中借用一个真实目标网站的握手信息,合法客户端通过密钥交换验证服务端身份,因此运营者不需要为自己的域名申请证书。
REALITY 配置里的 publicKey 和 shortId 是什么?
publicKey 是服务端 x25519 公钥,客户端用它参与密钥交换;shortId 是一个短标识,用于区分客户端。两者都必须与服务端一致,应按订阅填写。
哪些客户端支持 REALITY?
Xray 系、sing-box、mihomo 等较新内核支持,原版 Clash 内核不支持。导入失败时通常需要升级客户端版本。
信息来源与更新时间
- 信息来源
- 品牌清单资料(品牌公开信息整理)
- 测试范围
- 本站未进行测速与解锁实测,所有能力描述均为资料声明或未测试状态。
- 发布时间
- 待核实
- 核实日期
- 待核实
- 最近更新
- 待核实