我的ip被标记了吗请问

各位的锐评已经很多了，让我评价一下就是，可能从 end 但非 endest user 看来就是这样，只知道 SS 和破分流啥的，Surge 能被提到确实更是忠实信徒，我觉得吧分流等客户端侧各种功能倒不能说是没创新，有些功能的确是别人第一个写出来的也不能否认，只是这不是只要在写相关的代码就一定会写出来的东西吗？换任何人来早点开发不都一样？顶多是比谁出生更早、闻道有先后罢了，如果还有人看不懂的话，以物理来做个不是很贴合的比喻就像是上个世纪底层原理的爆发和这个世纪基础理论几近停滞但应用一大堆一样，这么多年了 Xray 给众人的实际感受就是前者而不是后者，后者等 288 刀吧

v2ray 开创了平台架构，但遗憾是事只做了一半、没顾及 endest user，在当时看来比较硬核、不够小白，早有配置文件订阅机制的话绝大多数新功能和优化等都会被 PR 给 v2ray 而不会被分散，或许就没后来者啥事了，不过生态的百花齐放总体上是好事，GFW 喝茶单个项目也没用，但集合多协议的缺点是它们实现协议可能只追求“能连上就行”、且不一定跟进最新实现，可能存在原协议并不存在的特征、牵连服务端 IP 被封

软件开源协议：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.