VPN and proxy protocols in 2026: VLESS, Hysteria2, NaiveProxy, WireGuard, AnyTLS and the rest

How a connection is built: five layers

Confusion in articles about protocols starts with mixing up the layers. "VLESS", "Reality", "XHTTP" and "Xray" sit at different levels of the same construction.

For example: VLESS + XHTTP + REALITY means the VLESS protocol, the XHTTP transport and REALITY as the security layer. It runs inside the Xray-core engine, launched from Happ or INCY.

How DPI recognises protocols

"Protocol resistance" means resistance to particular methods of analysis. There are five of them.

• Signatures. Fixed bytes and lengths in the first packets. This is how OpenVPN, WireGuard, PPTP and L2TP are identified.
• Entropy. A stream of random bytes with no recognisable structure is suspicious in itself. This is how classic Shadowsocks and VMess are spotted.
• Active probing. The observer connects to the server itself and checks the response. A server that stays silent or answers oddly gives itself away.
• TLS fingerprint (JA3/JA4). The set of ciphers and extensions in the first TLS message. The Go library looks nothing like Chrome. The uTLS library is used to forge the fingerprint.
• Behaviour. Packet sizes, their rhythm, the ratio of inbound to outbound traffic, the number of parallel connections to one server. A study at USENIX Security 2024 showed that when an application inside the tunnel opens its own TLS connection, a characteristic burst of packets is visible in the outer encrypted stream. The authors reported true positive rates above 70% against Shadowsocks, VMess, VLESS, Trojan, obfs4 and REALITY in their default settings. The problem is known as TLS-in-TLS.

Since 2026 the emphasis has moved to behavioural analysis. On some networks a VLESS+Reality connection over bare TCP stalls after roughly the first 16 KB of data, while SSH to the same server keeps working. The client shows "connected" and no data moves.

Summary table

DPI resistance is assessed as of September 2026. The picture differs between providers and shifts every few months.

1. Classic VPN protocols

PPTP and L2TP/IPsec

Obsolete protocols built into older Windows, Android and routers.

• PPTP. MPPE encryption is broken. Not fit for protecting traffic.
• L2TP/IPsec. Double encapsulation, UDP 500, 1701, 4500. Slow, recognisable by its ports.
• Where they fit: old corporate networks. Not for personal use.

OpenVPN

Running since 2001 in user space, over TCP or UDP, with encryption through OpenSSL.

• Pros: supported everywhere, flexible configuration, works over TCP 443.
• Cons: slower than WireGuard, a heavy codebase, a handshake recognisable by signature. Wrappers such as obfsproxy and Cloak hide the signature at the cost of speed.
• Key: an .ovpn file with certificates.

IKEv2/IPsec

Built into iOS, macOS and Windows with no third-party app. The MOBIKE extension switches network without dropping the connection.

• Pros: works without installing anything, reconnects quickly on a phone.
• Cons: fixed UDP ports 500 and 4500, recognised immediately.

WireGuard

Written by Jason Donenfeld. In the Linux kernel since 5.6 (2020). About 4,000 lines of code.

How it works. Client and server each hold a Curve25519 key pair. The Noise IKpsk2 handshake takes a single packet exchange. Data is encrypted with ChaCha20-Poly1305. The server identifies the client by public key; there are no logins.

• Pros: minimal latency, runs in the OS kernel, low battery drain, survives a change of network.
• Cons: UDP only. Handshake packets have constant lengths — 148 bytes for the initiation and 92 for the response — and the rehandshake happens strictly every 120 seconds. Those traits identify the protocol in a fraction of a second.
• Where it fits: a home network with no filtering, server-to-server links, routers.
• Key: a .conf file with [Interface] and [Peer] sections, or a QR code.

AmneziaWG

A WireGuard fork from the Amnezia team. The cryptography of WireGuard is unchanged; what changes is how the packets look.

The I1–I5 packets in version 2.0 disguise the start of a connection as DNS, QUIC, SIP or any other UDP protocol. In version 3.0 the packet headers, which in WireGuard and AWG 2.0 travelled in the clear and predictably, are encrypted with the ChaCha20 stream cipher. Handshake and keepalive intervals are set as ranges rather than constants.

