新研究展示一种探测 XTLS VLESS REALITY 的手段
XTLS VLESS REALITY 是一种网络代理协议，由开发者 RPRX 设计并实现，运行在 Xray 软件之上。它的核心目标是：让代理服务器看起来和一个正常的网站服务器毫无区别，从而规避网络审查工具的检测与封锁。
为了实现这一目标，VLESS REALITY 采用了两项关键技术：
关键问题：一台服务器，两个 TLS Stack
然而，上述设计引入了一个结构性隐患：
利用该阈值差异，探测流程如下：
结合 VLESS REALITY 的回落机制，探测工具可以在同一端口上执行两次探测：
为何难以修复？
最直觉的修复方案是将 XTLS REALITY 的 maxUselessRecords 改为 32。但这引发了一个新问题——Caddy 困境：
许多用户将 VLESS REALITY 寄生在自建的 Caddy Web Server 上。Caddy 同样使用 Go 编写，其 TLS Stack 同样是 Go 的 crypto/tls，阈值同样为 16。此时若 REALITY 将自身阈值改为 32，反而制造了新的差异。
本文所解读的探测方法证明了一个简洁而深刻的事实：
正在使用 XTLS VLESS REALITY 的用户应当意识到：
参考：杀死那只鹦鹉 —— 「白话文」讲解一种探测 XTLS VLESS REALITY 的手段
XTLS VLESS REALITY 是一种网络代理协议，由开发者 RPRX 设计并实现，运行在 Xray 软件之上。它的核心目标是：让代理服务器看起来和一个正常的网站服务器毫无区别，从而规避网络审查工具的检测与封锁。
为了实现这一目标，VLESS REALITY 采用了两项关键技术：
回落（Fallback）机制：当 Xray 服务端判断入站连接并非来自合法的 VLESS 客户端时，它不会拒绝连接或返回错误，而是将流量原封不动地转发给一个预先配置的「源网站」。对外部观察者而言，这台服务器的行为与真实的网站服务器别无二致。
TLS 握手寄生：VLESS REALITY 不自行完成 TLS 握手，而是将握手过程交给「源网站」的服务器来执行（即所谓「偷别人的 TLS 握手」），以此获得与真实网站完全一致的 TLS 握手特征。
关键问题：一台服务器，两个 TLS Stack
然而，上述设计引入了一个结构性隐患：
同一台服务器、同一个端口上，实际存在两个不同的 TLS Stack——Xray 自身基于 Go crypto/tls 的 TLS Stack 和源网站的 TLS Stack。
当合法 VLESS 客户端连接时，Xray 会用自己的 TLS Stack 处理后续通信；当非 VLESS 流量触发回落时，源网站的 TLS Stack 负责处理。
只要这两个 TLS Stack 的行为存在任何可被观测的差异，整个伪装体系就会暴露。
然而，几乎所有主流 Web 服务器使用的 TLS Stack 阈值为 32，而 Go 标准库的阈值为 16。
XTLS VLESS REALITY 的实现代码直接复制自 Go 的 crypto/tls 标准库。在这次复制过程中，开发者 RPRX 原封不动地保留了 maxUselessRecords = 16 的默认值。
这一行为的讽刺之处在于：RPRX 自己曾经在 uTLS 库中指出过完全相同的指纹风险，并亲自提交 Pull Request 将 uTLS 的 maxUselessRecords 从 16 修改为 32（refraction-networking/utls PR #171）。也就是说，他清楚地知道这一差异可能成为指纹识别的依据，却在实现自己的核心协议时犯下了完全相同的错误。
原文作者将这种行为定义为以一种近乎圣徒般的虔诚、机械地复制代码，而不理解其中每一个参数的安全含义。
利用该阈值差异，探测流程如下：
向目标服务器发起 TLS 握手，并在握手过程中持续插入 ChangeCipherSpec 记录
记录目标服务器在接收到第几个 ChangeCipherSpec 记录后终止握手
若在第 17 个记录时终止（阈值 16+1）→ 目标服务器使用 Go crypto/tls 或 XTLS REALITY
若在第 33 个记录时终止（阈值 32+1）→ 目标服务器使用 OpenSSL/BoringSSL
结合 VLESS REALITY 的回落机制，探测工具可以在同一端口上执行两次探测：
第一次：重放合法 VLESS REALITY 的 Client Hello → Xray 自身处理 → 观察到阈值 16
第二次：发送篡改后的 Client Hello → 触发回落 → 源网站处理 → 观察到阈值 32
为何难以修复？
最直觉的修复方案是将 XTLS REALITY 的 maxUselessRecords 改为 32。但这引发了一个新问题——Caddy 困境：
许多用户将 VLESS REALITY 寄生在自建的 Caddy Web Server 上。Caddy 同样使用 Go 编写，其 TLS Stack 同样是 Go 的 crypto/tls，阈值同样为 16。此时若 REALITY 将自身阈值改为 32，反而制造了新的差异。
本文所解读的探测方法证明了一个简洁而深刻的事实：
协议的安全性上限，取决于实现者对底层协议栈行为细节的认知深度。
XTLS VLESS REALITY 的伪装并非在密码学层面被攻破，而是因为开发者在搬运 Go 标准库代码时忽略了一个常量值的含义。这种「货物崇拜式」的工程实践，使得一个宣称能「解决 TLS 安全性问题」的协议，暴露于一种朴素到甚至平庸的探测手段之下。
正在使用 XTLS VLESS REALITY 的用户应当意识到：
该协议并非无懈可击，已存在可行的主动探测手段
探测方法实现简单，不需要大量算力，具备大规模部署的可行性
结合被动识别手段（SNI/IP 不匹配、流量聚合异常），探测效率可以进一步提升
在 Xray 的实现代码中，类似的行为差异可能还有更多尚未被公开
参考：杀死那只鹦鹉 —— 「白话文」讲解一种探测 XTLS VLESS REALITY 的手段
