一次 Xray REALITY 连接失败排查：不是被攻击，而是伪装目标站失效

😀

最近搬瓦工上的 Xray REALITY 节点突然连不上，客户端提示 REALITY authentication failed。第一反应当然是有点慌：是不是服务器被攻击了？是不是 SSH 密码被爆破？还是 REALITY 也有什么“证书过期”的问题？

最后排查下来，真正原因不是被攻击，也不是 UUID、privateKey、publicKey、shortId 这些核心参数配错，而是原来使用的伪装目标 www.microsoft.com 在当前环境下无法完成 REALITY 后半段握手。把 dest/serverNames/servername 换成 www.yahoo.com 后，连接恢复正常。

一、问题现象

客户端连接失败，提示类似：

当时有几个现象比较迷惑：

所以一开始怀疑过两类问题：

后面证明，这两个方向都不是根因。

二、先确认 SSH 没有继续暴露密码登录

既然怀疑过被攻击，第一步先收紧 SSH。

服务器上查看最终生效配置：

输出类似：

这里的 without-password 是旧写法，含义等同于 prohibit-password：root 不能通过密码登录，只能走密钥等方式。

再看登录日志：

这说明实际登录方式是公钥登录，不是密码登录。

如果登录时仍然出现输入密码的提示，要注意区分：

这是本地 .pem 私钥的 passphrase，不是服务器 root 密码。

三、确认 Xray 服务本身正常

继续检查 Xray 服务状态：

结果显示：

再确认 443 端口确实由 Xray 监听：

输出类似：

检查配置文件语法：

输出：

到这里可以排除：

四、确认系统时间正常

REALITY 对时间比较敏感，所以继续检查时间同步：

输出关键部分：

说明服务端时间同步正常。

如果这里是 no，可以先处理时间同步，再重启 Xray：

五、开启 Xray debug 和 REALITY show

为了看清楚客户端连接时服务端到底发生了什么，临时把日志级别调高。

配置里增加或修改：

并临时打开 REALITY 的调试输出：

然后测试配置并重启：

只看指定客户端 IP 的日志：

客户端连接时，服务端出现了关键日志：

这条日志很关键。

因为服务端已经成功解析到了：

这说明 privateKey/publicKey/shortId/时间 这些 REALITY 核心认证参数并不是完全不匹配。

真正失败的位置是：

也就是服务端把伪装目标站点的 TLS 证书阶段推给客户端之后，客户端没有完成后续握手。

六、检查服务端配置

当时服务端核心配置大致如下，敏感字段省略：

客户端对应配置大致如下：

这里重点核对过：

所以继续看伪装目标站。

七、测试原伪装目标 www.microsoft.com

服务端执行：

结果显示，无 SNI 和有 SNI 都能握手成功：

这个结果说明：

但这里有个坑：xray tls ping 成功，只能说明目标站 TLS 基本可用，不代表它一定适合作为 REALITY 的伪装目标。

REALITY 还涉及客户端、服务端、目标站 TLS 行为之间的组合。目标站背后的 CDN、证书链、TLS 参数发生变化，都可能让以前能用的配置突然不适合。

八、换成 www.yahoo.com 后恢复

最后做了一个最小对照实验：不改 UUID、不改 privateKey、不改 shortId，只改 REALITY 的伪装目标。

服务端改为：

客户端同步改为：

然后重启 Xray 和客户端内核。

结果：连接恢复正常。

这就基本坐实了：问题集中在原来的 www.microsoft.com 伪装目标，而不是 VPS 被攻击，也不是 REALITY 密钥三件套配置错误。

九、最终结论

这次故障不是：

更合理的根因是：

将 dest/serverNames/servername 换成 www.yahoo.com 后恢复，说明 REALITY 的目标站并不是“配置一次就永久稳定”。

十、排查命令汇总

检查 Xray 服务：

检查端口监听：

检查配置语法：

检查系统时间：

查看 Xray 日志：

按客户端 IP 过滤日志：

测试伪装目标：

从 privateKey 重新计算 publicKey：

检查 SSH 是否仍允许密码登录：

十一、以后怎么选 REALITY 目标站

这次踩坑之后，我对 REALITY 的 dest/serverName 有几个经验判断：

当前实测可用的是：

可以作为备用测试的候选：

不建议继续使用本次已经失败的：

也不建议随手用 Cloudflare 这类特别热门的 CDN 目标，因为失败流量会被转发到目标站，可能带来额外风险和异常流量。

十二、排查完成后的收尾

调试完以后，记得把服务端配置改回低日志级别：

并关闭 REALITY 调试：

然后测试并重启：

最后备份当前可用配置：

十三、总结

这次最容易误判的地方在于，客户端提示的是 REALITY authentication failed，看起来像密钥认证失败。但服务端开启 show 后可以看到，真实断点并不是简单的 UUID、publicKey、shortId 错误，而是：

所以排查 REALITY 问题时，不能只看客户端报错。更可靠的路径是：

这次的结论也很简单：

最终更换 www.yahoo.com 后恢复连接，问题解决。