处世如大梦，悟者能有几

作者：pluto 更新时间：2026-04-17

摘要

REALITY 是由 XTLS 项目（Project X）开发的新一代代理协议，旨在通过替代 TLS 来实现"无指纹"的代理通信。与 VMess 等应用层协议不同，REALITY 工作在传输层（TLS 层），通过伪装成真实 TLS 连接来对抗深度包检测（DPI）。本文从协议设计目标、密码学基础、认证机制、握手流程、安全性分析及与 VMess、Trojan 等协议的对比等维度，对 REALITY 协议进行系统性研究。

1. 背景与设计目标

1.1 历史背景

REALITY 协议诞生于 Project X/XTLS 社区对代理协议演化的深层思考。传统代理协议的演变路线如下：

• 第一代（2015-2019）：VMess、Shadowsocks 等应用层加密协议，通过自定义数据格式对抗特征识别
• 第二代（2019-2021）：Trojan、VLESS 等协议，通过 TLS 1.3 套壳方案提升隐蔽性
• 第三代（2023+）：REALITY 协议，直接替代 TLS，消除服务端指纹

REALITY 首次发布于 2023 年初，由 XTLS 项目的核心开发者 RPRX 主导设计，致力于解决 TLS in TLS 特征被针对的问题。

1.2 核心设计目标

REALITY 协议的核心设计目标为：

1. 消除服务端 TLS 指纹：不再向观察者展示代理服务端的 TLS 指纹特征，而是呈现指定目标网站的真实 TLS 指纹

2. 实现"借壳"代理：无需购买域名、配置 TLS 服务器，直接指向任意目标网站（如 google.com、cdn.jsdelivr.net 等），将其作为"代理外壳"

3. 保证前向保密性：基于 TLS 1.3 的前向保密设计，每次握手产生独立的会话密钥

4. 对抗主动探测：通过临时证书认证、客户端版本/时间检验等机制，有效区分合法客户端与网络探测

5. 支持后量子密码学：集成 ML-DSA-65 和 X25519-MLKEM768 等后量子算法，提前应对量子计算威胁

6. 零开销替代 TLS：直接替代 TLS 层，无额外加密开销，性能与原生 TLS 无差异

1.3 与 VMess 的主要差异

2. 密码学基础

2.1 密钥派生与认证

REALITY 在认证阶段使用基于 HKDF 的密钥派生机制：

AuthKey 派生流程：

// X25519 密钥交换
SharedKey = X25519(ClientPrivateKey, ServerPublicKey)

// 使用 HKDF 派生认证密钥
AuthKey = HKDF(
    hash=SHA256,
    ikm=SharedKey,
    salt=ClientRandom[:20],
    info="REALITY"
)

其中：

• ClientPrivateKey：客户端临时生成的 X25519 私钥
• ServerPublicKey：服务端的 X25519 公钥（在配置中存储）
• ClientRandom：TLS Client Hello 中的 Random 字段（32 字节）

2.2 客户端认证信息编码

客户端在 TLS Client Hello 的 Session ID 字段中嵌入认证信息。该字段在 Client Hello 中占 32 字节，编码结构如下：

+------------------+------------------+------------------+
| ClientVersion    | ClientTime       | ClientShortId    |
| (3 bytes)        | (4 bytes)        | (8 bytes)        |
| + Reserved (17B) | + Reserved       | + Reserved       |
+------------------+------------------+------------------+

加密方式：

• 明文（前 15 字节）使用 AES-128-GCM 加密
• 加密参数：
  • Key：AuthKey[:16]
  • Nonce：ClientRandom[20:32]（TLS Random 的后 12 字节）
  • Associated Data：Client Hello 报文

字段说明：

2.3 时间与版本验证

服务端在认证时进行如下检查：

// 版本检查
if config.MinClientVer != nil && Value(ClientVer) < Value(config.MinClientVer) {
    reject()
}
if config.MaxClientVer != nil && Value(ClientVer) > Value(config.MaxClientVer) {
    reject()
}

// 时间偏差检查
timeDiff := now - ClientTime
if config.MaxTimeDiff > 0 && abs(timeDiff) > config.MaxTimeDiff {
    reject()
}