• Pros: WireGuard's speed, UDP traffic without the WireGuard signature.
• Cons: UDP only. A new protocol version removes the signature but does nothing about the server's IP address being blocked. AmneziaWG 3.0 is incompatible with 2.0 when header protection is on.
• Key: a vpn:// link for the AmneziaVPN app, or a .conf file with obfuscation parameters.

2. The Shadowsocks family

Shadowsocks (AEAD)

Appeared in 2012. A proxy without TLS: the whole stream is encrypted with AEAD (ChaCha20-Poly1305 or AES-GCM) and looks like random bytes. Outline is built on it.

• Pros: simplicity, low overhead, support in every client.
• Cons: a structureless, high-entropy stream is identified statistically. Older versions are vulnerable to replay attacks.
• Key: ss://method:password@server:port, often in base64.

Shadowsocks 2022

An updated scheme: BLAKE3 keys, mandatory replay protection, less overhead.

• Pros: the lowest latency among proxy protocols, good for UDP and routers.
• Cons: it looks the same from outside — random bytes. Used together with ShadowTLS, or as an internal channel between your own servers.

ShadowTLS v3

A wrapper for another protocol, usually Shadowsocks. The server forwards the TLS handshake to a real site, the client receives a genuine certificate, and after the handshake the stream is swapped for the proxy. No domain or certificate of your own is needed.

• Pros: a real site's handshake, works on top of any protocol.
• Cons: in June 2025 the Aparecium tool demonstrated two reproducible ways to identify ShadowTLS v3: a fixed difference in the length of the ServerFinished message, and incorrect handling of NewSessionTicket from OpenSSL-based servers.
• Where it fits: a fallback on top of Shadowsocks 2022.

Mieru

A proxy without TLS. XChaCha20-Poly1305 encryption keys are derived from the username, the password and system time; packets get random padding and replays are rejected. No domain or cover site is required.

• Pros: works over TCP and UDP, configurable traffic shape.
• Cons: from outside it is the same stream of random bytes as Shadowsocks. Requires accurate time on client and server.

Sudoku

An experimental 2025 protocol with the opposite idea: not random noise but a low-entropy stream. Data is encoded into solvable 4×4 sudoku puzzles, so the stream looks like ASCII text. Supported in mihomo and as an obfuscation layer in Xray.

3. The V2Ray and Xray family

The V2Ray project appeared in 2015. Its fork, Xray-core, has been maintained by the RPRX team since 2020. Most commercial services in Russia run on Xray: the VLESS protocol, the Happ, INCY, v2rayN, v2rayNG and Streisand clients, the 3x-ui and Remnawave panels.

VMess

The first V2Ray protocol. It encrypts data itself and authorises by UUID and time.

• Cons: requires the clocks of client and server to be in sync (a drift over 90 seconds breaks the connection), double encryption on top of TLS, a recognisable stream without TLS. Obsolete.
• Key: vmess:// plus a base64 string containing JSON.

Trojan

A 2019 protocol. The client sends a hash of the password inside an ordinary TLS connection. Get the password wrong and the server serves a preconfigured real site, so a prober sees a normal web page.

• Pros: simplicity, a real HTTPS server.
• Cons: a domain and a certificate are required. According to the same USENIX Security 2024 work, passive TLS-in-TLS detection of Trojan exceeds 70%.
• Key: trojan://password@domain:443?sni=domain#Name

VLESS

A lightweight Xray protocol from 2020. It does not encrypt anything itself: it identifies the client by UUID and passes the destination address. Encryption and appearance come from the layer beneath it.

Security layers for VLESS

TLS. An ordinary certificate on your own domain. Compatible with a CDN.

XTLS Vision (flow=xtls-rprx-vision). When the tunnel carries HTTPS inside, Vision stops encrypting it a second time and pads the handshake packets instead. CPU load drops and the TLS-in-TLS pattern is blurred. Works only with the RAW (TCP) transport.

REALITY (2023). The server needs neither a domain nor a certificate of its own. It forwards the start of the handshake to a real site, receives a genuine response and certificate, and embeds a marker based on X25519 keys into the stream. A client holding the key sees the marker and opens the tunnel; everyone else gets the genuine site. Active probing finds nothing. Since March 2026 Xray warns when Apple or iCloud is chosen as the cover site, and when running on a port other than 443: those settings led quickly to the IP being blocked.

