Reality 协议是什么？VLESS + Reality 的原理与客户端
梯子岛编辑部 · 更新于 Reality 协议指 REALITY 这套改造过的 TLS 传输安全方案，服务端借用真实目标站的握手外观，常与 VLESS 加 XTLS Vision 搭配。它有传输方式和目标站的限制，并非万能选项。
REALITY（VLESS + REALITY 组合） 资料卡核验于 2026-10-09
- 来历
- Project X 的 XTLS/REALITY 仓库（github.com/XTLS/REALITY）：README 称服务端是对最新 Go 语言 crypto/tls 包的 fork，客户端实现见 Xray-core 的 reality.go。Xray 文档（xtls.github.io 的 transports/reality）将其作为传输安全方式之一。
- 传输与加密
- security 设为 reality，仅可配合 raw、xhttp、grpc 传输。服务端配 target、serverNames、私钥、shortIds；客户端配公钥、shortId、fingerprint。
- 官方文档写明支持的内核
- Xray-core、sing-box、Mihomo
- 相关 RFC
- RFC 8446
站内收录的客户端里，文档写明支持 Reality 的
- mihomo
- v2rayN
- v2rayNG
- Xray-core
- sing-box
- Hiddify
- NekoBox for Android
- Throne
- Quantumult X
- Stash
- Loon
- OpenClash
- PassWall
完整对照见协议 × 客户端支持矩阵。
Xray 文档：REALITYXTLS/REALITY 仓库（README）Xray 文档：传输配置与兼容表sing-box 文档：TLS（含 Reality Fields）Mihomo 文档：VLESS（reality-opts）
这张卡片的资料来源（9 条）
- REALITY 是改造过的 TLS，借用目标站的外观与握手特征；只能与 RAW、XHTTP、gRPC 搭配；target/serverNames/privateKey/shortIds/mldsa65Seed 等字段；未通过认证的流量转发到 target 的警告；X25519MLKEM768（xtls.github.io）
- REALITY 仓库 README：服务端是 Go crypto/tls 的 fork，客户端见 Xray-core reality.go；取代 TLS 可消除服务端 TLS 指纹；可指向他人网站；三种证书情形与客户端动作；不建议搭配 XTLS 以外协议；目标站需 TLS 1.3 与 H2（github.com）
- 传输方式与传输安全兼容表：reality 对 websocket、httpupgrade、mkcp 为 Not supported（xtls.github.io）
- sing-box TLS 配置页含 Reality Fields（handshake、private_key、public_key、short_id 等）（sing-box.sagernet.org）
- Mihomo 的 vless 配置含 reality-opts（wiki.metacubex.one）
- Mihomo 的 vmess 配置含 reality-opts（wiki.metacubex.one）
- Mihomo 的 trojan 配置含 reality-opts（wiki.metacubex.one）
- Mihomo 的 AnyTLS 页声明不支持 AnyTLS+Reality，若需 Reality 请选 VMess、VLESS 或 Trojan（wiki.metacubex.one）
- RFC 8446 定义 TLS 1.3，REALITY README 对目标站的最低要求是支持 TLSv1.3 与 H2（www.rfc-editor.org）
这里说的 Reality 协议，指的是 Project X 体系里一种叫 REALITY 的传输安全方案，不是某个同名软件。它是一套改造过的 TLS：服务端借用某个真实目标网站的握手外观，校验通过的连接进入代理，没通过的连接被转发到那个目标网站。它常与 VLESS 加 XTLS Vision 流控搭配，合称 VLESS+REALITY。下面依据官方仓库和文档，讲清它的机制、限制，以及客户端要满足什么条件。
Reality 协议是什么：借来的握手外观
REALITY 的代码仓库是 XTLS/REALITY，README 称服务端是对最新 Go 语言 crypto/tls 包的 fork，客户端实现见 Xray-core 的 reality.go。Xray 文档把它作为传输安全方式之一，页面在 Xray 文档：REALITY。它的别名常写成 VLESS-XTLS-uTLS-REALITY 或 VLESS+REALITY，所以你看到这些写法，指的是同一件事。
先弄清 reality是什么，可以抓住这几点：
- 它替代的是 TLS 这一层。README 称，用 REALITY 取代 TLS，可以消除服务端自身的 TLS 指纹特征。
- 目标站可以是别人的网站。README 说明目标可以指向他人网站，使用者无需自己的域名和 TLS 服务端。
- 客户端模拟浏览器。客户端用 uTLS 库模拟浏览器的 TLS 指纹，默认是 chrome。
- 它不是一个独立的代理协议。真正转发数据的仍是 VLESS 这类协议，REALITY 只负责外层的传输安全。
这些都是仓库 README 和 Xray 文档的说法。梯子岛没有任何自己的测试数据，不判断这些设计在你的网络里效果如何。REALITY 没有独立的 RFC，它所依据的 TLS 1.3 标准是 RFC 8446。
客户端怎么分辨“自己人”：三种证书与三种反应
REALITY 里最容易被误解的是“客户端怎么知道连的是对的服务器”。README 的说明是，客户端能区分三种证书，并分别采取不同动作：
| 客户端收到的证书 | 客户端怎么做 |
|---|---|
| 临时可信证书 | 正常使用，进入代理流程 |
| 目标站的真实证书 | 进入爬虫模式（spiderX） |
| 无效证书 | 发出 TLS alert 并断开 |
换句话说，服务端对通过校验的连接和没通过校验的连接给出不同的“面孔”，而客户端要识别出前者。这也是为什么 REALITY 的客户端配置里，除了服务器地址和 UUID，还要有公钥、shortId 和 fingerprint 这几项，它们是 Xray 文档列出的客户端参数。服务端一侧需要配置 target、serverNames、私钥和 shortIds，那是节点提供方的事，客户端使用者不用也看不到私钥。
vless reality 为什么总是成套出现
vless reality 容易被当成一个整体，其实它是两层：
| 层次 | 负责什么 | 在节点里对应什么 |
|---|---|---|
| VLESS | 认证与转发，用 UUID 标识 | 协议类型、id、encryption、flow |
| REALITY | 外层传输安全 | security 设为 reality，以及公钥、shortId、fingerprint |
README 不建议把 REALITY 搭配 XTLS 以外的代理协议，理由是它们存在明显的 TLS in TLS 特征，而 VLESS 的 xtls-rprx-vision 流控正是为 XTLS 设计的。所以文档里的典型组合是 VLESS 加 Vision，这是由 README 的建议推出来的，不是梯子岛对节点的统计。
不过配置格式上的支持范围更宽：Mihomo 文档的 vless、vmess、trojan 三个页面里都出现了 reality-opts，而它的 AnyTLS 页明确写了不支持 AnyTLS 加 Reality，需要 Reality 时请选 VMess、VLESS 或 Trojan。也就是说，某个客户端“能填”并不等于“文档推荐”。VLESS 协议本身的细节见 VLESS 协议，Vision 流控的简要解释见词典里的 XTLS Vision。
xtls reality 的限制：传输方式、目标站与已知警告
查 xtls reality 的资料时，最重要的不是“它能做什么”，而是“它不能做什么”。Xray 文档和 README 一共写了下面几条：
| 项目 | 文档怎么说 | 对你意味着什么 |
|---|---|---|
| 可搭配的传输 | 只能与 raw、xhttp、grpc 搭配 | 兼容表中 websocket、httpupgrade、mkcp 均标为不支持 |
| 目标站要求 | README：目标站需支持 TLS 1.3 与 H2 | 这是服务端选目标时的约束，H2 即 HTTP/2 |
| 未认证流量 | 会原样转发到 target | Xray 文档警告：若 target 在 Cloudflare 等 CDN 之后，服务器可能被当作端口转发而遭滥用 |
| 后量子能力 | 可选 mldsa65（ML-DSA-65）签名；目标站支持 X25519MLKEM768 时，客户端自动用它协商密钥 | 属于可选项，不是每个节点都会启用 |
传输方式各自是什么，放在 传输方式有哪些 里统一讲，兼容表本身见 Xray 文档：传输配置与兼容表。
这里要把话说清楚：官方资料列出了这么多条件和警告，说明 Reality 协议是一种有前提的方案，不是万能选项。梯子岛不会把它写成某个维度上的“最优”，因为这种判断需要大量的实际测试，而我们没有这类数据。
客户端要满足什么条件，才能连 Reality 节点
“客户端支持 Reality 协议”要拆成两层：内核有没有实现，界面有没有开放。先看内核：
| 内核 | 文档里的相关内容 |
|---|---|
| Xray-core | Xray 文档把 REALITY 作为传输安全方式之一，客户端实现见 reality.go |
| sing-box | TLS 配置页含 Reality Fields，如 handshake、private_key、public_key、short_id |
| Mihomo | vless、vmess、trojan 配置页含 reality-opts |
满足内核条件之后，还需要核对下面这些：
- 客户端所用内核在上表中。想看某个内核背后的客户端有哪些，读 Xray-core 档案 和 协议支持矩阵。
- 客户端界面能填写，或能完整导入公钥、shortId、fingerprint 等 Reality 字段。
- 节点的传输方式是 raw、xhttp、grpc 之一。
- flow 与节点说明一致，Vision 的使用条件见 VLESS 协议。
- 节点链接里的字段在转换成别的配置格式时没有丢失，转 Clash 配置时的常见漏项见 vless 转 Clash。
还没选好客户端的话，可以用 客户端选择工具 先按平台缩小范围。官方仓库和下载入口集中在 GitHub 仓库导航。
导入 Reality 节点后，怎么自己确认配置没漏
- 打开节点详情，确认协议是 VLESS，传输安全显示为 reality，而不是 tls。
- 确认公钥、shortId 有值且没有多余的空格或换行，fingerprint 也有值，README 说默认是 chrome。
- 确认传输方式属于 raw、xhttp、grpc。
- 对照节点提供方给的说明，核对 flow 是否一致。
- 其中任何一项对不上，先重新导入一次，不要手动东拼西凑。
- 连上之后，用 IP 与 DNS 检测 看出口和 DNS 走向。梯子岛只教方法，不提供检测结果。
- 仍然不通，按 梯子连不上怎么办 的顺序往下查，证书和时间类报错先看 证书错误与系统时间不对怎么办。
下一步该去哪
- 想先把 VLESS 本身弄懂：读 VLESS 协议是什么。
- 想了解 Reality 常用的 Xray 内核：读 Xray-core 是什么。
- 想弄清 ws、gRPC、XHTTP 这些传输方式：读 传输方式有哪些。
- 想确认某款客户端能不能处理 Reality：查 协议支持矩阵。
读完这篇，你应该能做到一件事：看到“VLESS + Reality”这几个字，知道它分成哪两层，每层要核对什么。
这篇没有覆盖的
- 本文不提供任何测速或解锁测试结果，也不评价 REALITY 在任何网络环境下的实际表现。
- 本文只讲客户端一侧的认识，不涉及服务端搭建，服务端字段只做名称层面的说明。
- 文档会更新，具体字段名与支持范围以 Xray、sing-box、Mihomo 的当前官方文档为准。
本文引用的官方来源
- Xray 文档：REALITY（xtls.github.io）
- REALITY（github.com）
- Xray 文档：传输配置与兼容表（xtls.github.io）
- sing-box 文档：TLS（含 Reality Fields）（sing-box.sagernet.org）
- Mihomo 文档：VLESS（wiki.metacubex.one）
- RFC 8446：TLS 1.3（www.rfc-editor.org）
以上链接均为官方页面，梯子岛在 2026-10-09 核对过；个别网站会拦截自动化访问，用浏览器直接打开即可。平台规则可能随时调整，以官方页面当前内容为准。
Reality 协议常见问题
Reality 是什么？
这里指的是 Project X 体系里的 REALITY 传输安全方案，不是某个同名软件。它是改造过的 TLS：服务端借用某个真实目标网站的握手外观，校验通过的连接进入代理，没通过的连接被转发到目标网站。常与 VLESS 加 XTLS Vision 流控搭配使用。
VLESS + Reality 是什么意思？
它指节点的协议是 VLESS，传输安全用的是 REALITY，通常还会配 xtls-rprx-vision 流控，所以也写作 VLESS+REALITY 或 VLESS-XTLS-uTLS-REALITY。两者分属不同层，VLESS 负责认证与转发，REALITY 负责外层的传输安全。
Reality 节点可以搭配 WebSocket 吗？
按 Xray 文档，REALITY 只能与 raw、xhttp、grpc 三种传输搭配，兼容表里 websocket、httpupgrade、mkcp 都标为不支持。如果你的节点写着 ws 之类的传输却又要求 Reality，说明配置有问题或资料已过期，应向节点提供方确认。
Reality 能不能当作万能选择？
不能这样看。官方资料自己就列出了限制：只能搭配三种传输，目标站需支持 TLS 1.3 与 H2，未通过认证的流量会原样转发到目标站，并提醒目标若在 CDN 之后可能带来滥用风险。适不适合你，取决于客户端和节点，梯子岛没有测速数据可以替你判断。
客户端要满足什么条件才能连 Reality 节点？
内核要支持 REALITY，Xray-core、sing-box 与 Mihomo 的文档里都有相关字段；客户端界面还要能填公钥、shortId 和 fingerprint 这类参数，或者能完整导入这些字段；节点的传输方式也必须是 raw、xhttp、grpc 之一。具体以客户端档案页为准。
接着读
- 协议 · VLESS 协议是什么？VLESS 节点与 Xray 的关系
- 对比 · VLESS 与 VMess 的区别：该用哪个协议
- 教程 · vless 转 Clash：Reality 节点转配置时容易漏的字段
- 客户端 · Xray-core 是什么？Xray 内核与 V2Ray 的关系
- 术语 · XTLS Vision是什么意思
- 术语 · TLS是什么意思
- 术语 · SNI是什么意思