疑似 CF free plan 的 gRPC 又寄了，当然 XHTTP 是不必担心的，wins come all day，且 packet-up 经我几轮优化后也没啥问题了，只是 POST 请求数略多，我在想要不重新开放 Mux cool 吧，它还可以解决应用层下行 100s 无数据被 CF 掐断的问题，win win

那倒不至于，我还是更喜欢 stream-up，还有 WSS 的问题在于 TLS Server Hello 是 http/1.1 没得藏，容易被 GFW 针对，且并非所有 CDN 都支持，且尚无 UDP QUIC H3 支持，总之 XHTTP 就是赢，赢麻了

🔨 1 new commit to Xray-core:main:

8212325: README.md: Add Loon to Others

https://t.me/LoonNews/1662 by RPRX

差点被你骗了

其实我一直想说的是，兼容协议都只是暂时的，如果有人觉得一时的兼容就可以完全 replace 那他真的是卧龙凤雏，举个例子 XUDP UoT Migration 两年了它就一直没支持，但是你双端 Xray-core 就可以默认用上，包括后续的 XHTTP 协议、REALITY 抗量子更新、Vision Seed 等我也不觉得它会跟进，总之就是如果你要用 Xray 的协议就不建议整花活，到时候别的软件没跟进你又要换回来，折腾自己

Xray-core 四月累积更新版本已 pre-release，主要包含大量修复，以及 XHTTP TLS 默认改为 packet-up，XHTTP REALITY 默认仍为 stream-one

https://github.com/XTLS/Xray-core/releases/tag/v25.4.30

请支持一个 REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

如果你有余力，请支持一个 Project X NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

Xray-core v25.4.30 已转为 latest 以触发更大范围的测试，目前的发布策略是即使没有 release notes，每两个版本标一个 latest，有 release notes 时再标 v1.250306.0 这样的兼容性 tag

小火箭 TF 版已支持 XHTTP，大家可以测测，如果有问题请反馈过去

何不充当 CF 反代器，为反审查事业尽一点微薄之力

有人觉得这次是 breaking，其实不尽然，因为我发得早，现在已经支持 X25519MLKEM768 的就技术前沿像 CF、Google 这样的，它们都没人偷，等一两个月后其它网站陆续开始支持了，大家的服务端早就升级、兼容了，所以我必须让 v25.5.16 成为新的稳定版

别笑了，中国某流行浏览器插件也有，之前还想着先做空它股价再放出消息来着，但发现没有做空空间，后来感觉水好像有点深不太敢放出消息，是哪个浏览器插件你们自己找吧，反正在你电脑上十几年了

还有 Xray-core v25.6.7 pre-release 了，快去测试

看 GitHub 上的讨论，我们两年前就发现了，不敢说是因为这插件太普及了，等下 Xray 团队直接上新闻，这我可受不了，且非要通过明文 HTTP 传你浏览记录的方式疑似涉及更高层面的监控，这我可惹不起

上市、股价太低、其浏览器插件很流行、十几年，够你们猜到了

既然有人猜到了，没错，就是“迅雷下载支持”，这个插件迅雷会自动安装，装上了你就有福了，它会自动把你当前访问的 URL 以明文 HTTP 的形式传到它的服务器，远程有是否收集的开关，它开的时候才会被抓到，两年前我查看被代理数据时意外发现的，当时我连它插件代码都分析完了，远程开关的页面都放 webarchive 上了，yuhan6665 连文章都写好了，所以我两年前就把整个迅雷给卸载了

现在还是不是这样不知道，感兴趣的自己去分析下现在的插件代码

https://github.com/XTLS/Xray-core/releases/tag/v25.6.8

Xray 出个 Vision，苹果也出个 Vision
Xray 用年份当大版本号，苹果也用年份当大版本号
Apple 这是要干嘛

研究 TUN 发现 rust 有现成的库，计划用 rust 写一个极简的 VLESS-CORE 作为客户端，有 XUDP、XHTTP、REALITY、Vision 等，还有无脑订阅，小白用户和机场主的最爱

无数次想重构 Xray-core 以摆脱 v2ray 的臃肿架构、提升性能，但似乎收益不高，且像 XUDP 迁移这类也需要服务端有 buffer，且服务端生态基本都被 Xray 占据，服务端也更复杂，不如 Xray 更加专注于服务端，开个新坑用 rust 写个 VLESS 专属客户端 core，很简单，不包含复杂且不必要的服务端代码，占用低，iOS 等资源受限环境都能跑

https://github.com/meh/rust-tun

这难道不是好事吗，更加迷惑 GFW 了

顺便一提，我觉得对于 REALITY target 选 CDN 而言，上个版本加入的 REALITY 回落限速比单纯拒绝不认识的 SNI 更合理，推荐迁移

不知不觉中 Xray-core 的 stars 快突破 30k 了，所以是谁还没点

https://github.com/XTLS/Xray-core

新饼来咯，XHTTP 多路径下行，所以聚合不同线路的下行真的能提速吗

https://github.com/XTLS/Xray-core/issues/4846#issuecomment-3041680786

虽然我以前就说过 IPLC、IPEL 什么的根本弱点，但是，这次我也不说我是预言家了，毕竟唇亡齿寒，还有我刚参与这些项目的时候就说 SS 这类纯随机数无脑封就行，有人听吗，我说 hy 这种 UDP 暴力发包很容易针对，有人听吗，我一直在建设的都是我认为的更为长久的解决方案，时间会证明一切