sing-box 连 Xray 新版 REALITY 报 reality verification failed 怎么办

发表于 分类于
sing-box 与 S-UI 内嵌的 sing-box 连 Xray-core v26.9.8 及更新版的 REALITY 服务端时报 reality verification failed，原因是服务端要求 X25519MLKEM768 密钥分享而客户端没发。本文讲清现象、根因与目前可行的排查办法。

本文依据 sing-box、S-UI、3x-ui 三个仓库的公开 issue 整理，未在本地实测复现。先说结论：这不是密码或 UUID 写错的问题，而是一次跨项目的握手兼容问题——升级 S-UI 到 v1.6.6 目前还解决不了它，下面不把它写成“升个级就好”。

现象长什么样

符合下面这组组合时，最容易对上号：

  • 服务端是 Xray-core v26.9.8 或更新版，跑 VLESS + REALITY，flow 是 xtls-rprx-vision；
  • 客户端一侧是 sing-box，或者是内嵌 sing-box 的 S-UI 出站（VLESS REALITY 出站），uTLS 指纹用 chrome；
  • 客户端日志里出现下面这句报错：
1
reality verification failed

S-UI issue 里的复现写得很明确：用 S-UI v1.6.5 或 v1.6.6 的出站检测去连这样的服务端，检测就返回 reality verification failed；同一台服务端，用 Xray-core 客户端能连，用 sing-box 去连 Xray-core v26.3.27 也能连。也就是说，变量不在账号密码，而在“服务端版本 + 客户端内核”这对组合上。

表现上还有一个容易误判的点：服务端并不会直接把连接掐断报错，而是把没通过验证的握手当成普通访客，静默 fallback 到伪装站。客户端看到的就是验证失败、打不开，而不是一个直白的“被拒绝”。

根因：服务端从 v26.9.8 起多了一道 ClientHello 检查

上游 sing-box issue #4520 把根因钉得很清楚：Xray-core v26.9.8 / v26.9.9 升级了 REALITY 依赖后，服务端要求客户端 ClientHello 里包含 X25519MLKEM768 密钥分享，并且排在普通 X25519 之前。缺了它，服务端就把这次握手判定为过期或异常的 ClientHello，不予放行。

而 sing-box 一侧的 chrome 指纹（metacubex/utls 的 HelloChrome_Auto）目前不发出 X25519MLKEM768 密钥分享，sing-box 1.14.3、1.14.4 都受影响。S-UI 并不自己实现这段握手，它内嵌 sing-box 来做 VLESS REALITY 出站：v1.6.5 内嵌 sing-box 1.14.3，v1.6.6 内嵌 1.14.4，两版都没有本地补丁。S-UI 维护者在 10 月 28 日的回复里也只说会尽量跟进 sing-box 的改动，没有给出面板侧的修复时间。

所以这条链是完整的：服务端新版收紧 → sing-box 的 chrome 指纹没发新密钥分享 → S-UI 跟着遭殃。单独升级 S-UI、单独升级 sing-box 到 1.14.4，都绕不过这一步。

3x-ui 用户也可能撞上同一类问题，但别急着下结论

3x-ui 仓库 10 月 27 日有一帖：三台节点一夜之间同时连不上，降级 Xray-core 后恢复。3x-ui v3.11.0 捆绑的是 Xray-core v26.10.21，同样在 v26.9.8 之后的收紧范围内；旧客户端（帖子里提到 v2rayN 7.10.5）配新服务端，确实符合“新服务端拒收旧握手”的模式，帖子里的回复也建议更新客户端、换一个能发 ML-KEM 的指纹、重新导入携带 support-x25519mlkem768 的订阅或链接。

但同一帖子也明确提醒了另一面：3x-ui 面板不会自己更新、也不会自己换内核。如果当晚三台节点都没动过，内核版本不会自己变，那么同时断线更可能是 IP 或端口被封、伪装站出问题，降级成功可能只是 coincided（碰巧赶上了重装或换端口）。该帖目前仍标记为信息不足，没有最终定论。照搬“降级就好”之前，先按下面这套办法分清你是哪一种。

排查步骤：先定位，再决定动哪边

第一步，对版本组合。确认服务端 Xray-core 是不是 v26.9.8 及更新版，客户端是不是 sing-box 或 S-UI 内嵌的 sing-box，两个条件同时满足，才优先按本文的根因处理；对不上，就先按常规思路查端口、防火墙和伪装站。

第二步，看日志原文。3x-ui 一侧可以用面板日志或下面这条命令看服务端日志（帖子回复里给出的取日志办法）：

1
x-ui log

如果客户端发起连接时服务端日志里完全没有记录，流量根本没到服务器，优先怀疑网络封锁，而不是握手问题；如果客户端一侧明确写着 reality verification failed，再回到本文的根因。

第三步，用 Xray-core 客户端做一次对照。S-UI issue 里写明同一服务端接受 Xray-core 客户端，这可以帮你确认服务端配置本身没坏。如果 Xray-core 客户端能通、sing-box 不通，问题就锁定在客户端握手上，不用再反复改服务端密码和伪装站。

第四步，决定临时方案时记住两条边界：

  • 升级 S-UI 到 v1.6.6 目前不能解决这个问题（S-UI issue 原话：Neither version has a local patch，升级面板不修复握手），不要把升级当成修复手段去反复操作；
  • 上游修复要等 sing-box 发布包含改动的版本，S-UI 再跟进 bump 依赖。在那之前，降级服务端内核只能算临时绕过，不是长期方案，降级前先确认面板与内核版本的对应关系，别把生产节点降到已被撤版的旧版本上去。

还没定论的部分

上游 sing-box issue #4520 截至本文整理时仍是 open 状态，没有已合并的修复；S-UI issue #1299 里提到的候选修复分支属于个人 fork，作者自己也说明不能作为面板的可支持依赖，本文不把它写成可用方案。等 sing-box 官方发布修复、S-UI 跟进新版后，本站再更新这篇的结论。

依据来源