// ShortId 检查
if !config.ShortIds[ClientShortId] {
    reject()
}

此机制的目的是：

• 时间检验：防止重放攻击和暴力破解（通常设置 ±1 小时）
• 版本检验：支持服务端渐进式升级，仅接受特定版本范围的客户端
• ShortId 检验：支持多用户场景，每个用户对应一组 ShortId 集合

2.4 证书生成与签名

REALITY 服务端动态生成临时证书，使用以下方案：

方案 1：Ed25519 签名（标准方案）

1. 从 AuthKey 派生签名私钥：
   SignatureKey = HMAC-SHA512(AuthKey, Ed25519PrivateKey[32:])
   
2. 证书内容使用 Ed25519 签名

3. 证书特性：
   - 自签名（Subject = Issuer）
   - 有效期：从当前时刻起 1 小时
   - 密钥用途：serverAuth, clientAuth

方案 2：ML-DSA-65 签名（后量子方案）

1. 使用 ML-DSA-65（后量子数字签名）对证书签名

2. 证书结构（ML-DSA-65 签名固定 4595 字节）：
   - 标准 X.509 证书部分
   - 最后 64 字节：HMAC 验证标签
   - 倒数第 65-4659 字节：ML-DSA-65 签名

3. 验证流程：
   - 客户端验证 ML-DSA-65 签名的有效性
   - 验证 HMAC 标签确保证书完整性

3. TLS 1.3 握手流程

REALITY 基于 TLS 1.3 握手机制，但在多个环节进行定制化设计。

3.1 握手消息流

Client                                          Server
  |                                              |
  |-------------- Client Hello ----------------->|
  |                                              |
  |<------------ Server Hello ------------------|
  |<-------- Change Cipher Spec ----------------| (compatibility)
  |<------- Encrypted Extensions --------|
  |<----------- Certificate ------------|
  |<--------- Certificate Verify --------|
  |<------------ Finished -------------------|
  |                                              |
  |------------ Change Cipher Spec ------------->|
  |------------- Certificate (empty) ----------->|
  |--------- Certificate Verify (empty) ------->|
  |------------ Finished ---------------------->|
  |                                              |
  |<== Encrypted Application Data ===============|   |=== Encrypted Application Data ==============>|

3.2 Client Hello 处理

Client Hello 在 REALITY 中包含以下关键元素：

必需扩展：

• key_share：X25519 密钥共享（标准）或 X25519-MLKEM768（后量子混合）
• supported_version：声明 TLS 1.3 支持
• signature_algorithms：支持的签名算法

特殊处理的字段：

• random：前 20 字节来自系统时间戳，后 12 字节用作 Nonce
• session_id：32 字节，包含加密的客户端认证信息
• server_name：必须匹配 config.ServerNames 中的值

3.3 Server Hello 处理

服务端在 Server Hello 中使用以下关键参数：

ServerHello {
    Version:        TLS 1.2（wire format）
    SupportedVersion: TLS 1.3（extension）
    CipherSuite:    TLS_AES_128_GCM_SHA256（或其他 TLS 1.3 套件）
    KeyShare:       X25519 或 X25519-MLKEM768 公钥
    Random:         32 字节随机数
}

3.4 握手记录收集

REALITY 实现特殊的握手记录长度检测机制，用于识别目标网站的真实 TLS 握手行为。

记录类型：

服务端通过 GlobalPostHandshakeRecordsLens 机制存储目标网站的握手消息长度，客户端可预先加载以复现真实网站的握手行为。

4. 认证机制

4.1 双向认证流程

REALITY 实现了基于 AuthKey 的非对称认证机制：

客户端 → 服务端认证：

1. 客户端在 Session ID 中嵌入：ClientVersion, ClientTime, ClientShortId
2. 使用 AuthKey 对 Session ID 进行 AES-128-GCM 加密
3. 服务端通过 AuthKey 解密并验证字段有效性
4. 验证通过则建立 TLS 连接；验证失败则转发至目标网站（fallback）

服务端 → 客户端认证：

1. 服务端生成临时证书
2. 使用从 AuthKey 派生的私钥对证书签名
3. 客户端验证证书签名并检查签名私钥与预期 AuthKey 的对应关系
4. 证书验证通过表示连接到真实代理；否则视为目标网站或中间人

