Xray 26.9.9 Reality 升级后客户端突然连不上：mihomo 必须补的 MLKEM 一行配置

2026 年 10 月下旬，我把一台新加坡 VPS 上的 Xray 升到了 26.9.9，升级本身一切正常，服务端日志也没有报错。但随后手机和电脑上的 mihomo 客户端全断了：界面只显示 Timeout，翻内核日志才看到真正的错误——REALITY authentication failed。服务端、公钥、UUID、short-id、伪装域名一个都没动过，唯一变的是 Xray 的版本。本文记录这个坑的根因和修复方法。

一、现象：只显示 Timeout，真相在内核日志里

出问题时客户端的表现很有迷惑性。FlClash 的界面上只有 Timeout，看起来像网络不通、像节点挂了、像防火墙把端口封了。我先按老思路排了一圈：ping 域名通、端口通、换网络（Wi-Fi 切流量）同样超时、重启客户端无效。

真正的信息在内核日志里。mihomo 的日志写的是：

REALITY authentication failed

这不是网络问题，是 TLS 握手阶段的 Reality 认证被服务端拒绝了。排查结论先写在这里：Reality 节点报 Timeout 时，先看内核日志再下结论，Timeout 不等于网络不通。 这个习惯后来又帮我省了一次冤枉排查——同日另一位用户（manateelazycat）在 Xray 26.10.21 下遇到了一模一样的症状，同样是翻内核日志才定位到同一行报错。

二、根因：服务端开始强制要求 MLKEM 密钥交换

Xray 从 26.9.8 这个开发周期开始（实际出货的正式版是 26.9.9），Reality 服务端改了规矩：要求客户端的 ClientHello 里必须携带 X25519MLKEM768 的 key share。

X25519MLKEM768 是经典椭圆曲线 X25519 与后量子算法 MLKEM-768 的混合密钥交换。服务端升级后，只发传统 X25519 key share 的旧客户端会被直接拒绝认证——不是降级协商，是直接失败。这就是为什么升级前一切正常、升级后全断：协议要求变了，客户端没跟上。

这里还有一个容易踩的版本号坑。GitHub Release 里并没有 26.9.8 和 26.9.5 这两个 tag，我实拉 API 核对过，26.6.27 之后直接是 26.7.11、26.7.28，然后跳到 26.9.9、26.9.30、26.10.21。26.9.8 只是 issue 里对 9 月开发周期变更的约数门槛，实际出货版是 26.9.9。如果你在网上看到"降级到 26.9.5"之类的说法，别照着做——那个版本不存在。 求稳降级到 26.6.27，次选 26.7.28，这两个是真实存在的 tag。

三、修复：mihomo 客户端补一行配置

mihomo 的修复很简单，但必须手动做——VLESS 分享链接里没有这个字段，订阅转换工具也不会帮你补。在 Clash 配置里找到 Reality 节点，在 reality-opts 下加一行：

- name: "🇸🇬-SG-Reality"
  type: vless
  server: 111.91.20.50
  port: 443
  uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  network: tcp
  tls: true
  servername: www.google.com
  reality-opts:
    public-key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    short-id: xxxxxxxx
    support-x25519mlkem768: true

关键就是最后一行 support-x25519mlkem768: true。mihomo 把它做成显式 opt-in，默认是不开的，所以升级服务端之前跑得好好的旧配置，升级后必须手动补。改完重载配置，内核日志里的 REALITY authentication failed 消失，延迟恢复正常。服务端、公钥、UUID、short-id、伪装域名全都不用改，只改客户端这一行。

我的 SG Reality 服务器（111.91.20.50）就是 Xray 26.9.9，补上这一行之后恢复。这个修复在 26.10.21 下同样有效——manateelazycat 同日实测，FlClash（mihomo 内核）加同一行后恢复。

四、sing-box 系客户端：当时没有开关，换协议绕行

如果你用的是 sing-box 系客户端（包括 Karing 这类套壳），当时没有对应的开关可用。Xray 26.9.9 发布时，sing-box 的 Reality 客户端尚不支持 MLKEM，相关的修复也没有合入。遇到这种情况不要死磕 Reality，改走 WS 或 XHTTP 传输，等上游支持后再切回来。

另外注意一个例外：第三方 fork Jolymmiles/Xray-core 的 v26.10.5-1858 自称服务端又能接受不带 MLKEM 的客户端。但那不是上游 XTLS 的正式行为，不能等同于"官方已修"。上游最新正式版仍是 26.10.21（该版只是紧急 CA 证书修复，未放宽 MLKEM 要求），mihomo 的开关仍是显式 opt-in，sing-box 仍不提供 MLKEM。所以上游路线下这个坑没有消失，客户端手动补行仍是正解，不要等服务端"修好"。

五、交付前的检查清单

这次踩坑之后，我给自己立了一条交付检查：凡是把 VLESS+Reality 分享链接转成 Clash 订阅或配置，目标服务端是新版 Xray 时，必须手动核对 support-x25519mlkem768: true 在不在，不能宣称"1:1 无增减"。分享链接表达不了这个字段，但内核又要求它，YAML 语法对不等于语义对。

顺带把排查顺序也固定下来，Reality 节点出问题时按这个顺序走：

1. 先看内核日志，确认是不是 REALITY authentication failed；
2. 是的话，核对服务端 Xray 版本是否 ≥26.9.9，再核对客户端 reality-opts 里有没有 MLKEM 开关；
3. 不是的话，再按网络问题排查（端口、防火墙、DNS）。

这个坑的本质是协议升级期的版本错配：服务端先行一步，客户端配置还停在旧默认值。知道根因后修复只要一行配置，但不知道根因时，Timeout 的表象足够让人把服务端、网络、防火墙全拆一遍。希望这篇能帮后来的人省掉那一圈。