东京 VPS 代理节点实测：VLESS + REALITY 排障记

背景

手里有一台东京 VPS，需求很明确：搭一个自己用的代理节点，要快、要稳、要抗封锁。方案选了 Xray 的 VLESS + REALITY + xtls-rprx-vision，监听 TCP 443，UFW 放行，BBR 开启——都是标准操作。

服务端配置一次写对，systemctl status xray 显示 active，443 端口确实在监听，甚至能正常呈现微软的证书作为 REALITY 目标。一切看起来都对了，除了：客户端连不上。

排障过程

按常规思路排查了一圈：

• UUID、密钥反复核对 —— 全对
• 防火墙规则 —— 443/tcp 已放行
• 服务端日志 —— 没有明显报错
• 换客户端、换网络 —— 都不行

这种「配置全对但就是不通」的情况最磨人。最后把目光投向了 REALITY 的伪装目标本身：www.microsoft.com:443。

根因：8192 字节的硬编码上限

这是 Xray 的一个已知 bug（官方 issue #6356）：REALITY 在握手时需要缓存目标站点的证书，而代码里写死了 8192 字节的上限。微软官网的证书链体积超过了这个上限，导致握手直接失败——跟你的密钥、UUID 一点关系都没有。

教训：当所有「该对的」都对了，就去怀疑那些你以为「肯定没问题」的部分。

修复：一行配置的事

把 REALITY 的伪装目标从 www.microsoft.com 换成 www.cloudflare.com（证书体积小，在上限内），重启 Xray，客户端把 SNI 同步一改——通了。

服务端实测：Google 返回 204，example.com 正常加载。节点正式服役。

经验清单

• REALITY 伪装目标优先选证书链短的大站，Cloudflare 系是稳妥选择
• 排障时先验证「传输层」再怀疑「应用层」：证书、SNI、指纹这些同样会杀死连接
• 遇到玄学问题，先去翻项目的 GitHub issues——你大概率不是第一个踩坑的人

下一篇：《Hysteria2 + Brutal：UDP 加速的暴力美学》——在同一台机器上再加一个 UDP 协议的节点。