4.2 证书链攻击防护

REALITY 通过以下机制防护证书链攻击：

客户端收到证书后的判断流程：

1. 收到临时可信证书（HMAC 验证通过）
   → 连接可用，正常通信

2. 收到真证书（CA 签名有效但 HMAC 失败）
   → 进入爬虫模式（Spider Mode）
   → 发送真实 HTTP 请求至目标网站
   → 隐蔽性最高，难以识别代理行为

3. 收到无效证书（签名验证失败）
   → 发送 TLS Alert
   → 断开连接
   → 标记为中间人攻击或主动探测

4.3 回落机制

当客户端认证失败时，REALITY 实现了多层级的回落策略：

第一层回落：直接转发至目标网站

Client Hello 验证失败 → hs.c.conn = nil
→ 所有 Client Hello 数据转发至 config.Dest
→ 呈现目标网站的真实 TLS 指纹

第二层回落：Server Hello 验证

如果目标网站 Server Hello 异常
→ 立即转发所有已接收数据至客户端
→ 继续双向转发（TCP Splice）

5. 密钥交换与共享密钥

5.1 X25519 密钥交换

标准方案使用 Elliptic Curve Diffie-Hellman over Curve25519：

Client Side:
    clientPrivateKey = RandomBytes(32)
    clientPublicKey = X25519(clientPrivateKey, basepoint)
    
    // Client Hello 中的 key_share 扩展
    key_share = {
        group: X25519,
        key_exchange: clientPublicKey
    }

Server Side:
    serverPrivateKey = config.PrivateKey  // 预配置
    sharedSecret = X25519(serverPrivateKey, clientPublicKey)

安全性特性：

• 前向保密性：私钥泄露不影响历史会话
• 椭圆曲线强度：≈ 128 位对称密钥强度
• 量子安全性：无（需使用 MLKEM 混合方案）

5.2 X25519-MLKEM768 混合密钥交换

后量子混合方案集成 ML-KEM（Kyber 标准化版本）：

Client Side:
    // ECDH 部分
    ecdh_privkey = RandomBytes(32)
    ecdh_pubkey = X25519(ecdh_privkey, basepoint)
    
    // ML-KEM 部分
    (mlkem_pubkey, mlkem_seed) = ML_KEM.Keygen()
    
    // 组合 key_share
    key_share = {
        group: X25519MLKEM768,
        key_exchange: ecdh_pubkey || mlkem_pubkey  // 64 字节
    }

Server Side:
    // ECDH 计算
    ecdh_shared = X25519(serverPrivateKey, ecdh_pubkey)
    
    // ML-KEM 包裹
    (mlkem_ciphertext, mlkem_shared) = ML_KEM.Encaps(mlkem_pubkey)
    
    // 组合密钥
    key_exchange = mlkem_ciphertext || ecdh_pubkey  // 64 字节
    
    // 最终共享密钥
    sharedSecret = ecdh_shared || mlkem_shared

安全性特性：

• 降级安全性：即使 X25519 被破坏，ML-KEM 部分仍安全
• 后量子强度：MLKEM768 ≈ 192 位对称密钥强度
• 组合大小：64 字节（32B ECDH + 32B MLKEM）

5.3 AuthKey 派生

// HKDF-SHA256 派生
PRF = HKDF(
    hash: SHA256,
    ikm: sharedSecret,
    salt: clientRandom[:20],  // 前 20 字节
    info: []byte("REALITY"),
    length: 32  // AuthKey 长度
)

AuthKey = PRF[:32]

6. 应用数据加密

6.1 TLS 1.3 记录加密

REALITY 使用标准 TLS 1.3 记录层加密：

加密参数：

Cipher Suite: TLS_AES_128_GCM_SHA256  (推荐)
              TLS_CHACHA20_POLY1305_SHA256  (替代)
              TLS_AES_256_GCM_SHA384  (高强度)

Client Write Key: HKDF-Expand(clientTrafficSecret, "key", 16)
Client Write IV:  HKDF-Expand(clientTrafficSecret, "iv", 12)