VLESS Encryption (2025). VLESS's own encryption with a post-quantum ML-KEM-768 key exchange paired with X25519. It is needed where TLS terminates at a CDN: without it the CDN sees the VLESS header, the UUID and the destination addresses in the clear. The random mode makes the stream resemble random bytes.

ECH (Encrypted Client Hello). Encrypts the site name at the start of a TLS connection. Works through CDNs that support ECH.

Transports for VLESS

XHTTP (formerly SplitHTTP, 2024) is Xray's main transport for difficult networks. It breaks the connection into ordinary HTTP requests, with packet-up, stream-up and stream-one modes. Uploads go as short POST requests with random padding, downloads as one long response, and there is no persistent bidirectional stream. From outside it resembles calls to a web API, and the transport is compatible with nginx and CDNs. Since March 2026 XHTTP over HTTP/3 uses BBR congestion control by default; Brutal mode is enabled separately.

Finalmask (2026) is an Xray obfuscation layer that sits on top of any transport. It adds its own headers for TCP and UDP, Sudoku, TCP fragmentation and noise UDP packets. The XDNS and XICMP tunnels hide traffic inside packets that resemble DNS and ICMP. XDNS is slow and meant for messengers when the network is almost entirely down.

• VLESS pros: flexibility, a huge ecosystem, CDN support, active development.
• VLESS cons: dozens of parameters, and one mistake breaks the connection. REALITY over bare TCP is vulnerable to behavioural analysis.
• Key: vless://UUID@server:443?type=...&security=...#Name (parameters explained below).

4. Protocols over HTTP/2 and HTTP/3

NaiveProxy

Written by klzgrad. Instead of imitating a browser it uses the real Chromium network stack, so the traffic repeats the exchange between an ordinary Chrome and a standard web server.

How it works. Streams travel through CONNECT tunnels in HTTP/2 or HTTP/3. The server is Caddy with the forwardproxy module, or HAProxy. Protection against analysis, layer by layer:

• The TLS fingerprint matches Chrome, because it is Chrome's code.
• Active probing is absorbed by the frontend: without the correct authorisation header the server behaves like an ordinary site.
• The first 8 reads and writes of each stream are padded by 0 to 255 bytes, smoothing out the size spikes typical of handshakes.

• Pros: one of the best disguises of any protocol, HTTP/2 multiplexing.
• Cons: a domain, a certificate and Caddy are required. The client has to be kept on the latest version, otherwise the fingerprint stops matching current Chrome. Mobile client support is limited: Android clients built on sing-box (NekoBox, husi, Exclave), Shadowrocket.
• Key: naive+https://login:password@domain:443

TrustTunnel

AdGuard VPN's protocol. The source was opened in January 2026 under Apache 2.0. TLS encryption, HTTP/2 or HTTP/3 transport. It tunnels TCP, UDP and ICMP, and each connection gets its own HTTP/2 or HTTP/3 stream.

• Pros: standard HTTP traffic, years of service inside AdGuard products, an open specification.
• Cons: a young ecosystem of third-party clients, few independent measurements of its resistance.

MASQUE

An IETF standard for tunnels over HTTP/3: CONNECT-UDP (RFC 9298, 2022) and CONNECT-IP (RFC 9484, 2023). Apple's iCloud Private Relay and Cloudflare WARP run on it.

• Pros: standardised, and the traffic is ordinary HTTP/3.
• Cons: UDP/QUIC only, few open server implementations.

5. AnyTLS

A 2025 protocol from the sing-box ecosystem. It solves one problem: hiding the TLS-in-TLS pattern.

How it works. After the TLS handshake the client sends SHA-256 of the password and a block of padding. On a wrong password the server closes the connection or serves an ordinary HTTP service. Data then travels in frames, with junk inserted between them according to a padding scheme. The default scheme: a first packet of 30 bytes, then 100–400 bytes, then chains of 400–1000 bytes. The server sends the client a new scheme whenever the client's scheme hash does not match the server's. The operator changes the padding scheme on the server and every client picks it up by itself.

• Pros: configurable padding, combines with REALITY, simple to set up.
• Cons: the youngest of the widely used protocols, with the least independent data on its resistance. No support in Xray, Happ or INCY.
• Where it runs: sing-box, mihomo, Shadowrocket, Hiddify, NekoBox.

