chore: remove vmess from core.

[Jolymmiles]

the goal is to remove the obsolete protocol

[ImMohammad20000]

Its better to remove vmess after vless encryption added

[M03ED]

well done, destroy backward compatibility and ruin all clients use xray

[ImMohammad20000]

Also so many people use tcp http configs and vmess for encryption removing vmess not a good idea

[zZedix]

you don't like it you don't use it
Iran's GFW is focusing on TLS encrypted proxies
currently using VMESS is our main solution in this situation
since vless is not encrypted without TLS its a vey bad idea
so leave the vmess alone and don't use it if you don't like it

[vffuunnyy]

well done, destroy backward compatibility and ruin all clients use xray

But keeping deprecated features forever just slows everything down. Protocols evolve for a reason — security, efficiency, and maintainability. It’s not about "ruining" anything — it’s about moving forward.

No one is stopping you from continuing to use older versions of the core if backward compatibility is that critical for your setup. But please don’t expect the latest versions to stay bloated with outdated protocols just to support legacy usage.

Think about the bigger picture — long-term maintainability matters.

[Kiya6955]

Better Option: remove yourself from the world!

[amirsaam]

Unless an encryption method that does not require TLS is added to VLESS, this only helps GFW to do more censoring and not helping the ones who fight against GFW because TLS is easily gets blocked whenever they want.

Add an encryption method, this PR should be marked as Work in Progress :)

P.S: Russia's Gov is not censoring as much as China and Iran, the problem is you think because TLS works in Russia, everywhere else also does work fine, sorry but that's not the case.

[iamtheted]

It's a BIG NO, instead of removing vmess, focus on adding a practical feature.

[M03ED]

But keeping deprecated features forever just slows everything down. Protocols evolve for a reason — security, efficiency, and maintainability. It’s not about "ruining" anything — it’s about moving forward.

No one is stopping you from continuing to use older versions of the core if backward compatibility is that critical for your setup. But please don’t expect the latest versions to stay bloated with outdated protocols just to support legacy usage.

Think about the bigger picture — long-term maintainability matters.

there is a third option if this pr merged, abandon xray and use a alternatives, no more pr on this repo because maintainers like rprx don't commit new changes them selves, people have to use alternatives if they need to run vmess, clients have 2 way, use multiple core (same as v2rayn) or replace xray
at the end this will lead to less pr for xray

[Fangliding]

nope

[RPRX]

Xray-core 不会移除已有的功能/协议，除非是内部迭代（旧 XTLS->新 XTLS，H2/QUIC->XHTTP）或彻底没人用了（旧 MTProto）

VMess 非 Xray 原创且支持广泛，不属于 Xray 移除了就能带动其它软件一起移除的协议，也并非彻底没人用了，所以不会被移除

[Johnny256Dawson]

这大概就是格局了吧

[gfw-killer]

This is a sign!
@RPRX Please prioritize VLESS Encryption
It's more urgent than Vision Seed and Switch (as XHTTP has both features)
but VMess encryption is not as safe as it should be
Governments have fun with non-encrypted VLESS and even VLESS+TLS when it's going through their or data-broker CDNs
even when it's VMESS+TLS but airport subscription is also tunneled via the same CDN (Gov. have the static passsword), or when user shares/gets it's vmess config share link via a government controlled line like SMS or domestic messenger/social media

[RPRX]

@gfw-killer Ok, I wiil see what I can do for solving these problems.

大概就是客户端持有 X25519 与 MLKEM768 公钥，生成密码密文并加密数据发给服务端，服务端持有 X25519 与 MLKEM768 私钥以解密出密码并解密密文数据，密文部分数据传输格式就是 TLS data record，以便在未来的版本中结合 Vision Seed 流量混淆机制

简单设计的话该加密自身为 0-RTT、抗量子，客户端配置泄露不会导致被解密，服务端配置泄露会导致被解密，但还好，因为该加密的微观特征明显，目标并非直接过墙（2025 了都），而是保护数据免受 CDN 的窥探，也就是说外面还有一层 TLS 的保护

如果有人将这一高强度土制加密放明文 HTTP 里面但导致被 GFW 封锁了，则可以证实 GFW 针对明文 HTTP 的审查，这就是阳谋

