💬 New comment on Xray-core#6477 Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed
by @RPRX

> > @iciness xray升级到26.9.9后reality又无法连接了人都麻了
>
> mihomo代理配置里reality-opts:下加入support-x25519mlkem768: true 另外，服务端miniClientVer可以先删掉了

由于主要针对 Client Hello 缺少 X25519MLKEM768 的问题，Xray 最新版本做出了更精确的调整，Mihomo 加上述参数即可 https://github.com/XTLS/Xray-core/issues/6714#issuecomment-5581324161

看到“关爱世界委员会”的 Exclave 作者发的这篇声明 https://github.com/ExclaveNetwork/Exclave/issues/480 就特别想笑，从头到尾捋一下这种奇怪的指纹怎么来的：

1. 2023 年 nekohasekai 给 Xray-core 开了一些包含 SagerNet/* 组件的 PR，我们觉得维护不便&路线冲突故予以拒绝，简单来说这些代码应当直接 PR 到 Xray-core 仓库而不是引用别的仓库、增加维护/修改成本，~~后面更是发现是 GPL~~，难以维护且被收回授权的 SS2022 就是例子
2. 有了这样的导火索，nekohasekai 从此天天找茬 Xray，直至同年九月爆发了“TLS in TLS 是炒作”的论战，他认为该项检测不现实/成本高，甚至在没看 Trojan-killer 代码的情况下脑补它的实现原理并进行批评，闹出了很大的笑话，还趁热打铁在其博客连发两篇春秋笔法、错误百出的小作文，~~讽刺的是，后来“关爱世界委员会”成员推出了“旨在解决 TLS in TLS”的 AnyTLS，nekohasekai 不提炒作了甚至早点了 star~~
3. 2025 年中 REALITY 支持了 X25519MLKEM768，虽然这需要升级服务端和客户端，但由于当时并没有多少网站支持它所以留足了升级的时间，**然而 sing-box 因上述纠葛迟迟不更新 REALITY 服务端的代码，导致后来只有 trim 掉 X25519MLKEM768 才能连上 sing-box 服务端**，虽然 Xray 从未这样做过且也没什么大问题，但包括 sing-box 在内的一些其它客户端为了兼容 sing-box 服务端而搞出了这种奇怪的指纹

这根本不是 REALITY 搞了多大的破坏性更新，而是 sing-box 故意迟迟不更新 REALITY 服务端代码的人祸，再往上究其原因就是 1、2 点所述的历史纠葛，Exclave 作者 dyhkwong 对上述三点只字不提，且 X25519MLKEM768 本来就会使连接更加安全而不单是 parrot 与否的问题，uTLS 主线 Firefox、Safari 指纹支持它至少半年了而不是“recent”，没有发版只是因为维护人手不足，dyhkwong 与其基于屁股、冠冕堂皇且无耻地把所有问题都归责于 Xray、呼吁“boycott Xray”，不如反思下你们这“关爱世界委员会”有没有关注过用户的数据安全问题，~~还说什么翻墙是伪命题~~

Reply to this message to post a comment on GitHub.