REALITY 技术深度解析从 TLS 伪装、抗主动探测到 VLESS + XTLS Vision 完整实践

一、先说结论：REALITY 到底是什么？

一句话概括：

REALITY 是 Xray 中工作在 TLS/传输安全层的一套机制，用目标站点的 TLS 外观配合自己的客户端认证，使合法客户端能够建立代理连接，而无法通过 REALITY 认证的连接则表现得更接近正常目标站 TLS 访问。

因此，它不是：

不是 VLESS 的替代品；
不是 XTLS Vision 的替代品；
不是简单的 HTTPS 反向代理；
不是"复制别人证书"；
也不是一套完全独立于 TLS 的新传输协议。

更准确的分层如下。

可以把整个链路理解为：

text 复制代码

应用
  ↓
VLESS
  ↓
XTLS Vision
  ↓
REALITY
  ↓
uTLS / TLS ClientHello
  ↓
RAW/TCP
  ↓
IP

各层职责完全不同：

组件	主要职责
VLESS	用户身份、代理协议、UUID
XTLS Vision	流控与 TLS 流量优化
REALITY	TLS 外观、握手认证、目标站 fallback
uTLS	模拟浏览器 TLS ClientHello 指纹
RAW/TCP	底层可靠传输
XHTTP/gRPC	可选的其他承载方式

理解这一点以后，后面的所有配置都会变得很清楚。

二、为什么会出现 REALITY？

传统方案很常见：

text 复制代码

客户端
   ↓
VLESS
   ↓
TLS
   ↓
your-domain.com
   ↓
你的 TLS 证书
   ↓
服务器

也就是说，你通常需要：

买一个域名；
把域名解析到服务器；
申请 TLS 证书；
部署证书；
让客户端用这个域名连接。

从正常互联网服务角度看，这完全没有问题。

问题在于，如果我们研究的是网络流量识别与主动探测，传统 TLS 服务会自然暴露一整套属于自己的网络身份：

text 复制代码

Server IP
   │
   ├── Domain
   ├── Certificate
   ├── TLS Parameters
   ├── ASN
   └── Application Behavior

REALITY 的设计思路则不同。

它不要求服务器持有 target 网站的私钥，而是利用目标网站的 TLS 握手特征和 REALITY 自己的认证逻辑，把"代理服务身份"和"普通 TLS 外观"拆开。

普通 TLS

text 复制代码

客户端
   ↓
你的服务器
   ↓
你的证书
   ↓
your-domain.com

REALITY

text 复制代码

REALITY Client
   ↓
Xray REALITY Server
   ├── REALITY 验证成功 → VLESS
   └── 验证失败 → target

因此最重要的区别之一是：

REALITY 服务器不需要拥有 target 网站的证书私钥。

这也是为什么 REALITY 配置里会出现：

json 复制代码

"target": "example.com:443",
"serverNames": [
  "example.com"
]

却没有：

text 复制代码

certificate.pem
private.key

这样的站点证书文件。

三、REALITY 真正厉害的地方：认证失败也不像普通"失败"

要理解 REALITY，必须先理解"主动探测"。

假设某个扫描系统发现：

text 复制代码

203.0.113.10:443

它可能主动连接这个地址，然后发送各种请求：

text 复制代码

TLS ClientHello
HTTP Request
随机字节
协议探测包

如果服务器返回非常特殊的结果，例如：

text 复制代码

Connection reset
Unknown protocol
固定错误码
特殊握手数据

那就可能形成稳定特征。

REALITY 的核心设计之一就是：

text 复制代码

未知连接
   ↓
REALITY Server
   ↓
REALITY 验证失败
   ↓
target

也就是说，非 REALITY 请求并不一定简单暴露一个明显的"代理协议错误"。

官方文档明确提醒：REALITY 会把未通过认证的流量直接转发到 target。

这既是它的重要能力，也是一个需要认真理解的工程风险。

假设：

text 复制代码

target = 某大型 CDN 网站

那么：

text 复制代码

扫描器
   ↓
你的服务器
   ↓
CDN

在某些情况下，你的服务器可能事实上变成一个转发入口。

所以"认证失败转发 target"不能只看到隐蔽性，也必须看到资源滥用风险。

四、一次 REALITY 握手到底发生了什么？

可以把完整过程抽象成下面几步。

第 1 步：客户端连接 REALITY Server

客户端首先连接服务器：

text 复制代码

SERVER_IP:443

底层可能是：