Server Write Key: HKDF-Expand(serverTrafficSecret, "key", 16)
Server Write IV:  HKDF-Expand(serverTrafficSecret, "iv", 12)

记录格式：

+----------+------------------+----------+
| Header   | Ciphertext       | Tag      |
| 5 bytes  | variable         | 16 bytes |
+----------+------------------+----------+

Header = {
    ContentType: 0x17 (Application Data)
    Version: 0x0303 (TLS 1.2 wire format)
    Length: len(Ciphertext) + 16
}

Ciphertext = AES-128-GCM(
    key: Client/Server Write Key,
    nonce: IV ⊕ SeqNum,
    plaintext: ApplicationData,
    aad: Header
)

6.2 加密序列号管理

// 序列号字段
out.seq  // 8 字节，大端序，从 0 开始递增

// Nonce 计算
nonce = out.iv ⊕ out.seq  // 12 字节异或

// 每条消息后递增
out.seq++

7. 安全性分析

7.1 前向保密性

REALITY 的前向保密性分析：

✅ 强前向保密

• 每个连接独立的 X25519 临时私钥
• 服务端私钥泄露不影响历史会话
• 符合 TLS 1.3 RFC 8446 要求

⚠️ AuthKey 泄露风险

• AuthKey 用于客户端认证但不是会话密钥
• 若 AuthKey 泄露，攻击者可伪造客户端但无法解密应用数据
• 应用数据加密密钥独立于 AuthKey 派生

7.2 对主动探测的防护

防护机制：

时间检验：
- ClientTime 必须在 ±MaxTimeDiff 范围内（通常 1-3 小时）
- 防止探测者使用过期的 Client Hello 重放

版本检验：
- ClientVersion 必须在 [MinClientVer, MaxClientVer] 范围内
- 支持服务端渐进式升级客户端版本要求

ShortId 检验：
- ClientShortId 必须在 config.ShortIds 集合中
- 支持多用户隔离，每个用户对应特定 ShortId 集合

限制攻击者的尝试空间：
- ShortId 空间：2^64（实际使用 4-8 个）
- 时间窗口：±MaxTimeDiff（通常 3600 秒）
- 版本范围：通常 3-5 个版本

即使暴力破解：
- 尝试次数 ≈ 8 × 7200 = 57,600 次
- 实际网络环境中探测成本极高

7.3 对证书链攻击的防护

攻击场景 1：中间人替换证书

正常流程：
Client ← [临时证书] ← Server
- HMAC 验证通过 → 正常通信

中间人攻击：
Client ← [真证书] ← Attacker ← [真证书] ← Target
- HMAC 验证失败 → 进入爬虫模式
- 发送真实 HTTP 请求至真实目标
- 获得真实 HTTP 响应
- 完全隐蔽，无法识别代理行为

防护效果：

• 无法通过证书链被迫升级攻击
• 中间人只能两种选择：1) 转发真实连接 2) 中断连接
• 两种选择都无法识别代理

7.4 密码学强度评估

长期安全性（> 10 年）：

• 推荐启用 ML-DSA-65 签名选项
• 定期更新 MLKEM768 参数（若有新突破）
• 监控密码学研究进展

7.5 已知限制

1. 临时证书泄露风险

若攻击者获得 AuthKey：
- 可以生成有效的临时证书
- 但无法解密应用数据
- 无法伪造会话

防护：
- AuthKey 仅存储在内存，不持久化
- 连接断开后立即销毁
- 不同连接使用不同 AuthKey

2. 时间同步依赖

ClientTime 检验依赖客户端与服务端时间同步：
- 允许偏差范围（通常 ±1 小时）
- 若客户端时钟严重错误，连接失败
- 无法用于离线场景

3. 目标网站依赖

REALITY 的隐蔽性完全依赖目标网站选择：
- 若选择冷门网站 → 流量异常明显
- 若选择热门网站 → 与常规用户流量难以区分
- 目标网站关闭会导致代理不可用

8. 配置参数详解

8.1 服务端配置

