最近偶然发现 Xray 又出了新玩意儿：REALITY。

说实话，我目前使用的架构还是 20 年那一套，基于 Docker + Watchtower 实现全自动更新，已经使用 2 年没变了，一直没啥问题，只是 4 月上去支持了下 WARP 用于访问 ChatGPT。

上次关注 Xray 的消息都还是 21 年吃分叉瓜的时候了。于是乎我跑去 Xray 项目上了解下最新的进展，可惜官网介绍不多，只能从各种 issues 中找到一些蛛丝马迹。

评估了下迁移成本后，我从 V2Ray 迁移到了 Xray，整体的架构没变，还是 Nginx 分流那套，只是网络工具变了，顺带加了一些新的协议（VLESS、Vision、gRPC）

Xray 是什么？与 V2Ray 有什么关系？

本是同根生，起源于同一个项目，后面分叉迭代了。

REALITY、Vision 诞生的原因是什么？

以 Trojan 为代表的 TLS 通信工具，存在 TLS in TLS 问题，「加密套娃」使得它可能具有某些统计学特征。

RPRX 因此还专门起了 Trojan-killer 项目，源码大家自己解读，我看了下整体的思路就是验证「加密套娃」。

XTLS、Vision、REALITY 是什么？工作原理是什么？

XTLS 是早期解决 TLS in TLS 的思路，实现上需要修改 TLS/uTLS 官方库，所以在可维护性上不被看好，但是思路验证是没问题的。

Vision 算是 XTLS 的稳定版，也是为了解决 TLS in TLS 问题，现在称它为流控，使用 xtls-rprx-vision 标识。

REALITY 是为了进一步消除服务端 TLS 指纹特征，解决 SNI 封锁等问题，工作原理分布在各个 issues 里面，结合项目代码我简单分析了下 REALITY 的工作原理。

整体上是依靠伪装来骗过检查者，找正规大网站借用握手包特征来伪装，然后里面加一些自己的鉴权东西，大体流程是：

1. Server 端请求 Apple、Bing 等正常网站获取 TLS 握手期间的 Server Hello 包

2. 拿着这个正常的握手包和 Client 交互，当然里面填充了一些 Xray 自己构造的校验内容

3. 因为包内容被修改，所以 Client 正常无法直接处理这个 Hello 包的，需要做一些校验处理，通过后才能继续通信

整个过程单从特征上来看，都像是在和 Apple、Bing 等大网站在交互，也无法通过证书链等方式攻击，因为只是批了大网站的皮，内核其实是自己校验算法。

总的来说 REALITY 的设计思路确实比较清奇！

REALITY 可能的缺点是什么？

首先是配套工具的支持，任何东西要易用、易上手才能推广开，目前支持的工具还较少。

其次是协议的打磨，目前看思路说得通，但伪装行为本身是否会带来新的特征，这个无法证伪，还需要通过时间再验证。

然后是性能，交互上多了一次 Server 端去 Apple 等网站拿握手包的过程，本身就是一次网络开销，这块还可以优化（最近的消息说是准备加缓存）。

最后是有个 issues 提到的 DNS 问题，本质上是流量分布问题。虽然交互伪装成了大网站的流量，但是 IP 是大家都能看到的，所以从统计上能看到：某个 IP 突然有了不少 Apple、Bing 等域名流量 😂，这本身是否也是一种特征？这个同样无法证伪，还需要通过时间再验证。

毕竟是个新鲜事务，我觉得可以再持续观察下，总是需要创新才能带来新的可能性 👏。

我的选择

整体的选择标准还是：安全性 > 稳定性 > 速度。

最后工具的选择是：

1. V2Ray => Xray

2. ClashX => Clash.Meta（Client 配置兼容）

协议的选择是：

1. VLESS+Vision+TLS（默认，本次新增）

2. Trojan+TCP+TLS（之前保留）

3. VLESS+gRPC+TLS（本次新增）

4. VMess+WebSocket+TLS+CDN（应急，之前保留）

说实话因为我不用机场，所以一直用 Trojan 都没出过问题，即使在各种敏感时期。

我觉得「网络邻居」带来的风险比各种工具协议本身的特征风险会更大一些 🙈。

这次切换主要是体验下新工具以及解决潜在风险：

1. TLS in TLS 特征：使用 Vision，也就是 xtls-rprx-vision

2. Client TLS 指纹：ClashX 不支持 Vision（VLESS)，因此迁移到了 Clash.Meta，自带了 client-fingerprint

3. Server TLS 特征：REALITY 暂时不用，后面如果要用，我当前架构的迁移成本也很低

对比我 20 年那一套方案，新的方案没有大的变化，还是基于 Nginx 的 SNI 分流架构，容器间的通信换成了 Unix Socket，充分利用了 Fallback 实现多协议共存。

Nginx 层统一管理收敛流量入口，整个主机只用开启 443/80 和 SSH 端口即可，同时各个模块都做了伪装，「非标请求」看到的都是正常的页面，而且 WS + CDN 限定了白名单访问。只有 Client 直接访问的服务才需要处理 TLS，内部统一是 h1/h2c cleartext 协议，尽量减少 TLS 开销。

跑个分 🏃！

速度测试结果出乎意料。VLESS+gRPC+TLS 最拉垮我是没想到的，Multi 和 Signle 模式下速度差不多，可能是链路复用的问题 🤔️。VLESS+Vision+TLS 和 Trojan+TCP+TLS 差别不大，意料之中吧，测速场景下看不出来优势

小结

个人结论依旧保持不变：目前基于 TLS 的协议才是未来的发展方向，「网络邻居」依旧是最大的风险。

虽然当前类 TLS 方案存在 TLS in TLS、Client 指纹、Server 特征等问题，但是很高兴看到目前有非常多人投身于此领域，并致力于解决这些问题。

在此过程中新的协议或者工具层出不穷，但是也请不要将自己的精力过多放在协议试验上，如果你现在用的协议没有受到干扰，那就没有必要去追求其他协议，保持关注即可。

我们的目标是自由访问互联网资源，自由获取你想要的内容，而不是传输工具本身。就像我们我们选择出发是为了感受旅程，而不是为了交通工具。