text 复制代码

RAW/TCP

客户端不会直接发送一段明显的"我是 VLESS"的明文标记，而是从 TLS/REALITY 握手开始。

第 2 步：客户端构造 ClientHello

客户端会使用类似：

json 复制代码

"fingerprint": "chrome"

这样的配置。

这里的 fingerprint 不是浏览器 User-Agent。

它针对的是 TLS ClientHello 特征。

TLS ClientHello 中包含大量可以形成指纹的数据：

text 复制代码

TLS Version
Cipher Suites
Extensions
Extension Order
Supported Groups
Key Share
ALPN
Signature Algorithms
Session ID
SNI
...

不同 TLS 实现产生的 ClientHello 并不完全一致。

例如：

text 复制代码

Chrome
Firefox
Safari
Go crypto/tls
Java JSSE
OpenSSL

往往具有不同的 TLS 指纹。

REALITY 客户端依赖 uTLS 操作底层 TLS 参数，因此官方当前文档中 fingerprint 是客户端 REALITY 的关键字段，而且不能使用会关闭 uTLS 的 unsafe 方式。

第 3 步：发送 serverName

例如：

json 复制代码

"serverName": "www.example.com"

TLS 里常见的 SNI：

text 复制代码

Server Name Indication

大致告诉服务器：

text 复制代码

"我准备访问 www.example.com"

REALITY 服务端配置：

json 复制代码

"serverNames": [
  "www.example.com"
]

客户端的 serverName 必须符合服务端允许范围。

通常它应该和 target 的真实证书/SNI 行为保持一致。

第 4 步：REALITY 完成自己的服务端认证

REALITY 还需要一对 X25519 参数。

服务端生成：

bash 复制代码

xray x25519

你会得到对应的私钥和客户端使用的参数。

概念上：

text 复制代码

Server
  └── PrivateKey

Client
  └── password
      └── 对应服务器 X25519 公钥材料

旧版教程经常把客户端字段写成：

json 复制代码

"publicKey": "..."

当前官方 REALITY 文档已经把客户端字段改称：

json 复制代码

"password": "..."

它本质上仍然对应 X25519 公钥，但官方特意改名，是为了避免开发者误以为它应该像普通公开公钥一样到处发布。

第 5 步：REALITY 客户端验证临时可信证书

REALITY 并不是简单接受任意 TLS 证书。

客户端需要区分：

text 复制代码

REALITY Temporary Trusted Certificate
真实 target Certificate
无效 Certificate

官方 REALITY 项目描述的逻辑大致是：

text 复制代码

收到 REALITY 临时可信证书
        ↓
代理连接继续

收到 target 真实证书
        ↓
进入相应处理逻辑

收到无效证书
        ↓
TLS Alert / 断开

因此 REALITY 的安全边界不是"关闭证书验证"。

恰恰相反，它加入了自己的证书验证逻辑。

第 6 步：REALITY 成功后再进入 VLESS

REALITY 验证成功之后，才进入：

text 复制代码

VLESS

然后进行：

text 复制代码

UUID
flow
代理目标

等处理。

因此一条典型链路实际上是：

text 复制代码

TCP
  ↓
REALITY
  ↓
VLESS
  ↓
XTLS Vision
  ↓
目标连接

这也是为什么不能说：

"用了 REALITY 就不需要 VLESS。"

REALITY 解决 TLS/传输安全问题。

VLESS 解决代理协议和用户身份问题。

五、UUID、X25519、ShortID 到底有什么区别？

这是 REALITY 最容易配置错的地方之一。

1. UUID

例如：

text 复制代码

550e8400-e29b-41d4-a716-446655440000

负责：

text 复制代码

VLESS 用户身份

可以理解成：

text 复制代码

"这个用户是谁？"

生成：

bash 复制代码

xray uuid

2. X25519

服务端：

json 复制代码

"privateKey": "..."

客户端：

json 复制代码

"password": "..."

负责 REALITY 的服务端认证/握手体系。

可以理解成：

text 复制代码

"我连接的是不是持有正确 REALITY 私钥的服务器？"

生成：

bash 复制代码

xray x25519

如果已经有服务端私钥，也可以派生客户端对应参数：

bash 复制代码

xray x25519 -i "SERVER_PRIVATE_KEY"

3. ShortID

服务端：

json 复制代码

"shortIds": [
  "6ba85179e30d4fc2"
]

客户端：

json 复制代码

"shortId": "6ba85179e30d4fc2"