{
    "streamSettings": {
        "security": "reality",
        "realitySettings": {
            "show": false,                          // 调试输出开关
            "dest": "google.com:443",              // 目标网站
            "serverNames": [
                "www.google.com",
                "mail.google.com"
            ],                                      // 允许的 SNI 列表
            "privateKey": "...",                   // X25519 私钥（base64）
            "maxTimeDiff": 3600000000000,          // 时间偏差上限（纳秒）
            "minClientVer": [0, 0, 0],             // 最小客户端版本
            "maxClientVer": [0, 0, 29],            // 最大客户端版本
            "shortIds": [
                "0123456789abcdef",               // 8 字节 ShortId（16 进制）
                "fedcba9876543210"
            ],
            "mldsa65Key": "...",                   // ML-DSA-65 私钥（可选）
            "limitFallback": {
                "bytesPerSec": 0,
                "burstBytesPerSec": 0
            }                                       // 回落限流
        }
    }
}

参数说明：

• dest：REALITY 转发的目标网站，格式 host:port
• serverNames：服务端接受的 SNI 值，支持多个
• privateKey：X25519 服务端私钥（生成: xray uuid + 转换）
• maxTimeDiff：客户端时间偏差容限（推荐 1-2 小时，单位纳秒）
• shortIds：客户端 ShortId 白名单，支持 1-8 条
• mldsa65Key：可选的 ML-DSA-65 私钥，启用后使用后量子签名

8.2 客户端配置

{
    "streamSettings": {
        "security": "reality",
        "realitySettings": {
            "show": false,                         // 调试输出开关
            "fingerprint": "chrome",               // uTLS 指纹（chrome, firefox 等）
            "serverName": "www.google.com",        // 目标 SNI
            "password": "...",                     // 服务端公钥（base64）
            "shortId": "0123456789abcdef",        // 8 字节 ShortId
            "spiderX": "/",                        // 爬虫初始路径
            "mldsa65Verify": "..."                // 服务端 ML-DSA-65 公钥（可选）
        }
    }
}

参数说明：

• fingerprint：客户端 TLS 指纹伪装（chrome 最普遍）
• serverName：连接的 SNI，须在服务端 serverNames 中
• password：服务端 X25519 公钥，用于派生 AuthKey
• shortId：须在服务端 shortIds 中
• spiderX：进入爬虫模式时的初始 HTTP 路径
• mldsa65Verify：验证服务端 ML-DSA-65 签名（启用后量子认证）

9. 与其他协议的对比

9.1 REALITY vs VMess

选择建议：

• 隐蔽性优先 → REALITY
• 轻量级/快速 → VMess（但已不安全）
• 通用性优先 → VMess 或 VLESS

9.2 REALITY vs Trojan

对比结论：

• Trojan 是传统代理的代表，配置简单但防护有限
• REALITY 是新一代设计，防护全面但需要理解其机制

9.3 REALITY vs VLESS-XTLS-Vision

实际应用：

• 若需要最高隐蔽性 → REALITY
• 若需要最高性能 → VLESS-XTLS-Vision
• 若综合考量 → VLESS-XTLS-Vision（成熟稳定）

10. 已知问题与限制

10.1 技术限制

问题 1：时间同步依赖

现象：连接提示"ClientTime 超出范围"
原因：客户端系统时间与服务端相差 > MaxTimeDiff
解决：同步系统时间（NTP）

问题 2：目标网站不可用

现象：代理连接中断，无法回落
原因：目标网站宕机或网络异常
解决：更换目标网站（推荐使用 CDN 服务）

问题 3：重复 ShortId 检验失败

现象：某些特定 ShortId 客户端连接失败
原因：ShortId 与其他用户冲突或被污染
解决：更换 ShortId 或增加 MaxTimeDiff 限制

10.2 实现限制

限制 1：握手记录预检测

REALITY 需要预先检测目标网站的握手消息长度
- 首次部署需要运行专用工具采集目标网站特征
- 目标网站握手行为变化需要重新采集
- 部分云环境可能不支持长连接探测

限制 2：与代理协议的组合

REALITY 仅支持与特定协议组合：
- ✓ VLESS + XTLS-Vision  （推荐）
- ✓ VLESS-gRPC           （可用）
- ✗ VMess                (特征明显)
- ✗ Shadowsocks          (不兼容)

11. 最佳实践