6. QUIC-based protocols

QUIC is the HTTP/3 transport over UDP with TLS 1.3 built in. Losing one packet does not hold up the other streams, and the connection survives a change of network.

Hysteria (v1) and Hysteria2

Written by the apernet team. The first version, from 2020, used its own format; Hysteria2 (2023) was rewritten as a layer on top of HTTP/3.

How it works. The client authorises with a POST request to /auth; an unauthorised request gets a genuine HTTP/3 response. The masquerade mode serves a site or proxies someone else's.

Brutal. A congestion control algorithm. TCP algorithms cut speed when packets are lost; Brutal holds the configured rate and compensates for losses by retransmitting. On mobile internet and congested Wi-Fi that delivers speed no TCP-based protocol can reach.

Salamander. Every QUIC packet is XORed with a key stream from BLAKE2b-256 over a random salt and the shared key. The QUIC structure disappears from the header, though packet sizes and timings remain.

Port hopping. The UDP port changes during the session.

Since March 2026 Hysteria2 is also supported in Xray-core: server, transport and obfuscation through Finalmask.

• Pros: the highest speed on lossy channels, disguise as HTTP/3, 4K video and large downloads.
• Cons: UDP only. Some providers throttle UDP on port 443 or slow QUIC down entirely. Brutal claims the channel aggressively. The client states its own bandwidth by hand.
• Key: hysteria2://password@server:443?sni=...&obfs=salamander&obfs-password=...#Name (short form hy2://).

TUIC v5

A QUIC protocol aiming at minimal latency. It supports TCP and UDP with zero round-trip time for the extra handshake (0-RTT), Full Cone NAT for UDP, and two UDP delivery modes: native and over QUIC streams. The protocol is specified separately from its implementations; servers include tuic-server, sing-box and mihomo.

• Pros: fast connection setup, gentle congestion control (BBR), easy on the battery.
• Cons: no disguise as a website the way Hysteria2 has. Depends on UDP.
• Key: tuic://UUID:password@server:443?congestion_control=bbr&alpn=h3#Name

Juicity

A QUIC protocol inspired by TUIC, focused on stability and better UDP delivery. In TUIC, native mode produces frequent application-level retransmits when packets are lost, while quic mode sends every UDP datagram as its own stream and wastes resources. Juicity addresses both.

• Pros: stable UDP (games, calls), a simple protocol.
• Cons: a small ecosystem: dae, v2rayA, mihomo, Stash.
• Key: juicity://UUID:password@server:port?congestion_control=bbr

7. Transports from the Tor project

A separate ecosystem, used by the Tor browser.

• obfs4 (2014). A stream of random bytes with protection against probing. Identified by entropy.
• meek. Traffic through large CDNs. Slow.
• Snowflake. Traffic through WebRTC connections with volunteers' browsers.
• WebTunnel (2024). Disguised as an ordinary WebSocket on an HTTPS site.

Cores and clients

Happ supports VLESS, VMess, Shadowsocks, SOCKS5, Trojan and Hysteria2. WireGuard, AmneziaWG, TUIC, AnyTLS and NaiveProxy cannot be imported into Happ.

Keys, links and subscriptions

A key is a string holding every connection parameter. The start of the string shows the protocol:

A VLESS key, taken apart:

vless://1f0e3c5a-0000-0000-0000-000000000000@example.com:443
?type=xhttp&security=reality&pbk=PUBLIC_KEY&sid=ab12cd
&sni=example.org&fp=chrome&path=/api&mode=packet-up#Name

A subscription is a link to a list of keys. The client downloads the list itself and refreshes it on a schedule. When a server changes, the app pulls the new list and the user does nothing.

Which protocol to choose

No single protocol covers every case. Services keep several routes on different transports inside one subscription, and the client moves between them.

What MaskNet uses

MaskNet is built on VLESS and the Xray-core engine. A subscription holds several routes, and the Happ and INCY clients read it themselves. There is no protocol to choose, no port to type and no key to copy: a button in your account opens the app with the subscription already added, and on a phone a QR code adds it.

Russian sites and apps go direct. Banks, government services and marketplaces work without turning MaskNet off.

Frequently asked questions