ShortID 可以用来区分 REALITY 客户端。

当前官方规则是：

text 复制代码

最长 8 Byte
= 最多 16 个十六进制字符

并且字符数量必须为偶数。

正确：

text 复制代码

aa
aa12
aa1234
0123456789abcdef

错误示例：

text 复制代码

abc
abcde

因为十六进制两个字符才表示一个字节。

六、serverName 和 target 到底是什么关系？

假设服务端：

json 复制代码

"target": "www.example.com:443",
"serverNames": [
  "www.example.com"
]

其中：

target

代表 REALITY 要借用握手外观并承接 fallback 的目标。

serverNames

代表服务器允许客户端携带的 serverName。

客户端：

json 复制代码

"serverName": "www.example.com"

最简单的工程原则就是：

text 复制代码

target
   ↓
真实 TLS 证书
   ↓
SAN / SNI
   ↓
serverNames

不要理解成：

text 复制代码

target 随便写
serverName 随便写

REALITY 的效果高度依赖网络行为是否合理。

七、target 应该怎么选？

这是部署 REALITY 时比"抄 JSON"更重要的事情。

1. 优先现代 TLS

建议目标具备：

text 复制代码

TLS 1.3

并具有现代浏览器常见的 TLS 行为。

2. HTTP/2 是常见加分项

常见 HTTPS 网站通常支持：

text 复制代码

ALPN:
h2
http/1.1

如果目标站行为本身非常古老，而你的客户端却模拟最新 Chrome，整体网络行为可能不够自然。

3. serverName 必须是目标真实接受的 SNI

常见做法：

text 复制代码

查看 target 返回证书
      ↓
读取 SAN
      ↓
选择正确 serverName

而不是凭感觉填域名。

4. 网络位置要合理

当前官方文档特别提到一个非常重要的最佳实践：

尽量借用相同 ASN 或网络位置合理的目标证书/站点。

为什么？

假设：

text 复制代码

服务器 ASN = 某东京云厂商

但是：

text 复制代码

SNI / target 的网络特征 = 完全不同地区、完全不同运营商

虽然单个 TLS 包可能看起来合理，但从更高维度观察：

text 复制代码

IP
ASN
RTT
TLS
路由
SNI
行为

组合起来仍可能不自然。

所以不要只研究 TLS 指纹。

现代流量识别看的是多个特征组合。

5. target 必须稳定

如果 target 经常：

text 复制代码

宕机
证书异常
TLS 行为变化
限制连接

REALITY 的稳定性自然会受到影响。

生产环境中需要定期检查：

text 复制代码

DNS
TCP/443
TLS 握手
证书
HTTP/2
延迟

6. 警惕 CDN 转发器问题

官方特别警告：

如果 target 位于某些 CDN 后面，未认证请求又全部 fallback 到 target，那么你的 REALITY Server 可能被扫描后当成转发入口使用。

当前 REALITY 提供：

json 复制代码

"limitFallbackUpload": {},
"limitFallbackDownload": {}

用于限制未认证 fallback 流量。

但是官方同样提醒：

固定的 fallback 限速本身也可能成为特征。

所以生产环境里不能机械地"全部打开"。

八、uTLS 到底解决什么问题？

很多人看到：

json 复制代码

"fingerprint": "chrome"

会误以为只是修改 User-Agent。

其实完全不是。

HTTP User-Agent：

http 复制代码

User-Agent: Mozilla/5.0 ...

工作在 HTTP 层。

TLS Fingerprint：

text 复制代码

ClientHello

发生得更早。

可以粗略表示：

text 复制代码

TCP
 ↓
TLS ClientHello
 ↓
TLS Handshake
 ↓
HTTP
 ↓
User-Agent

DPI 在 HTTP 请求出现之前，就可以分析 TLS ClientHello。

常见 TLS 指纹特征包括：

text 复制代码

Cipher Suite 顺序
Extension 顺序
Supported Groups
Key Share
ALPN
Signature Algorithms
GREASE
Session ID
TLS Version

因此：

json 复制代码

"fingerprint": "chrome"

解决的是：

让 REALITY 客户端 TLS ClientHello 更接近对应浏览器家族的网络行为。

它不是修改浏览器字符串。

九、Vision 又是什么？为什么常和 REALITY 一起出现？

典型配置：

json 复制代码

"flow": "xtls-rprx-vision"

Vision 属于 XTLS 流控体系。

它和 REALITY 并不是竞争关系。

