节点列表里经常见到「香港 01 VLESS Reality Vision」这种名字。三个词是三样东西，各管一层。VLESS 是协议本身，REALITY 是外面那层传输安全，Vision 是 VLESS 自带的流控模式。机场把它们写进节点名，是因为这三样在订阅里对应三组不同的参数。
一条这样的节点在 Clash 订阅里长这样。
proxies:
- name: "香港 01 VLESS Reality Vision"
type: vless
server: hk01.example.com
port: 443
uuid: 00000000-0000-4000-8000-000000000000
flow: xtls-rprx-vision
tls: true
servername: www.example-target.com
client-fingerprint: chrome
reality-opts:
public-key: "PUBLIC-KEY-FROM-YOUR-PROVIDER"
short-id: "a1b2c3d4"
udp: trueservername 填的不是你的节点域名
普通 TLS 节点的 servername 和 server 通常一致，都是机场自己的域名。REALITY 节点这一栏填的是别人的网站。
REALITY 仓库对这套做法的描述是，可以指向别人的网站，无需自己买域名、配置 TLS 服务端。服务端配置里有一项 target，指向那个被借用的真网站，另有一组 serverNames 列出客户端可以报哪些域名。客户端连过来的时候报的就是其中之一，握手看上去像在访问那个网站。
验证不过关的连接会被转给真网站。这一点和 Trojan 的回落是同一种思路，区别在于 REALITY 转过去之后，探测者拿到的是那家网站货真价实的证书，而不是机场自己签的一张。
所以机场不需要域名和证书，这是 REALITY 最实际的好处。REALITY 的仓库建于 2023 年 1 月 29 日，许可证是 MPL-2.0 加 BSD-3-Clause，同年 3 月 9 日的 Xray v1.8.0 把它正式带了出来，那一版的关键词写的就是无需买域名、消除服务端 TLS 指纹、可指定 SNI。
public-key 和 short-id 是怎么配上的
服务端那边用 xray x25519 生成一对密钥，私钥写进服务端配置的 privateKey，对应的公钥发给客户端。另有一组 shortIds，Xray 文档说它可以用于区分不同的客户端，客户端拿其中一个填进自己的 shortId。
shortId 的格式有讲究，必须是偶数长度的十六进制字符串，最多 16 个字符，不足的部分由核心自动补零。所以订阅里看到 a1b2c3d4 这种短串是正常的，不用怀疑机场偷懒。
服务端还有一项 maxTimeDiff，允许的最大时间差，单位毫秒。默认不启用，机场开了的话，设备时钟走偏也会影响 REALITY 节点，这一点和 VMess 对时间的要求有点像，只是触发条件少见得多。
Xray 那边还有一栏 spiderX，文档的说明是爬虫初始路径与参数，建议每个客户端不同。Mihomo 和 sing-box 的节点配置里没有对应项。
client-fingerprint 和 fingerprint 是两栏不同的东西
这两个名字挨得太近，很容易看混。
client-fingerprint 是客户端 utls 指纹，让你的 TLS 握手包长得像某个浏览器发出来的。Mihomo 文档列的可选值有 chrome、firefox、safari、ios、android、edge、360、qq 和 random，其中 random 按 Cloudflare Radar 的数据按概率生成一个现代浏览器指纹。这一栏适用于 VMess、VLESS、Trojan 和 AnyTLS 四种协议。
fingerprint 指的是服务器证书的 SHA256 指纹，用途是证书锁定，填了之后客户端只认这一张证书。Mihomo 文档给的获取办法是用 openssl 命令读证书，或者在 Chrome 的证书查看器里抄。
sing-box 把前者放在 tls.utls 里，字段是 enabled 和 fingerprint，留空时默认按 chrome 处理，可选值和 Mihomo 那份基本重合。
flow 那一行开的是 Vision
XTLS Vision 是 2022 年 10 月 29 日的 Xray v1.6.2 首次放出来的，当时它还叫新流控实验选项。发布说明里有一句写得很直白，讲的是 XTLS Vision 针对的就是 TLS in TLS 这件事。它的做法是在内层握手阶段做长度填充，让代理流量里那次嵌套握手不那么好认。
那一版的说明还写了几条限制。两端都要开同样的流控设置，测试期间只支持 VLESS 不支持 Trojan，XTLS 不支持 Mux，UDP 的 Full Cone 行为不受影响。到 2023 年 3 月的 v1.8.0，旧的 XTLS Origin、Direct、Splice 三种流控被移除，xtls-rprx-vision 成了唯一的选项。
Xray 现在列的取值有两个。xtls-rprx-vision 会拦截目标为 443 端口的 UDP 流量，xtls-rprx-vision-udp443 除了不拦这部分之外与前者相同。sing-box 只认前一个。
顺带提一句，AnyTLS 也是冲着 TLS 套 TLS 去的，思路不同，它在会话层上做分包和填充，而不是改流控。
同一组参数，两家内核放在不同层级
Mihomo 把 REALITY 相关的东西挂在节点下面的 reality-opts 里，sing-box 收进 tls 对象。同一条节点的 JSON 写法是这样。
{
"type": "vless",
"tag": "hk01-reality",
"server": "hk01.example.com",
"server_port": 443,
"uuid": "00000000-0000-4000-8000-000000000000",
"flow": "xtls-rprx-vision",
"tls": {
"enabled": true,
"server_name": "www.example-target.com",
"utls": { "enabled": true, "fingerprint": "chrome" },
"reality": {
"enabled": true,
"public_key": "PUBLIC-KEY-FROM-YOUR-PROVIDER",
"short_id": "a1b2c3d4"
}
}
}Mihomo 那边还多一项 reality-opts.support-x25519mlkem768，用来声明支持 X25519-MLKEM768 密钥交换。这些都由机场写好，手动改的机会不多，认得出来就够用了。
2026 年 7 月起有一个兼容性坑
Xray 在 2026 年 7 月 11 日的 v26.7.11 里做了一处改动，把 REALITY 服务端的默认 minClientVer 设成 26.3.27，提交说明里还加了一句自行承担风险。这一版在 GitHub 上标为预发布，Xray 最近一个正式版仍是 2026 年 3 月 27 日的 v26.3.27。
Mihomo 的回应写在文档里。它的 reality-opts 一节挂着一条警告，说由于 xray-core 刻意的不兼容行为，不会考虑 xray v26.7.11 及以上版本的兼容性，连不上的话请更换服务端，或者改用其他协议。
对用户的意思是，机场如果把服务端升到那几版，用 Clash Verge Rev 这类 Mihomo 系客户端的人可能会发现 REALITY 节点突然握不上手，而 v2rayN 这种自带 Xray 内核的客户端没事。碰到这种情况先别怀疑自己，把现象告诉机场客服，顺便试试同一订阅里别的协议。
本站收录的 28 家机场里，资料写明用 VLESS 的有 6 家，是自述中最常见的协议，但没有一家把 REALITY 单独写出来。数据来自机场自述与站长资料，核对日 2026-08-09。想知道自己那条订阅有没有 REALITY，翻配置文件搜 reality-opts 这个词最快，六种协议的分辨办法在按字段认协议里。