VLESS + Encryption instead of Shadowsocks

[Artin-GH]

Hi guys. I saw this XRAY warning the other day:

The feature Shadowsocks (with no Forward Secrecy, etc.) is deprecated, not recommended for using and might be removed. Please migrate to VLESS Encryption as soon as possible.

In Iran, our Iranian IPs get inaccessible for non-iranian IPs when the firewall finds out that the IP address is being used for a VPN server. It happens much more frequently when using RAW transportation (even with HTTP Obfuscation) compared to when using protocols like Shadowsocks, or VLESS+XHTTP or when securing using REALITY. I just wanted to ask do you think weather or not encrypted VLESS would behave similarly to Shadowsocks in this case or not, as the warning suggests using it instead?

[aminyx]

It depends on the appearance you choose, and the spec is explicit that VLESS Encryption isn't meant to face a
censor's DPI directly.

From #5067 (decryption: "mlkem768x25519plus.native|xorpub|random...."):

• native is deliberately not fully random: the handshake carries public-key material and data records
  start with a TLS 1.3-style 23 3 3 len len header.
• xorpub XORs the public key / ML-KEM ciphertext in the handshake to remove that feature.
• random also XORs the 5-byte record header, so the whole stream looks like uniform random bytes,
  i.e. the same wire image as Shadowsocks AEAD/2022.

So if RAW+SS survives where plain RAW doesn't, expect random to behave roughly like SS (same appearance), while
native/xorpub are a different fingerprint (TLS-like records without a TLS handshake), not necessarily a better one.
How Iran's firewall scores each of them nobody can tell in advance; a test on a throwaway IP will.

The deprecation warning is about cryptography, not obfuscation: SS 2022/AEAD use a static PSK, so there is no
forward secrecy, and one leaked client config decrypts the traffic of every client on that key. VLESS Encryption
fixes that (ML-KEM-768 + X25519 key exchange, forward secrecy, 0-RTT); it doesn't make traffic harder to classify.

The PR names CDN (the CDN no longer sees the UUID and the proxied SNI), relays where HTTP/TLS are blocked and
non-TLS setups as the intended uses, and says to stay with REALITY, XHTTP or Vision for direct connections. Since
VLESS+XHTTP and REALITY already hold up better for you than RAW, I'd keep that outer layer and use VLESS
Encryption as the SS replacement inside chains/relays or behind a CDN. For CDN the PR recommends
VLESS Encryption + XTLS Vision + XHTTP (XMUX) rather than WS + MUX, because MUX isn't compatible with XTLS splice.