可以这样理解：

text 复制代码

VLESS
负责代理协议

Vision
负责流控优化

REALITY
负责 TLS 安全与外观

uTLS
负责客户端 TLS 指纹

RAW
负责底层传输

所以：

text 复制代码

VLESS + Vision + REALITY

是完全合理的组合。

十、完整服务端配置示例

下面使用当前 Project X 文档风格编写一个容易理解的最小示例。

注意：示例中的 IP、UUID、密钥、ShortID 和 target 都必须替换，不能直接用于生产。

json 复制代码

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "users": [
          {
            "id": "YOUR_UUID",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "target": "www.example.com:443",
          "serverNames": [
            "www.example.com"
          ],
          "privateKey": "SERVER_PRIVATE_KEY",
          "shortIds": [
            "6ba85179e30d4fc2"
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

核心只有几部分。

VLESS

json 复制代码

"protocol": "vless"

Vision

json 复制代码

"flow": "xtls-rprx-vision"

RAW

json 复制代码

"network": "raw"

旧版示例中经常能看到：

json 复制代码

"network": "tcp"

阅读旧文章时要注意 Xray 配置文档与字段命名经历过演进。

REALITY

json 复制代码

"security": "reality"

target

json 复制代码

"target": "www.example.com:443"

老教程常见：

json 复制代码

"dest": "www.example.com:443"

当前官方文档使用 target，并说明旧名称 dest 仍作为别名存在。

PrivateKey

json 复制代码

"privateKey": "SERVER_PRIVATE_KEY"

只能保存在服务器。

不要发布。

十一、完整客户端配置示例

json 复制代码

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "address": "YOUR_SERVER_IP",
        "port": 443,
        "id": "YOUR_UUID",
        "encryption": "none",
        "flow": "xtls-rprx-vision"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "fingerprint": "chrome",
          "password": "SERVER_X25519_PASSWORD",
          "shortId": "6ba85179e30d4fc2",
          "spiderX": "/"
        }
      },
      "tag": "proxy"
    }
  ]
}

其中最关键的对应关系：

text 复制代码

Server UUID
      =
Client UUID

text 复制代码

Server privateKey
      ↕ X25519 对应
Client password

text 复制代码

Server shortIds
      包含
Client shortId

text 复制代码

Server serverNames
      包含
Client serverName

十二、生成 UUID、X25519 和 ShortID

UUID

bash 复制代码

xray uuid

X25519

bash 复制代码

xray x25519

如果需要从服务端私钥重新得到客户端对应参数：

bash 复制代码

xray x25519 -i "SERVER_PRIVATE_KEY"

ShortID

可以使用安全随机数。

Linux：

bash 复制代码

openssl rand -hex 8

例如：

text 复制代码

6ba85179e30d4fc2

注意：

text 复制代码

不要把 UUID
当 ShortID

不要把 privateKey
填进客户端

不要把客户端 password
误填成 UUID

它们是完全不同的字段。

十三、配置完成以后怎么检查？

先不要直接重启生产服务。

可以使用 Xray 自带的配置测试：

bash 复制代码

xray run -test -c /etc/xray/config.json

如果配置正确，再启动：

bash 复制代码

xray run -c /etc/xray/config.json

如果通过 systemd 管理：

bash 复制代码

systemctl restart xray
systemctl status xray

实时日志：

bash 复制代码

journalctl -u xray -f

十四、怎么检查 target？

当前 Xray 提供：

bash 复制代码

xray tls ping example.com

它可以辅助观察 target TLS 行为。

对 REALITY 来说，target 验收至少应该考虑：

text 复制代码

1. DNS 是否稳定
2. TCP 443 是否稳定
3. TLS 握手是否正常
4. TLS 1.3 是否支持
5. HTTP/2 是否支持
6. 证书 SAN 是否匹配
7. 网络位置是否合理
8. 延迟是否稳定
9. 是否容易形成 fallback 滥用

这一步比"网上抄一个热门域名"重要得多。

十五、2026 年值得注意的后量子能力

REALITY 现在还有一块很多旧教程没有写到的内容：

json 复制代码

"mldsa65Seed": ""

客户端：

json 复制代码

"mldsa65Verify": ""

对应：

text 复制代码

ML-DSA-65

用于增加额外的后量子签名验证能力。

生成：

bash 复制代码

xray mldsa65

另外，当前官方文档指出，如果 target 支持：

text 复制代码

X25519MLKEM768

