# REALITY 与 XTLS Vision 分别解决了什么问题

> 来源 https://jichangtuijianweb.co/kepu/vless-reality-vision/，更新于 2026 年 9 月 20 日。机场推荐网（https://jichangtuijianweb.co/）原创内容。
> 分类 协议与内核。

REALITY 换掉外层的 TLS，让服务器借用真实网站的握手外观，机场不必自备域名和证书。XTLS Vision 是 VLESS 的流控，负责填充内层 TLS 握手的短包。

拿 TLS 当外壳的代理，[Trojan](https://jichangtuijianweb.co/kepu/trojan-xieyi/) 也好，VLESS 加 TLS 也好，一直带着两个麻烦。一个在服务器这头，机场得备好域名和证书，服务器程序的 TLS 实现还有自己的指纹。另一个藏在连接里面，你要访问的网站自己也用 TLS，两层套在一起，头几个包的长短很有规律。

Xray 项目前后拿出两样东西，各对付一个。2022 年 10 月 29 日的 v1.6.2 带来 XTLS Vision，管里面那层。2023 年 3 月 9 日的 v1.8.0 带来 [REALITY](https://jichangtuijianweb.co/cidian/#reality)，管外面那层。节点名里写着 VLESS Reality Vision 的，就是三样叠在一起用。

## 头五个包的长短，让人看出里面还套着一层 TLS

Xray 的维护者 yuhan6665 在 2022 年 10 月 31 日发过一篇讨论帖，标题里就带着 XTLS Vision，把这件事讲得很具体。通过一个 TLS 代理去打开 HTTPS 网站，连接最开头的五个包是这样的。

```
第一个包  客户端 → 代理服务器   目标地址和 UUID          很短
第二个包  客户端 ← 代理服务器   收到请求，可以发数据      很短，长度几乎固定
第三个包  浏览器 → 目标网站     TLS Client Hello        短，变化很少
第四个包  浏览器 ← 目标网站     TLS Server Hello        长，变化较大
第五个包  浏览器 → 目标网站     握手完成，开始加密通话    很短
```

外层 TLS 遮得住内容，遮不住每个包有多长、谁先谁后。这五个包的长短组合太固定，审查的一方靠统计就能认出来。

Vision 的办法分两步。握手阶段，它把每一个短包都填充到 900 到 1400 字节这个区间，长短规律就散了。握手结束以后，里层如果是 TLS 1.3，传的本来就是密文，帖子的说法是 XTLS 不再对数据包做任何操作，只是单纯拷贝，第二遍加密省掉了。Xray 文档的传输方式一页因此写了一句很满的话，启用 REALITY 并配上合适的 Vision 流控，性能可以提升数倍甚至十几倍。这是 Xray 自己的说法，本站没有做过对照测试。

填充的算法后来又改过。v1.8.0 的发布说明提到，在原有的长填充之外加了 0 到 256 字节的可变填充，不是 TLS 的流量也开始填充，更早的几种 XTLS 流控在这一版被移除。

落到订阅里，Vision 就是 VLESS 节点上的一行 `flow`。Xray 文档列了两个取值，`xtls-rprx-vision` 会拦下发往 443 端口的 UDP，也就是 QUIC，`xtls-rprx-vision-udp443` 不拦，别的都一样。mihomo 和 sing-box 的文档只列了前一个。v1.6.2 的说明还有两条限制，测试阶段只支持 VLESS，XTLS 暂不支持 Mux。[VLESS 本身的来历](https://jichangtuijianweb.co/kepu/vmess-vless-qubie/)另有一篇。

## REALITY 借的是别人网站的握手

Xray 文档给 REALITY 下的定义是一句话，对 TLS 的一种修改，通过借用目标站点的 TLS 外观与握手特征来完成伪装。REALITY 在 GitHub 上单独有一个仓库，创建时间是 2023 年 1 月 29 日，README 写的许可证是 MPL-2.0 和 BSD-3-Clause 双许可。README 开头列了它想做到的事，换掉 TLS 以后服务端的 TLS 指纹特征没有了，前向保密还在，证书链攻击无效。后面紧跟着机场最在意的一条，伪装对象可以是别人的网站，域名不用买，TLS 服务端也不用自己配。

机场那头的配置里有一项 `target`，填的是被借用的那个真网站，比如某个大站的 443 端口。另一项 `serverNames` 列出客户端可以报的域名，文档说一般和目标网站证书上的域名一致。密钥用 `xray x25519` 命令生成，私钥留在服务端，对应的那一半发给客户端。

订阅里 REALITY 节点的 `servername` 一栏写着别人家的域名，原因就在这里。客户端连的还是机场服务器的 IP，只是在握手时报出那个域名。

握手的时候，客户端靠证书分辨对面是谁。README 的描述是，REALITY 客户端正常应该收到一张由临时认证密钥签发的临时可信证书，收到它，连接可用。如果收到的是目标网站的真证书，说明服务端拒绝了这次握手，或者连接半路被人重定向去了目标网站，也可能正遭遇中间人攻击，客户端这时转入爬虫模式，装成一个普通访客。收到无效证书就直接断开。

换到探测者的位置，拿不出正确密钥的握手会被服务器直接转发给目标网站。Xray 文档的原话是对于鉴权失败的流量会直接转发至 target。探测者从头到尾是在和那家真网站握手，拿到的证书、看到的网页都来自那家网站，机场的服务器只在中间搬运。Trojan 服务器遇到探测，亮出来的是机场自己域名的证书，这是两者差得最远的地方。

借谁的网站由机场定。README 给的最低标准是国外网站、支持 TLSv1.3 与 H2、域名非跳转用，加分项有 IP 相近、带 OCSP Stapling 等几条。文档也提醒了副作用，直接转发意味着服务器可能被人扫到以后拿去偷跑流量。为此 Xray 加过回落限速的选项，文档自己又补了一句，回落限速是一种特征，不建议启用。

## 同一样东西，三家内核的字段名各不相同

这些参数都由机场写进订阅，用户认得出来就够了。

| 含义 | Xray | mihomo | sing-box |
|---|---|---|---|
| 握手时报出的域名 | `serverName` | `servername` | `tls.server_name` |
| 服务端密钥对应的那一半 | `password` | `reality-opts.public-key` | `tls.reality.public_key` |
| 短 ID | `shortId` | `reality-opts.short-id` | `tls.reality.short_id` |
| 模仿哪种浏览器的指纹 | `fingerprint` | `client-fingerprint` | `tls.utls.fingerprint` |
| Vision 流控 | `flow` | `flow` | `flow` |

第二行最容易让人糊涂。Xray 文档说 `password` 旧称 publicKey，为防止误解才改的名，它在数学上确实是 x25519 公钥，可在 REALITY 的设计里由客户端持有，不能公开。mihomo 和 sing-box 沿用了公钥的叫法。三个名字指的是同一串字符，对用户来说它和密码一样不能外传。

短 ID 的格式，Xray 文档写的是 8 个字节，也就是 16 个十六进制字符，可以写短一些，位数必须是偶数，内核在后面自动补 0。服务端可以配一组短 ID，文档说可用于区分不同的客户端。

指纹那一行在 REALITY 节点上是必填的。Xray 文档解释过，REALITY 的实现要靠 uTLS 这个库去操作底层的 TLS 参数，所以这里不允许关掉 uTLS。sing-box 的文档对 uTLS 却很不客气，说研究者多次发现它的指纹漏洞，库本身缺乏维护，真想抵抗 TLS 指纹识别的话建议改用 NaiveProxy。两份官方文档对同一个库的评价差这么多，用的人心里有数就好。

## 2026 年 7 月以后，mihomo 声明不再兼容新版 Xray 服务端

这一段和正在用 REALITY 节点的人直接有关。2026 年 7 月 11 日，Xray 有一次提交改了 REALITY 服务端的一个默认值，`minClientVer` 从此默认是 `26.3.27`，提交标题的括号里写着改动它后果自负。这个选项的含义是客户端 Xray 的最低版本。当天发布的 v26.7.11 带着预发布标记，到我核对时，GitHub 上最新的正式版还是 2026 年 3 月 27 日的 v26.3.27。

mihomo 的回应写进了文档。`reality-opts` 一节现在挂着一条说明，称由于 xray-core 刻意的不兼容行为，不会考虑 xray v26.7.11 以上版本的兼容性，用不了就请更换服务端，可选 mihomo 原生 listener、sing-box 或旧版 xray-core，要么改用其他协议。

机场如果把服务端升到这些版本又没改默认值，用 [Clash Verge Rev](https://jichangtuijianweb.co/kehuduan/clash-verge-rev/)、FlClash 这类 mihomo 内核客户端的人，碰到的症状会是 REALITY 节点忽然全部握手失败，同一份订阅里别的协议照常。遇到这种情况，把现象和自己的客户端版本告诉机场客服，让他们去查服务端。自己这边能做的是先换用订阅里其他协议的节点，或者临时改用 [v2rayN](https://jichangtuijianweb.co/kehuduan/v2rayn/) 这种可以跑 Xray 内核的客户端，内核版本不要低于 v26.3.27。

## 本站 28 家机场里，没有一家把 REALITY 写进介绍

本站收录的 28 家机场，协议一栏有记录的 8 家里，写 VLESS 的有 6 家。REALITY 和 Vision 这两个词，28 家的资料里一处也没有出现，核对时间多数是 2026 年 8 月 8 日和 9 日。机场用没用，要看订阅。Clash 格式的配置里，节点带着 `reality-opts` 就是 REALITY，带着 `flow` 就是开了 Vision。

客户端方面，Xray、mihomo、sing-box 三种[内核](https://jichangtuijianweb.co/kepu/daili-neihe-shi-shenme/)都支持这一套，iPhone 上的 [Stash](https://jichangtuijianweb.co/kehuduan/stash/) 和 Loon 在文档里写明支持，Surge 的手册里没有 VLESS。几种协议放在一起怎么选，见[机场常见协议总览](https://jichangtuijianweb.co/kepu/daili-xieyi-zonglan/)。

## 常见问题

### REALITY 节点的 servername 写着别家大网站，我的流量会经过那家网站吗

不会。客户端连的仍是机场服务器的地址，只是握手时报出那个域名。按 Xray 文档，只有鉴权失败的连接才会被服务器直接转发到目标网站，那是给探测者看的。通过验证的连接由机场服务器照常代理，和目标网站没有关系。

### Vision 能用在 Trojan 或 VMess 节点上吗

按现有文档不能。Xray v1.6.2 的发布说明写明测试阶段只支持 VLESS，暂不支持 Trojan。mihomo 和 sing-box 的文档里，flow 这个字段也只出现在 VLESS 节点上，可填的值只有 xtls-rprx-vision 一个。

### REALITY 节点对设备时间有要求吗

默认情况下文档没有提这类要求。REALITY 服务端有一个选填项 maxTimeDiff，含义是服务端能容忍的时间差上限，以毫秒计，机场开了它，设备时钟偏得太多就可能握手失败。这一项写在服务端，订阅里看不到，REALITY 节点整组连不上时可以顺手校一下时间。

### iPhone 上哪些客户端能用 VLESS REALITY Vision 节点

Stash 和 Loon 的文档都写了支持。Stash 的 VLESS 一节列出了 xtls-rprx-vision 流控和 REALITY 模式，Loon 的节点示例带着 flow、public-key 和 short-id 三个参数。Surge 手册的协议目录里没有 VLESS。

### 用了 REALITY 和 Vision 是不是就不会被封

不能这么说。REALITY 处理的是证书和服务端 TLS 指纹，Vision 处理的是内层握手的包长特征，两份文档都没有承诺不被封。Vision 的讨论帖还特意建议大家分散使用各种工具的特性。本站没有封锁方面的测试数据，给不出结论。

## 参考来源

- [XTLS/REALITY 仓库 README](https://github.com/XTLS/REALITY)
- [GitHub API，XTLS/REALITY 仓库信息](https://api.github.com/repos/XTLS/REALITY)
- [Xray 文档，REALITY 传输安全](https://xtls.github.io/config/transports/reality.html)
- [Xray 文档，传输方式总览](https://xtls.github.io/config/transport.html)
- [Xray 出站文档里的 VLESS 一页](https://xtls.github.io/config/outbounds/vless.html)
- [Xray-core 讨论帖 1295，XTLS Vision（2022-10-31）](https://github.com/XTLS/Xray-core/discussions/1295)
- [Xray-core v1.6.2 发布说明（2022-10-29）](https://github.com/XTLS/Xray-core/releases/tag/v1.6.2)
- [Xray-core v1.8.0 发布说明（2023-03-09）](https://github.com/XTLS/Xray-core/releases/tag/v1.8.0)
- [Xray-core 提交 af7eb68，REALITY 服务端默认 minClientVer（2026-07-11）](https://github.com/XTLS/Xray-core/commit/af7eb68028732a8ee3c0e5d6ab2b8a657bb2e770)
- [GitHub API，Xray-core v26.7.11 与最新正式版的发布信息](https://api.github.com/repos/XTLS/Xray-core/releases/latest)
- [mihomo 文档，TLS 通用字段与 reality-opts](https://wiki.metacubex.one/config/proxies/tls/)
- [mihomo 文档，VLESS 节点](https://wiki.metacubex.one/config/proxies/vless/)
- [sing-box 文档，TLS 共享字段](https://sing-box.sagernet.org/configuration/shared/tls/)
- [sing-box 文档，VLESS 出站](https://sing-box.sagernet.org/configuration/outbound/vless/)
- [Stash 文档，支持的代理协议](https://stash.wiki/proxy-protocols/proxy-types)
- [Loon 文档，节点格式](https://nsloon.app/docs/Node/)
- [Surge 手册目录](https://manual.nssurge.com/)