VLESS + Reality：无需域名的最强抗探测方案
上一章我们将传输层升级到了 XHTTP。本章介绍一种完全不同的方案——VLESS + Reality。它不需要域名和证书，抗探测能力最强，适合作为 XHTTP + CDN 方案的备用线路。
本章深入解析 VLESS + Reality 的技术原理，以及它为什么被认为是当前抗探测能力最强的方案。下一章将给出完整的实操部署步骤。
传统 TLS 方案的痛点
VLESS + TCP + TLS 的工作流程：
这要求你必须：
- 拥有一个域名——DNS 记录指向你的 VPS
- 获取 TLS 证书——Let's Encrypt 或 Cloudflare Origin Certificate
- 维护证书续期——Let's Encrypt 证书 90 天过期
更关键的问题是域名暴露：GFW 可以通过 SNI（Server Name Indication）看到你连接的域名。如果这个域名只有你在用（没有其他正常流量），它就成了一个明显的目标。
Reality 的核心思想
Reality 的设计理念极其精妙：借用别人的 TLS 证书。
传统方案中，你的服务器用自己的证书证明"我是 proxy.example.com"。Reality 则让你的服务器伪装成"我是 www.microsoft.com"——使用的是微软的真实证书。
GFW 看到的是：一个 IP 在与 microsoft.com 进行标准的 TLS 连接。这与全球数十亿正常的 HTTPS 请求毫无区别。
Reality 握手详解
Reality 的握手过程比传统 TLS 多了一层巧妙的机制：
第一阶段：伪装的 TLS 握手
第二阶段：密钥交换
第三阶段：正常代理
Reality 的认证不依赖 CA 证书体系，而是使用 curve25519 密钥对。服务端生成私钥和公钥，客户端配置公钥。这意味着即使 CA 被劫持，也不影响 Reality 的安全性。
主动探测如何被化解
GFW 最强的武器是主动探测——向可疑服务器发起连接，看响应是否正常。Reality 对此的防御堪称完美：
探测器看到的结果：这台服务器就是 microsoft.com 的一个节点，返回的证书、内容、行为全部正常。因为返回的确实是微软的真实数据。
对比传统方案的回落
| 方案 | 探测时的表现 | 可信度 |
|---|---|---|
| 传统 TLS + Nginx 回落 | 返回你自建的网站（可能是空白页或简单页面） | 中等——小网站被探测多次后可能引起怀疑 |
| Reality 回落 | 返回微软/苹果/谷歌等大站的真实内容 | 极高——你伪装的是世界上最常见的网站 |
Reality 的配置参数解析
一个典型的 Reality 服务端配置：
关键参数说明：
| 参数 | 含义 |
|---|---|
dest | 回落目标——非法请求转发到哪里 |
serverNames | 允许客户端使用的 SNI 列表 |
privateKey | 服务器私钥（X25519），配对的公钥给客户端 |
shortIds | 短 ID，额外的认证层（防止密钥泄露后被滥用） |
flow: xtls-rprx-vision | XTLS Vision 流控，下一节详细解释 |
这个示例省略了完整配置中的 sniffing 和 outbounds 部分。完整配置中还会包含：
sniffing（流量嗅探） 的作用是：Xray 从经过的流量中提取真实目标域名（HTTP 的 Host 头、TLS/QUIC 的 SNI），然后由服务端重新进行 DNS 解析。这解决了客户端 DNS 被污染的问题——即使客户端解析到了错误的 IP，服务端也能通过嗅探到的域名找到正确地址。
outbounds（出站规则） 定义了流量的出口：
freedom（自由）：正常转发到互联网——这就是代理的出口blackhole（黑洞）：直接丢弃流量——用于配合路由规则屏蔽广告或恶意域名
没有额外路由规则时，所有流量默认走第一个 outbound（即 freedom，正常上网）。
端口选择
示例配置中使用了 "port": 443，这是最理想的端口（正常 HTTPS 流量都走 443）。但如果你的 VPS 上 443 已被 Nginx 占用（比如同时运行着网站），可以使用其他端口（如 8443）：
使用非 443 端口时，Xray 会提示 REALITY: Listening on non-443 ports may get your IP blocked by the GFW。实际风险取决于你的网络环境——海外 VPS 被主动扫描非标端口的概率较低，但 443 仍然是最安全的选择。
如何选择伪装目标（dest）
伪装目标的选择直接影响安全性：
好的选择
www.microsoft.com— 全球流量巨大www.apple.com— 同上gateway.icloud.com— Apple 设备常连www.amazon.com— 电商巨头
选择标准
- 支持 TLS 1.3（必须）
- 支持 H2（推荐）
- 全球访问量大（你的流量混在其中不显眼）
- 不在 GFW 黑名单中（google.com 虽然大，但在中国被封）
坏的选择
- 已被墙的网站（google.com、youtube.com）
- 小众网站（流量太少，你的连接会很显眼）
- 你自己的其他域名（关联性太强）
伪装目标必须与你的 VPS 地理位置合理匹配。如果你的 VPS 在日本，却伪装成只部署在美国的服务，在物理延迟上就会穿帮。选择有全球 CDN 部署的大站最安全。
为什么需要 XTLS Vision 流控
配置中 client 有一个 flow 字段设为 xtls-rprx-vision。这不是随便填的——它解决了一个所有加密代理都面临的隐蔽性问题：TLS-in-TLS 检测。
前置知识：TLS 握手的"指纹"
TLS 握手不是随机的，它有非常固定的数据包大小模式：
这个大小序列（200, 100, 3000, 50, 随机...）就像一个指纹——审查者看到这种模式就知道"这是一次 TLS 握手"。正常情况下这没问题，全世界的 HTTPS 连接都是这个模式。
问题：代理场景下的嵌套暴露
没有代理时，审查者看到你和网站做 TLS 握手，完全正常。但有代理时：
时间线是这样的：
- 你和代理服务器建立外层 Reality 连接（这一步没问题）
- 连接建好后，浏览器要通过隧道访问 google.com
- 浏览器和 google.com 做 TLS 握手——这个握手数据被外层 Reality 加密后传输
关键来了——虽然外层已经加密了，但每个数据包的大小没变：
审查者虽然看不到内容（已加密），但能看到每个包的大小。他发现：
"这条连接刚建立后，传了一系列大小约 280、160、3050、100 字节的包，然后才开始随机大小的数据……这个模式和 TLS 握手一模一样！里面套了一层 TLS！这是代理！"
这就是 TLS-in-TLS 指纹攻击——不需要解密内容，只通过包大小的统计规律就能判断。
Vision 的解决方案
XTLS Vision 的思路：在内层握手阶段改变包的大小和时序，让审查者的统计模型失效。
Xray 能识别"当前传输的是内层 TLS 握手数据"（因为数据经过 Xray 时是明文的，它知道内容类型），识别后做两件事：
第一阶段：内层 TLS 握手期间
同时加入时序抖动——本来这几个包是连续快速发出的，Vision 在中间插入随机的微小延迟，打破握手特有的时间节奏。
结果：审查者看到的包大小序列变成随机数字，无法匹配 TLS 握手指纹。
第二阶段：握手完成，进入正常数据传输
内层 TLS 握手完成后，后续传输的都是加密后的应用数据（网页内容、视频流等）。这些数据本身大小就是随机的，不需要额外处理。Vision 在这个阶段直接透传，不做任何填充。
好处：不浪费 CPU、不浪费带宽。握手只有几个包（不到 1 秒），之后全是高效透传。
对比效果
| 无 Vision | 有 Vision | |
|---|---|---|
| 握手阶段包大小 | 280, 160, 3050, 100（规律明显） | 450, 280, 3500, 190（随机化） |
| 握手阶段时序 | 快速连续发送（TLS 特征） | 加入随机延迟 |
| 数据传输阶段 | 随机（本来就安全） | 直接透传（不浪费性能） |
| 审查者判断 | "包大小模式匹配 TLS 握手，是代理" | "看不出规律，放行" |
为什么 Reality 必须用 TCP
Vision 需要精确控制每个包的大小和发送时机。TCP 下，Xray 直接操控 socket，能决定"这个包发多大、什么时候发"。
如果用了 WebSocket 或 gRPC，数据会被这些协议重新分帧、合并、拆分——Xray 精心填充好的包大小会被打乱，Vision 的策略就完全失效了。
所以 Reality + Vision 的配置中 network 必须是 tcp，且不能开启 mux（多路复用）。这是协议层面的硬性约束，不是偏好选择。
Reality vs WebSocket + TLS + CDN
两者是当前最主流的方案，但适用场景完全不同：
| 对比维度 | VLESS + Reality | VLESS + XHTTP/WS + TLS + CDN |
|---|---|---|
| 需要域名 | ❌ 不需要 | ✅ 需要 |
| 需要证书 | ❌ 不需要 | ✅ 需要（或 CDN 自动管理） |
| 隐藏 VPS IP | ❌ IP 暴露 | ✅ IP 藏在 CDN 后面 |
| 抗主动探测 | 最强（回落到大站真实内容） | 强（回落到自己的网站） |
| 能过 CDN | ❌ 不能 | ✅ 可以（CDN 支持 WebSocket） |
| 性能 | 极佳（TCP 直连） | 较好（多一层 WebSocket 开销） |
| 部署复杂度 | 低（无需域名和证书） | 中等（需配置 DNS、证书、CDN） |
| IP 被封后 | 需要换 VPS | 换 CDN IP / 不受影响 |
选择逻辑
最稳妥的做法是两套方案都部署：XHTTP + CDN 作为主力（IP 隐藏），Reality 作为备用（性能优先，或 CDN 出问题时切换）。
Reality 的局限性
Reality 不是万能的：
- IP 暴露：客户端直连 VPS，GFW 知道你在连这个 IP（虽然不知道你在做什么）
- IP 被封风险：如果 VPS IP 被墙（封端口或封 IP），Reality 也连不上
- 不兼容 CDN：CDN 不认识 Reality 协议，流量无法经过 CDN 中转
- 客户端要求：需要支持 Reality 的客户端（主流客户端均已支持）
当前生态现状
截至 2026 年，Reality 相关生态已经非常成熟：
服务端：
- Xray-core（官方实现，最活跃）
- sing-box（跨平台，也支持 Reality）
客户端：
- v2rayN（Windows）
- v2rayNG（Android）
- NekoBox（跨平台）
- Clash Meta / mihomo（通过 VLESS 插件支持）
- Shadowrocket（iOS，付费）
面板/管理工具：
- 3X-UI（Web 管理面板）
- Marzban（多用户管理）
小结
VLESS + Reality 代表了代理协议的当前技术巅峰——零域名依赖、零证书维护、最强抗主动探测、优秀的性能。它的核心思想（借用大站证书 + 密钥对认证）是一个优雅的工程方案。
但它不适合所有场景。如果你需要 IP 隐藏能力（防止 VPS 被封），请参考第三章和第四章的 XHTTP + TLS + CDN 方案作为主力，Reality 作为备用。
推荐部署策略：
- 日常使用：XHTTP + CDN（第三、四章）— IP 隐藏，安全稳定
- 备用线路：Reality（本章）— 性能更好，CDN 出问题时切换
- 两套共存：同一台 VPS 同时运行两套方案，客户端随时切换
下一章将给出 VLESS + Reality 的完整实操部署步骤——从安装 Xray 到客户端连接成功，手把手教你搭建。