REALITY 客户端也可以利用相应的后量子密钥交换能力。

可以用：

bash 复制代码

xray tls ping example.com

观察目标能力。

这里需要强调：

后量子能力不是"打开一个字段就自动万事大吉"。

你还要考虑：

text 复制代码

target 证书长度
target TLS 能力
客户端版本
服务端版本
整体流量特征

因此更适合高级用户和受控环境测试。

十六、REALITY 支持哪些传输？

旧教程经常把 REALITY 直接等价成：

text 复制代码

VLESS + TCP + REALITY

但当前官方文档已经明确：

text 复制代码

REALITY
可与

RAW
XHTTP
gRPC

组合

所以我们现在应该把 REALITY 理解为：

text 复制代码

Transport Security Layer

而不是：

text 复制代码

TCP 专属协议

例如：

text 复制代码

VLESS
 + RAW
 + Vision
 + REALITY

是一种组合。

而：

text 复制代码

VLESS
 + XHTTP
 + REALITY

则是另一种组合。

它们底层目标和网络行为并不完全一样。

十七、RAW + Vision + REALITY 为什么一直很经典？

因为它结构非常直接：

text 复制代码

VLESS
   ↓
Vision
   ↓
REALITY
   ↓
RAW/TCP

没有额外：

text 复制代码

WebSocket
Nginx
CDN
HTTP Reverse Proxy

数据路径短。

从架构角度看：

text 复制代码

组件越少
    ↓
故障点越少
    ↓
排查越简单

对于点对点、TCP 质量良好的服务器，这是它最大的工程优势之一。

但"最简单"不代表任何网络环境下都是最优。

如果环境更适合：

text 复制代码

HTTP 化承载
中间代理
特殊链路
复杂网络调度

那么 XHTTP 等方案可能更合适。

所以 REALITY 是安全层，不应该孤立决定整个传输选型。

十八、REALITY 和传统 TLS 怎么选？

可以简单比较：

维度	普通 TLS	REALITY
自有域名	通常需要	通常不需要
自有站点证书	需要	不需要 target 私钥
ACME	常用	非必需
TLS 外观	自己站点	借用 target 行为
主动探测处理	自己设计 fallback	REALITY 内建 target 转发逻辑
uTLS	可选	REALITY 依赖
X25519 参数	无 REALITY 参数	需要
ShortID	不需要	支持
Vision	可组合	常见组合
运维复杂度	域名+证书体系	target+密钥体系

如果你本身就有：

text 复制代码

高质量域名
稳定网站
正常 HTTPS 业务
成熟证书自动化

普通 TLS 并不是"落后方案"。

如果希望：

text 复制代码

不维护自有 TLS 站点证书
利用 REALITY 客户端认证
增强主动探测场景下的外观一致性

REALITY 更有意义。

十九、REALITY 不是"绝对不可识别"

这是整篇文章最需要强调的一点。

网上经常会出现：

text 复制代码

REALITY 100% 无法识别

这种表述并不科学。

现代网络流量分析不只看：

text 复制代码

TLS Certificate

还可以观察：

text 复制代码

IP
ASN
SNI
RTT
JA3 / JA4 类 TLS 指纹
TCP 指纹
包长
包间隔
连接持续时间
上下行比例
访问行为
目标站合理性
历史统计
主动探测结果

因此：

text 复制代码

REALITY
≠
数学意义上的不可识别

更准确的说法是：

REALITY 在 TLS 外观、客户端认证以及主动探测处理方面做了非常有针对性的设计，可以显著减少传统代理 TLS 服务中的一些明显身份特征，但整体可识别性仍然取决于完整网络行为。

二十、生产环境最容易踩的 10 个坑

1. privateKey 和 password 填反

正确：

text 复制代码

Server → privateKey
Client → password

2. serverName 不在 serverNames 中

服务端：

json 复制代码

"serverNames": [
  "www.example.com"
]

客户端必须对应。

3. ShortID 长度错误

ShortID：

text 复制代码

十六进制
偶数长度
最长 16 个字符

4. target 证书不匹配 serverName

必须检查：

text 复制代码

SAN
SNI

5. 直接复制几年以前教程

REALITY/Xray 配置字段一直在演进。

典型变化包括：

text 复制代码

dest → target
publicKey → password
tcp → RAW 文档命名

阅读旧文章时必须和当前官方文档对照。

6. 只看 TLS，不看 ASN

一个 TLS ClientHello 看起来像 Chrome，并不代表整个连接就一定像普通 Chrome 用户。