11.1 服务端部署

步骤 1：生成密钥对

# 生成 X25519 私钥
xray uuid | sha256sum  # 或使用专门工具
# 输出格式：xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# 计算公钥（通常由 xray 自动计算）

步骤 2：选择目标网站

推荐目标网站特性：
- 位于 GFW 域外且支持 TLS 1.3、HTTP/2
- 流量大且用户多（便于混淆）
- IP 地址稳定（避免 CDN 频繁变化）

推荐目标：
- google.com（全球用户最多）
- cdn.jsdelivr.net（建站者常用）
- www.microsoft.com（企业信任度高）

步骤 3：配置参数

// 严格模式（高安全）
{
    "maxTimeDiff": 1800000000000,    // ±30 分钟
    "minClientVer": [0, 0, 20],      // 禁用旧版本
    "maxClientVer": [0, 0, 29],      // 限制最新版本
    "shortIds": ["0123456789abcdef"]  // 单用户
}

// 宽松模式（易用性优先）
{
    "maxTimeDiff": 3600000000000,     // ±1 小时
    "minClientVer": [0, 0, 0],
    "maxClientVer": [255, 255, 255],
    "shortIds": ["0123456789abcdef", "fedcba9876543210", "..."]
}

11.2 客户端连接

调试技巧：

启用调试输出：
realitySettings: {
    "show": true,  // 输出详细日志
}

查看日志：
- "REALITY remoteAddr: ..."     握手地址
- "ClientVer: ..."              客户端版本
- "ClientTime: ..."             时间检验
- "hs.c.conn == conn"           认证结果（true 成功）

常见错误排查：

错误：authentication failed or validation criteria not met
原因：
1. ClientTime 超出范围 → 同步系统时间
2. ShortId 不在白名单 → 检查配置
3. 客户端版本不匹配 → 检查 minClientVer/maxClientVer
解决：逐项检查上述条件

错误：server name mismatch
原因：serverName 不在服务端 serverNames 中
解决：确保客户端 serverName 在服务端配置中

12. 总结

12.1 优势总结

✅ 服务端无指纹：完全伪装为任意目标网站
✅ 防护全面：时间、版本、ShortId 多层防护
✅ 后量子就绪：集成 MLKEM768 和 ML-DSA-65
✅ 部署灵活：无需自有域名和证书
✅ 性能优异：无加密开销，替代原生 TLS
✅ 安全创新：证书链攻击无效，爬虫模式隐蔽

12.2 劣势与限制

❌ 时间依赖：客户端需要精确的系统时间
❌ 目标依赖：代理可用性依赖目标网站
❌ 生态有限：相比 VMess/Trojan 生态尚未成熟
❌ 学习曲线：需要理解多个密码学概念
❌ 握手预检：部分环境部署复杂

12.3 未来展望

即将推出的功能：

1. 预先构建模式（Pre-built Mode）

   • 提前采集目标网站握手特征
   • 无需实时探测，提升速度

2. 0-RTT 支持

   • 结合 TLS 1.3 Early Data
   • 消除握手延迟

3. QUIC 支持

   • 扩展至 QUIC 层
   • 支持 0-RTT 和连接迁移

4. 多目标策略

   • 支持同时指向多个目标网站
   • 动态选择策略优化

12.4 推荐使用场景

12.5 安全建议

1. 定期更新

   • 关注 XTLS/Xray 项目更新
   • 及时采用新的后量子算法参数

2. 多用户隔离

   • 为每个用户配置独立 ShortId
   • 定期轮换 ShortId 集合

3. 时间保持同步

   • 服务端和客户端启用 NTP
   • 建议使用公共 NTP 服务器

4. 目标网站选择

   • 避免使用冷门/小型网站
   • 定期检查目标网站可用性

5. 日志监控

   • 启用调试输出分析连接行为
   • 识别异常流量模式

参考资源

• XTLS/REALITY GitHub
• XTLS/Xray-core
• RFC 8446: TLS 1.3
• HKDF: RFC 5869
• ML-KEM/Kyber
• ML-DSA/Dilithium

本文档基于 REALITY 协议源代码和 RFC 标准编写，内容准确性以官方文档为准。