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

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

Xray 项目前后拿出两样东西，各对付一个。2022 年 10 月 29 日的 v1.6.2 带来 XTLS Vision，管里面那层。2023 年 3 月 9 日的 v1.8.0 带来 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 本身的来历另有一篇。

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、FlClash 这类 mihomo 内核客户端的人，碰到的症状会是 REALITY 节点忽然全部握手失败，同一份订阅里别的协议照常。遇到这种情况，把现象和自己的客户端版本告诉机场客服，让他们去查服务端。自己这边能做的是先换用订阅里其他协议的节点，或者临时改用 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 三种内核都支持这一套，iPhone 上的 Stash 和 Loon 在文档里写明支持，Surge 的手册里没有 VLESS。几种协议放在一起怎么选，见机场常见协议总览。