软件开源协议：mit mpl gpl
线路开源协议：reality

华为翻墙有一种

奇怪的快感

这就是为什么我现在遇到阴阳人就直接 ban 了，一个个的都有什么大病

https://github.com/XTLS/Xray-core/commit/47cfe9994a6b39b1f673ba35e62b091bcce15a71#commitcomment-199503450

💬 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.

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

关于 https://github.com/ExclaveNetwork/Exclave/issues/480#issuecomment-5615081269 ：

REALITY 的本质是服务端 MITM，同时也是真正的 TLSv1.3，**精妙地继承了 TLSv1.3 的前向安全等一揽子安全设计同时还强制 pin**，这是 REALITY 与类似目标的其它协议的最大的不同之处，当然既然已经是 MITM 了那么服务端肯定要升级才能支持新的加密套件比如 X25519MLKEM768，并非 dyhkwong 所述的“协议设计者在设计协议之初未考虑到 TLS 的潜在变化”，**毕竟你不可能在一开始就支持未来才会出的加密套件**，dyhkwong 在其叙事中屡次基于刻意偏见把 REALITY 描述成“已经进行并且将来也会不得不持续进行破坏性变更”却丝毫不提 REALITY 的本质及安全特性，且虽然 REALITY 的认证依赖 CH 中的 X25519 但就算不依赖，**仅“看起来正常的 MITM”这一条就需要你更新服务端以支持新的加密套件**，至于依赖 CH 中的 X25519 进行认证也是 REALITY 的安全设计即 **GFW 仅拿到客户端配置无法对你 MITM**，而绝大多数别的“土制协议”是从未考虑过这一点的，这些也是 dyhkwong 不会告诉你的，甚至 REALITY 抗量子更新第二弹 加的 ML-DSA-65 更是将这一安全设计提前覆盖到了后量子时代

