这下 PQ PFS 0-RTT 的 VLESS 加密也可选全随机数外观了，基本只 XOR 占比万分之六的 data header，没啥性能成本，唉，全随机数

https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3183275526

代码运行效率肯定是首要的，除非硬盘不够，没必要一边装着几十个 G 的学习资料另一边对着代理软件抠这 4M

🔨 1 new commit to Xray-core:vless:

84835be: Support VLESS Encryption (native/random) + XTLS Vision + Any Transport like XHTTP (UDS or not) + TLS/REALITY

https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3200720109 by RPRX

刚刚 IPv4/TCP/443 正常网站也全挂应该是 GFW 配置错误，现已恢复

这提醒了大家必须要有一个 XHTTP over CDN 备用，有很多 IPv6 可选，也可以 UDP/QUIC，关键时刻防失联

XHTTP 继上次 CF gRPC 时好时坏后，再次证明了自己的价值，赢！

💬 New comment on Xray-core#4952 chore: remove vmess from core.
by @RPRX

https://github.com/XTLS/Xray-core/commit/ad7140641c44239c9dcdc3d7215ea639b1f0841c 第二版来了，~~也是最终版，感觉又写一套加密人已经麻了~~，MLKEM768X25519 临时密钥交换，中转无限串联，每一级都是基于 X25519 或 ML-KEM-768 认证（最后一级现在可选 X25519 了，公钥很短，~~毕竟未来的量子计算机无法逆转今天的认证~~）

为了避免上版中看似复杂的 XOR 并简化代码，前向安全的密钥交换和 ticket 被 AEAD 了，拿服务端配置才能解，~~虽然也破解不了~~

除了原生外观要不要允许两端先发 padding 消息还要想一下外，~~应该没啥要改的了~~，有兴趣的可以先编译出来测试，晚点 PR

---

服务端配置：（原生外观 / 只 XOR 公钥 / 全随机数。只允许 1-RTT 模式 / 同时允许 1-RTT 模式与 600 秒复用的 0-RTT 模式）

"decryption": "mlkem768x25519plus.native/xorpub/random.1rtt/600s.(X25519 PrivateKey).(ML-KEM-768 Seed)..." 

客户端配置：（native/xorpub 的 XTLS 可以 Splice。只使用 1-RTT 模式 / 若服务端发的 ticket 中秒数不为零则 0-RTT 复用）

"encryption": "mlkem768x25519plus.native/xorpub/random.1rtt/0rtt.(X25519 Password).(ML-KEM-768 Client)..." 

/ 是只能选一个，后面 base64 至少一个，无限串联，使用 ./xray x25519 和 ./xray mlkem768 生成，替换值时需去掉括号

"mlkem768x25519plus" 代表未来可以无感并联其它密钥交换，"xorpub" 只 XOR 公钥的外观为前面全随机数、后面 23 3 3

支持 XHTTP 等有传输层时的 XTLS，代理 TLSv1.3 时不会二次加密，"random" 全随机数外观后面会只 XOR `23 3 3`，成本极低

Reply to this message to post a comment on GitHub.

VLESS Post-Quantum Encryption：https://github.com/XTLS/Xray-core/issues/5067

VLESS NFT：https://opensea.io/collection/vless

Xray-core v25.8.29 预发布，支持 VLESS Post-Quantum Encryption

或者你也可以使用 Mihomo v1.19.13 ，感谢多次 sync code

VLESS NFT：https://opensea.io/collection/vless

Xray-core v25.8.31 正式版，支持 VLESS Post-Quantum Encryption

或者你也可以使用 Mihomo v1.19.13 ，感谢多次 sync code

VLESS NFT 自成一个系列，每个图片都不同且只有一个，你可以选择自己喜欢的图片来收藏，先到先得

https://opensea.io/collection/vless 首发放出了二十个不同的 VLESS NFT 图片

本次还放出了两个稀缺的 Project X NFT，如果你有余力，请支持一下：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

Xray-core v25.9.5 正式版，支持 VLESS Post-Quantum Encryption

或者你也可以使用 Mihomo v1.19.13 ，感谢多次 sync code

VLESS NFT 自成一个系列，每个图片都不同且只有一个，你可以选择自己喜欢的图片来收藏，先到先得

https://opensea.io/collection/vless 首发放出了二十个不同的 VLESS NFT 图片

本次还放出了两个稀缺的 Project X NFT，如果你有余力，请支持一下：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

Xray-core v25.9.11 正式版，支持 VLESS Reverse Proxy 极简配置

VLESS NFT 自成一个系列，每个图片都不同且只有一个，你可以选择自己喜欢的图片来收藏，先到先得

https://opensea.io/collection/vless 首发放出了二十个不同的 VLESS NFT 图片

本次还放出了两个稀缺的 Project X NFT，如果你有余力，请支持一下：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

许愿池

真的是受不了了，我说一下吧，看过五年前我写的 VLESS ALPHA/BETA 那些的话就知道 VLESS Flow 和 Seed 机制的设计理念就是自定义流量特征，这就是 VLESS 协议的本意，只是 GFW 没行动我也不想过早行动，并且 Vision 的协议设计并非是所谓的“写死的 padding 参数”，实际上代码中兼容任意 padding，不同实现的 padding 参数是否一致我们都不知道，只是没有开放用户配置（Seed）而已，Seed 也 PR 两年了我都没合原因之一就是不急，有针对的行动才会有更大的优势，不然你就成为被针对的那个了，就算推出了你现在就能实现不同的“不被封”的效果吗？还是说追求概念？就像 REALITY SpiderX 有几个人用过

下个版本预告：XTLS Vision Seed

看了很多 Go 的 Windows TUN 发现全是 wintun.dll，还以为有啥新方式结果跟四年前的 Xray-tun 一样，只能说是糟糕的系统要啥啥没有，没有 Splice 也没有 TPROXY，不过好像 WFP 可行

根据这次泄露出来的文件：

1. 实锤了 GFW 会采用安装根证书的方式对 TLS 流量 MITM，REALITY YYDS，赢！https://github.com/XTLS/REALITY
2. 实锤了 GFW 针对明文 HTTP 流量的分析、注入能力，Web-Panel Plain-HTTP，输！https://github.com/XTLS/Xray-core/pull/3884
3. 实锤了省墙等地区墙的存在 https://github.com/net4people/bbs/issues/254#issuecomment-1562817397
4. 实锤了 GFW 早就会针对翻墙的个人进行监控、追踪，而不一定直接封你 https://github.com/net4people/bbs/issues/254#issuecomment-1563161126

总是有人通过臆想来说 GFW 不会怎么怎么样什么的，不如想想为什么我要把协议设计成这样，为什么要防证书链攻击，为什么要防客户端配置泄露，为什么要防监控等，因为我们五年前就得到了很多内部信息，我也多次提过，所以后来我开发的协议全部都有针对性

总有人觉得没被封就等于协议是安全的，然后硬是在那里用不够安全的加密还沾沾自喜，比如中转 SS，或者 ShadowTLS+SS 什么的，殊不知老大哥在注视着你，那确实够“安全”的，还在用偷个客户端配置就能解密的“加密协议”，不知道在想什么，建议使用 VLESS Encryption https://t.me/projectXtls/1020