得益于 VLESS 预留了 "encryption":"none"，如果客户端不支持该加密则不会发出数据而是会报错，下个月的版本就发这个吧

[RPRX]

话说 2025 了基本都有 AES-NI 了吧，加密方式只有 AES-256-GCM 没问题吧

[gfw-killer]

Please add chacha20-poly1305 option too, it's needed for devices with no AES-NI (old or budget devices)
https://gist.github.com/raycoll/62a660602b9ec9fb67b6443f16732080
It's possible to check if device has it or no, then fallback to chacha20-poly1305
https://github.com/klauspost/cpuid

[RPRX]

主要是不想把这个加密设计得过于复杂，服务端可以先 aes-256-gcm 解密，失败的话就试 chacha20-poly1305

[gfw-killer]

If it's gonna have a Header and Payload part like VMess, then Header encryption can always be AES then header determines the payload encryption algorithm.
If not, then decryption in VLESS Inbound can have multiple choices, for example :
"decryption": "chacha20-poly1305,aes-256-gcm" (first try chacha20-poly1305 then try aes-256-gcm)
but if it has no separated Header and Payload parts, then it will be expensive for server to check if the incoming connection is valid or no, as partial decryption of GCM or Poly1305 algorithms is not possible, then vless fallback will be slow and maybe it also become vulnerable to denial of service

[RPRX]

If it's gonna have a Header and Payload part like VMess, then Header encryption can always be AES then header determines the payload encryption algorithm.

其实我不想设计这种机制，因为尝试两次解密的开销对于后面庞大的 body 来说不值一提，基本上没什么额外开销

[RPRX]

@gfw-killer 我更新了 VLESS 加密的设计方案，像 QUIC 一样跨二元组复用 sharedKey，兼顾 0-RTT 与前向安全，测试代码已跑通

本周末将正式推出 VLESS 加密，主要特性如下：

• 抗量子的认证与加密，0-RTT
• 前向安全，重放防护
• 更优的性能，且可选 XTLS

全面基于 ML-KEM-768、HKDF(SHA256)、AES-256-GCM/ChaCha20-Poly1305

[RPRX]

https://t.me/projectXray/4394072

风扇滑翔翼, [2025/8/6 20:06]
xtls已经有这些了就不用兼容xtls了 吧

Project X Channel, [2025/8/6 20:07]
XTLS 是流控不是加密，处理 TiT 和裸奔用的

意思就是 CDN TLS 流量特征由 XTLS 处理，且可以裸奔避免二次加密

风扇滑翔翼, [2025/8/6 20:08]
那个mlkem是啥说法 仿reality那样?

Vesilia, [2025/8/6 20:09]
我想了一下 VLESS 加密不用 ML-DSA-65 做认证了，用 ML-KEM-768，服务端生成解封装 key 和对应的封装 key，后者只有 1088 字节由客户端配置存着，首次连接时把认证密钥密文和自己的临时封装 key 发给服务端，服务端用共享密钥加密或 hash 认证密钥发给客户端即可认证服务端的身份，要不要引入 x25519 我还在思考

Vesilia, [2025/8/6 20:09]
https://github.com/XTLS/Xray-core/pull/4992#issuecomment-3156162191

Project X Channel, [2025/8/6 20:09]
差不多，但 REALITY 的认证用不了这种方式，因为 Client Hello 塞不下

VLESS 用这种方式主要是 all in ML-KEM-768，以及防止二维码塞不下

风扇滑翔翼, [2025/8/6 20:12]
所以复用是之前说的 HKDF(ticket, salt)吗

Project X Channel, [2025/8/6 20:13]
决定不引入 X25519 了，这玩意儿基本不出十年就废了

Project X Channel, [2025/8/6 20:13]
对，服务端只存十分钟，十分钟后密钥扔掉即前向安全，且重放无效

风扇滑翔翼, [2025/8/6 20:14]
这些握手数据放哪 那些空置了几年的proto吗

Project X Channel, [2025/8/6 20:15]
加密是套在现有协议外层的，VLESS 和 flow 在内层

过 CDN 的话，因为只是不想 CDN 看到 SNI，可以 XTLS 避免二次加密

