REALITY: hybrid X25519MLKEM768 ClientHello gets blocked by DPI in RU, classical X25519 passes; server option to accept classical?

[da-vlasov]

Summary

From RU, on two different networks (a fixed-line home ISP and BIG4 mobile), REALITY handshakes with a hybrid X25519MLKEM768 key share are reliably blocked, usually after a short warm-up. The same server and profile with a classical X25519-only key share work fine. This happens with both a sing-box-based client and native Xray-core (v2rayN, fp=chrome).

Since XTLS/REALITY 8cdf7bf (Xray ≥ 26.9.8) the server rejects ClientHellos without X25519MLKEM768. As also noted in #6384, such a ClientHello is simply forwarded to the target. So for us, upgrading the server core means losing all clients in RU, and we pin the server at 26.7.28 for now.

Setup

• Server: Xray-core 26.7.28 (accepts both key shares), VLESS + REALITY + xtls-rprx-vision, TCP 443, NL datacenter. The target is a NL site.
• Client A: Hiddify 5.5.1 (sing-box fork). Its key_share option switches between hybrid (default since 5.1.0) and classical.
• Client B: v2rayN with Xray-core 26.10.31, fp=chrome. This is a native Xray / uTLS Chrome ClientHello, hybrid by default.

A/B test (client A)

Same client, server and network; only the key share differs. 100 requests through the local proxy, each a new outbound connection, so a new REALITY handshake each time:

Key share	OK	Failed
classical	98/100	2 (5 s, recovered immediately)
hybrid	16/52	36 (all 15 s handshake timeouts)

With hybrid, the first ~12 handshakes succeed. After that almost every new connection fails. The state lasts more than 10 minutes and survives client restarts. Switching to classical from the same client IP to the same server works instantly. The same behaviour was reproduced on MTS mobile (a different operator), which points at shared DPI rather than one ISP.

Packet capture on the server

• Classical: the ClientHello is 530–594 bytes in a single segment, and the handshake completes.
• Hybrid: the ClientHello is about 1.8 KB and is split by TCP (client MSS 1360). While the block is active, the server gets the SYN, the ACK and the first 1360-byte segment, and ACKs it, but the rest of the ClientHello never arrives. The handshake never starts. After that the flow is dead in both directions: the server's FIN retransmissions to earlier stuck flows are not answered.

Native Xray client (client B)

To rule out a client-specific ClientHello, I repeated the test with v2rayN (Xray-core 26.10.31, fp=chrome, same link, same network):

• tcpdump on the server: the ClientHello is split the same way, first segment 1360 bytes without PSH, i.e. the hybrid X25519MLKEM768 key share.
• Same A/B method: 3 of 100 requests succeeded, 96 were 15 s handshake timeouts and 1 failed after 0.85 s. There was no warm-up this time: failures started with the first request, probably because the block from earlier hybrid tests on this client-IP → server path was still active.
• Right after that, the classical profile (client A) on the same machine connected instantly.

So the blocking is not specific to the sing-box/Hiddify ClientHello: the genuine uTLS Chrome hybrid ClientHello from Xray-core is affected the same way, while the classical one passes on the same path at the same time.

Questions

1. Is this known? Are there other reports of hybrid-key-share REALITY being singled out while classical passes?
2. Would you consider a server-side opt-in (per inbound) to accept an X25519-only ClientHello again, for regions where the hybrid one is blocked? We understand that classical looks "outdated" next to current Chrome, but right now it is the only one that passes here.
3. If not, what do you recommend to carry the hybrid ClientHello through this kind of DPI (ClientHello fragmentation, XHTTP, something else)?

[RPRX]

#7208 (comment)

The PR is #7135

[da-vlasov]

Thanks for the pointer! So the target is the Chrome 133 fingerprint rather than the hybrid key share as such. That matches our data: Xray 10.26.31 with fp=chrome (Chrome 133) was blocked the same way as Hiddify's hybrid ClientHello, while the classical one passed.