需要看：

text 复制代码

IP + ASN + SNI + TLS + 行为

整体组合。

7. target 选大型 CDN 后不考虑 fallback 滥用

可能把你的服务器变成不希望出现的转发入口。

8. 盲目打开 fallback 限速

官方提醒：

text 复制代码

固定限速模式
本身可能成为可识别特征

需要结合真实需求判断。

9. 日志长期 debug

部署测试：

json 复制代码

"loglevel": "debug"

可以。

生产长期运行建议控制日志级别，避免：

text 复制代码

磁盘占满
敏感调试信息
过量 IO

10. 把 REALITY 当成整个网络架构

REALITY 只负责其中一层。

生产架构还要考虑：

text 复制代码

路由
DNS
负载
故障摘除
出口质量
拥塞控制
MTU
监控
限流
用户管理
升级策略

二十一、一个成熟的 REALITY 技术栈应该怎么理解？

最后，把所有东西再组合一次。

text 复制代码

┌─────────────────────────┐
│        Application      │
│ Browser / App / TUN     │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│          VLESS          │
│ UUID / Proxy Protocol   │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│      XTLS Vision        │
│ xtls-rprx-vision        │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│        REALITY          │
│ X25519 / ShortID / SNI  │
│ Temporary Certificate   │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│          uTLS           │
│ Chrome TLS Fingerprint  │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│        RAW / TCP        │
│          :443           │
└────────────┬────────────┘
             │
             ▼
          Internet

对应职责：

text 复制代码

VLESS
= 我是谁

Vision
= 数据怎么高效流动

REALITY
= TLS 安全和握手外观怎么建立

uTLS
= ClientHello 看起来像什么客户端

RAW/TCP
= 数据最终怎么传输

这才是理解：

text 复制代码

VLESS + XTLS Vision + REALITY

最准确的方法。

二十二、总结

REALITY 最值得学习的并不是它的 JSON 配置，而是它背后的设计思想：

第一，协议分层

它没有重新发明整个代理协议。

而是专注改造：

text 复制代码

TLS / Transport Security

这一层。

第二，把"合法客户端"和"普通探测者"分开

合法客户端：

text 复制代码

REALITY Authentication
        ↓
VLESS

其他流量：

text 复制代码

REALITY Authentication Failed
        ↓
target

第三，不只关注加密，也关注流量外观

传统安全工程经常问：

text 复制代码

数据有没有加密？

而 REALITY 关注的另一个问题是：

text 复制代码

加密连接在网络上"看起来像什么"？

第四，安全从来不是一个协议字段解决的

真正成熟的部署必须同时考虑：

text 复制代码

TLS
TCP
ASN
target
SNI
DNS
路由
客户端指纹
链路稳定性
监控
资源滥用

所以 REALITY 很强，但它不是魔法。

如果只记一句话：

REALITY 是一套围绕 TLS 外观、服务端认证与主动探测处理设计的 Xray 传输安全机制；VLESS 负责代理身份，Vision 负责流控，uTLS 负责客户端 TLS 指纹，它们组合起来才构成完整链路。

参考资料

本文技术内容基于并交叉核对以下官方资料（2026 年 8 月）：

Project X 官方文档：REALITY
Project X 官方文档：VLESS（XTLS Vision Seed）
Project X 官方文档：Command Line Parameters
XTLS/REALITY 官方项目 README
XTLS/Xray-core 官方项目
XTLS/Xray-examples 官方示例库

说明： Xray-core 更新较快，dest/target、publicKey/password、tcp/raw 以及 VLESS 配置结构在不同时期的文章和示例中可能出现不同写法。生产部署前应以你所使用版本对应的官方文档和 xray run -test 结果为准。

官方资料与版本说明

本文按 2026 年 8 月的 Project X / XTLS 文档校验。Xray-core 更新较快，部署时建议始终以当前版本官方文档为准。

Project X REALITY：https://xtls.github.io/en/config/transports/reality.html
Project X Transport Configuration：https://xtls.github.io/en/config/transport.html
Project X VLESS Inbound：https://xtls.github.io/en/config/inbounds/vless.html
Project X VLESS Outbound：https://xtls.github.io/en/config/outbounds/vless.html
XTLS/REALITY：https://github.com/XTLS/REALITY
XTLS/Xray-core：https://github.com/XTLS/Xray-core
XTLS/Xray-examples：https://github.com/XTLS/Xray-examples