风扇滑翔翼, [2025/8/6 20:17]
有续火吗 比如协商一个新的ticket或者给这个ticket续命 还是说10分支重新握
以及如果服务端完全丢了ticket(eg 重启)能不能回退回原握手 还是失败重试

Project X Channel, [2025/8/6 20:19]
临到期前客户端发起重新协商，客户端如果几次连接失败也会重新协商

风扇滑翔翼, [2025/8/6 20:21]
服务端不认识这个ticket回个reject这样快点吧

Project X Channel, [2025/8/6 20:22]
可以实现明确拒绝，帮助客户端确定是网络问题还是，不过如果攻击者拦截这个拒绝信息，不过好像攻击者在一开始就拦截更快

服务端发送非 TLSv1.3 record 形式的数据实现明确拒绝吧

Yuhan6665, [2025/8/6 20:23]
突然开始填坑 orz

Project X Channel, [2025/8/6 20:25]
gfw-killer 一人多次血书

风扇滑翔翼, [2025/8/6 20:29]
最好收到reject了再丢弃ticket 不然纯网络问题没理由丢
还有用sync map存[dialerConf]ticket 的话可以用用utils里有一个TypedSyncMap

Project X Channel, [2025/8/6 20:32]
现在决定是这样的

这个 ticket 就是 32 字节，似乎没必要 TypedSyncMap？

风扇滑翔翼, [2025/8/6 20:34]
不用sync map就随便

Project X Channel, [2025/8/6 20:34]
是 sync.Map

我看到你写的那个 TypedSyncMap 了，我试试用一下

U̶nknowNㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ, [2025/8/6 20:49]
Currently XTLS is limited to TCP+TLS/Reality, will the new XTLS also support ws/grpc/xhttp for cdn usage?

Project X Channel, [2025/8/6 20:50]
对

[RPRX]

@Fangliding

话说由于 增强 mux 也在计划中，我在想要不再出个 1-RTT 的模式实现不复用 sharedKey 时的前向安全，防止有人蛐蛐十分钟

但感觉有点没必要

[RPRX]

因为把“多个被代理连接”用 mux 塞进同一条 VLESS 加密内，相较于复用 sharedKey 加密“多个被代理连接”

那如果这个 sharedKey 泄露了，结果都是能解密出“多个被代理连接”，这踏马本质上是一样的

[RPRX]

而如果不 mux 也不复用 sharedKey 的话，在 TCP TLS 2-RTT 的基础上再加 1-RTT，这很有想法，用户测出延迟高的话更会被吐槽

[Fangliding]