再说说指纹的问题，所有人都知道 nekohasekai 自那场搞笑“论战”过后就没有跟进过包括其 fork 的 REALITY 仓库在内的几乎任何更新，若不是他们后来统一用 Mihomo 的 uTLS fork 附带 REALITY ~~那估计这辈子你都看不到 sing-box 服务端支持 REALITY X25519MLKEM768~~，[Xray-core v25.5.16](https://github.com/XTLS/Xray-core/releases/tag/v25.5.16) 写的是“所以服务端一定要及时升级，避免新版客户端连不上”、“等一两个月后其它网站陆续开始支持了，大家的服务端早就升级、兼容了”但我也不说这个点了，Xray v25.5.16 版本开始的 Chrome 指纹就是带 X25519MLKEM768 的，也就是说 Xray 生态的服务端若不及时升级就连不上，那大家猜猜那些客户端 trim 掉 X25519MLKEM768 主要是为了兼容哪家的旧版客户端呢？甚至我觉得这还不是最大的重点，**最大的重点是都过去一年了还搞这种奇怪的指纹是要 [恶心谁](https://t.me/projectXtls/3539?comment=5242816)？不复当年 uTLS 出个指纹问题就想顺带把 REALITY 说死那次了？所以我总是说吧有些人它就是屁股歪，若非要说是“为了兼容”那么若没有这种指纹纵容，反而所有服务端早就升级了，甚至在协议作者明确说不能搞这种奇怪的指纹后某些人愣是不改，亘古未有啊，那我只能在服务端把这种指纹过滤掉以确保至少 Xray 搭出来的 REALITY 不会受此影响，~~都是这个世界的错~~**

Reply to this message to post a comment on GitHub.

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

https://github.com/ExclaveNetwork/Exclave/issues/480#issuecomment-5647030654 依旧稳定发挥了 dyhkwong 基于屁股说话只说一半、断章取义误导观众的传统艺能：

首先又是上次掰扯过的问题，虽然当时风扇确实没给我说，更没有他们脑补的“我授意”什么的，**但 Xray-core v26.2.6 确实也写了“v26.2.6 包含一些 v26.1.23 新增功能的配置项变更、重要修复，请及时升级 Xray-core 以及 GUI 客户端”，我没改，web archive 自己去看，能别狗叫了不？** 其次又是跟 drownrat 学的车轱辘句式，他们口口声声的“漏洞”指的是当时没几个人用的 pcs 参数，**妄图以极小搏极大来糊弄过去“那些个客户端让本能用上 X25519MLKEM768 的用户降级到 X25519”的问题，毕竟后者影响面可是基于 REALITY 庞大用户基数的大多数非 Xray 客户端，抛开影响面谈安全问题/漏洞是诡辩，试图掩盖真正的核心问题是无耻**，无视我推动的那么多安全策略却拿没几个人用的参数来论证“不配”更是可笑，甚至我根本就没干那事，~~学到了 Sukka 和 drownrat 的精髓说是~~，提醒升级的 release notes 倒是我写的，后面 pcs 也是我强推才流行的

> 中间人拿到客户端配置对用户 MITM 属于用户不按照操作方式使用导致的自食其果，不属于协议问题。即使如此，基于 TLS 的协议仅拿到客户端配置仍然无法 MITM。REALITY 等魔改 TLS 认证流程的协议属于自己制造了别的协议不存在的问题再自己解决。

类似于“抛开影响面、抛开 release notes”的说话只说一半，~~这抛开不谈咋这么眼熟~~，**光说“制造了别的协议不存在的问题”却丝毫不提“解决了别的协议没解决的问题”，你那单纯套个 TLS 的协议是能妥善解决 SNI 白名单的问题还是说你要自签证书加 allowInsecure？甚至没我强推 pcs 的话这问题都没被摆到主流台面上来**，以前的 Trojan、现在的 AnyTLS 机场多流行这套组合你们也门清，至于自建，大概率又是“属于用户不按照操作方式使用导致的自食其果”，那问题是机场用户基本上是小白、自建用户基本上是大白，跟着教程甚至一键脚本冲就完了根本就不懂那些，**况且即使是 pin 证书也不如 REALITY 这类方案，它们虽然不完美但至少在持续进步，至于“中间人拿到客户端配置对用户 MITM”让用户自食其果，是你能保证用户的客户端配置不漏还是？以前说过很多可能性就不重复了，所以解决了这问题的协议它就是比没这解决问题的协议更先进**

最后终于到 trim 掉 X25519MLKEM768 的问题了，dyhkwong 口口声声辩护这一行为，~~“协议本身恶心”其实是“协议必须恶心”~~，**却没有告诉你 Go 程序使用 uTLS 的初衷就是“符合浏览器 Client Hello”，那你都 trim 掉了 X25519MLKEM768 你还是个 der 的浏览器 CH 啊这不搞笑吗？我说过就算回落到旧版 Chrome 指纹也比这强啊，他同样没有告诉你的是 Xray-core v25.5.16 即 REALITY 服务端支持 X25519MLKEM768 那一版开始，Xray 客户端的 Chrome 指纹就是默认指向带 X25519MLKEM768 的最新版，我们也没遇到什么大问题啊，官方尚且如此，第三方实现对齐官方行为不就行了，有什么必要留畸形的指纹？甚至一年后官方明确说了不能搞这种，一年多了还不能改？是为兼容还是实际上懂的都懂，他更没有告诉你的是客户端带上 X25519MLKEM768 而连不上旧版服务端在当时只是极少数，这就是为什么像 Xray 直接切新指纹本就完全可行**

Reply to this message to post a comment on GitHub.

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

> ~流窜AI那边准备一年内接管互联网了，人类开发者还在争论指纹~

能不能别搞笑了这争论的是指纹吗？分明就是某些人看我不爽又干不掉我所以只能天天拿些鸡毛蒜皮的小事/张冠李戴来攻击我以及 Xray 的事

反正所有问题就必须是我的问题、大问题，不如让我们回顾一下今年我和哪些傻逼对线过：

1. Sukka 看到 REALITY 仓库 maxUselessRecord 是 16 就直接高潮，甚至给我写了七千字小作文，然而我早就给它改成 32 了，16 是别人误改
2. 刘某人韭菜割多了自信心爆棚，竟敢说我不了解 ShadowTLS 的实现细节，结果发现尴尬的是自己，被我喷到退休、连 Surge 论坛都关了
3. 小唐人预告拉满，都以为它要整一波大的结果却拉了坨大的，PoC 全面误伤正常网站，后面根据我写的 TODO 的 PoC 甚至也检测不出来
4. drownrat 自己搞错了死不承认，只能硬磕当时没几个人用的 pcs 算 CVE9，甚至眼瞎没看到 v26.2.6 明确写了让用户升级，只能把我拉黑怕我继续揭穿他，当然最搞笑的还是这傻逼要手搓“核弹”，它那“核弹”其实是它认为的我的小号在推特上的历史发言，自己洗脑自己了属于是
5. dyhkwong 的误导性言论刚刚我已经分析过了，弄出这畸形的指纹只能说是卧龙凤雏，毕竟 Xray 从一开始就没搞过这种指纹也没什么问题，并且若用户迟迟不更新 Xray 服务端那么甚至 Xray 自己的客户端都连不上，畸形指纹兼容的是哪家服务端不言而喻，要么就是故意的

相信大家都看明白了，这些傻逼的落脚点就是要踩我，至于什么理由不重要，甚至根本不是我干的事也能把帽子扣我头上，甚至没什么影响范围的事也必须是十分严重的问题，我早习惯了，早在去年某些人借 uTLS 指纹问题想顺带踩死 REALITY 时我就说过，“任何问题都必须是 Xray 的非常严重的问题”，今年这些事能让大家看得更清楚，**当然更傻逼的是这些狗喜欢通过小圈子/私密群来拉人头，就连什么都不懂的小白用户都要被他们拉出来给他们点赞，然而这些事情并不是你拉赞多你就占理，最终历史会给出公正的评判，届时只会更加揭露他们是跳梁小丑的本质**

Reply to this message to post a comment on GitHub.

Xray-core 已合并 XDRIVE 进 main，第 2000 个 commit，对于俄罗斯、伊朗用户，需先配置好 Google Drive API，记得开 mux.cool，并将 SNI 设为 www.google.com，若某地访问不了 Google，可以试试 template

XDRIVE 不仅无视 IP 白名单，还能白名单 SNI domain fronting，至于速度，Google Drive 看起来还不错，其它服务看你们能不能找到快的

评论区有说国内的，额不要自作多情，这协议延迟略高且吞吐量略低，对于国内而言大概永远也成不了主力，除非你追求非常别致的隐蔽翻墙