重要的不是泄露sharedKey而是不过滤的话请求可以被重放(
加过滤器会导致那个拒绝服务攻击那为什么中间人不一开始就掐断连接呢 毕竟vless加密说了目的不是隐蔽自己是vless

[RPRX]

@Fangliding 不过你要想一下主要目标是放 CDN 里，CDN 去执行这个重放来攻击自己的用户吗

[RPRX]

不过 GET 难说，POST 的话肯定不会，连浏览器都有提示

[RPRX]

等我 FP 一下

[RPRX]

b0b2209 后续讨论转移至 #5067

[Jolymmiles]

@RPRX then.... now we can delete vmess?

[ImMohammad20000]

Why are you insist on removing vmess!
@Jolymmiles

[Jolymmiles]

Why are you insist on removing vmess!
@Jolymmiles

Because we have vless encryption

[RPRX]

那也没有因为有了 VLESS XTLS REALITY 就移除 Trojan 啊，全移除了的话我还写啥 vless-core，直接把 Xray-core 更名得了

留着其它协议主要是为了兼容性，这些协议也没占多少地方

[ImMohammad20000]

Why are you insist on removing vmess!
@Jolymmiles

Because we have vless encryption

So by ur Logic we should stop using trains because planes are invented.

Xray is a multi protocol core And it used in a lot of apps it should support more even protocols not removing existing ones

[Jolymmiles]

Why are you insist on removing vmess!
@Jolymmiles

Because we have vless encryption

So by ur Logic we should stop using trains because planes are invented.

Xray is a multi protocol core And it used in a lot of apps it should support more even protocols not removing existing ones

Let's not go into this ridiculous and cheap sophistry. The correct comparison is two trains, where one has mechanisms that increase the safety of passengers, and the other is a decommissioned train from a first world country to a third world country, which has traveled 1,000,000 km and now the only thing it can do is deliver a passenger, without taking into account his safety.

Xray is a multi protocol core and it used in a lot of apps it should observe all modern safety precautions and remove old ones when they have a replacement.

[Jolymmiles]

那也没有因为有了 VLESS XTLS REALITY 就移除 Trojan 啊，全移除了的话我还写啥 vless-core，直接把 Xray-core 更名得了

留着其它协议主要是为了兼容性，这些协议也没占多少地方

Sounds reasonable

[RPRX]

都是啥理解能力，VLESS Encryption 目标就是成为 SS 2022/AEAD、VMess 的更好的替代品，不然写出来干嘛，为了直接过墙吗

[gfw-killer]

in compare to VMess, VLESS still lacks a selectable symmetric encryption for low-end server and clients
specially when XTLS is not supported/selected or the majority of traffic is not TLSv1.3

but it's good enough to tag vmess/ss/ss2022 as deprecated
And I am wondering why Trojan is not tagged as deprecated yet, wasted multiple valuable days of developers on debugging it's memory leak and blocked vless encryption release for days

[RPRX]

in compare to VMess, VLESS still lacks a selectable symmetric encryption for low-end server and clients

算了吧，low-end server 真的存在吗？2025 了 clients 不支持 AES 硬解的设备就别用了，ChaCha 都被我删了

[patterniha]

And I am wondering why Trojan is not tagged as deprecated yet

Trojan is suitable for when you want to use Xray-core with a personal-utility-program,
It is easier to implement in any language, it does not use mux for UDP, peers does not need to send version-byte and additional-information-length-byte, ...
I had connected MMDF to Xray-core with Trojan.
or for example, trojan is more suitable for cloudflare-edge-workers(when vless-features is not needed)

[RPRX]

@patterniha 如果只是想要一个最简单但能用（不抗 GFW）的 TLS 代理的话，VLESS 和 Trojan 没区别，VLESS 多的特性不实现就行

XUDP 也并非要求 Mux，VLESS & VMess 用的是单独实现：https://github.com/XTLS/Xray-core/blob/main/common/xudp/xudp.go

[patterniha]

@RPRX
in MMDF, i remember that this one: "peers does not need to send version-byte and additional-information-length-byte for first-response"
caused me some problems because my response-writer was controlled by Python's-built-in-tls and it was a bit troublesome to add two zero-bytes to the first response(server-hello).
Anyway, it wasn't hard, but I was too lazy to change my code-structure, so i choose trojan.

[gfw-killer]

Forget it, does the low-end server really exist? Don’t use devices with clients that don’t support AES hard solution in 2025. I have deleted all ChaCha

Yes, they really exist, specially in poor countries.
In 2025 that most chips are 3nm, Xiaomi makes Redmi A5 4G with 12nm Unisoc chipset with no AES-NI
And some Chinese guy in tg was wondering why VPS in Iran is so cheap, because their hw is bs with no AES-NI
I think it's more important than vless-relay, but it's not important for me personally
I just pointed to it as a reason that why vless加密并不成为vmess的替代品

[Jolymmiles]

Forget it, does the low-end server really exist? Don’t use devices with clients that don’t support AES hard solution in 2025. I have deleted all ChaCha

Yes, they really exist, specially in poor countries. In 2025 that most chips are 3nm, Xiaomi makes Redmi A5 4G with 12nm Unisoc chipset with no AES-NI And some Chinese guy in tg was wondering why VPS in Iran is so cheap, because their hw is bs with no AES-NI I think it's more important than vless-relay, but it's not important for me personally I just pointed to it as a reason that why vless加密并不成为vmess的替代品

I guess using this a little old servers not good idea

[gfw-killer]

I guess using this a little old servers not good idea

You are right, modern EU/US cloud servers are cheap enough to buy, and low-end domestic servers are only used as relay so the lack of AES-NI does not matter (if we don't consider Xray reverse tunnel and the minority who use them directly as a Xray node)
But for client, I think the first design that had ChaCha20 was more reasonable.

[RPRX]

But for client, I think the first design that had ChaCha20 was more reasonable.

#5067 (comment) 加回来了