VLESS Reality

VLESS Reality is the second mode that Colitu Adaptive Connect tries on Android and iOS, and one of the TCP modes ranked by connect time on Windows and Linux. It combines VLESS, a lightweight proxy protocol, with Reality, a TLS camouflage layer, and is designed for networks that use deep packet inspection (DPI).

#What it is

Both parts come from Project X (Xray), an open-source network toolkit, and its XTLS team.

• VLESS is a minimal, stateless proxy protocol. A request carries a version, the user ID (a UUID), a command and the destination address. VLESS encrypts nothing itself; it relies on the layer underneath.
• Reality is that layer: a TLS 1.3 implementation that needs no certificate of its own. During the handshake the server presents itself as a real third-party website.
• XTLS Vision is a flow mode that Colitu enables for VLESS Reality. It deals with the "TLS inside TLS" pattern explained below.

#How it works

1. Setup. The server is configured with a real website as its target, an X25519 key pair and short IDs. The app receives the public key, a short ID and the target name from the Colitu panel over an encrypted channel.
2. ClientHello. The app starts a TLS 1.3 handshake as if a browser were visiting the target site: the SNI field carries that site's name, and the TLS fingerprint imitates Chrome through the uTLS library.
3. Hidden authentication. The app derives a shared secret from its ephemeral X25519 key share and the server's public key. With it, the app encrypts a small authentication block, including the short ID and a timestamp, into the ClientHello's session ID field, which normally holds random bytes.
4. The server decides. If the block is valid, the server finishes the TLS 1.3 handshake itself with a temporary certificate bound to the shared secret, which the app can verify. If it is not valid, the server relays the connection byte for byte to the real target website.
5. Tunnel. After the handshake, VLESS requests travel inside the TLS 1.3 session using the Vision flow.

Because of step 4, anyone who connects without the key, including an active probe, talks to the real website, receives its real certificate and sees its real pages.

#XTLS Vision and "TLS inside TLS"

Most of what you do online is already HTTPS, so inside a VPN tunnel there is usually a second TLS session. Nested TLS creates recognisable patterns in packet sizes and timing, especially during the inner handshake. Vision recognises the inner TLS traffic, pads the early packets to blur that pattern, and then passes already-encrypted inner data through without encrypting it a second time. This reduces both the fingerprint and the CPU load. Vision needs a raw TCP stream, which is why Colitu uses it for VLESS Reality but not for VLESS XHTTP.

#Why Colitu uses it

Classic TLS camouflage needs the VPN's own domain and certificate, which can be listed and blocked by name, and a server that may give itself away when probed. Reality removes both weak points: there is no certificate of its own to block, and a probe sees a real site. On networks where DPI actively searches for VPN traffic, this makes VLESS Reality one of the hardest modes to tell apart from normal HTTPS.

#Where it is strong

• DPI-filtered networks: a browser-like fingerprint, a real third-party handshake and no certificate of its own.
• Networks that block UDP: it runs over TCP, so it works where Hysteria2 cannot.
• Active probing: probes are relayed to the real website.
• Stable wired and Wi-Fi connections: with little packet loss TCP performs well, and Vision keeps the overhead low.

#Limitations and when it is not the best choice

• TCP on lossy links. On mobile data or poor Wi-Fi with heavy loss it slows down like any TCP protocol; Hysteria2 is usually faster there.
• Long single connections. Some networks cut long-lived TCP connections or throttle them after a while. VLESS XHTTP exists for exactly that case.
• Mismatches can be noticed. The SNI names one website while the IP address belongs to a different network. Filters that compare the two, or that block by IP address, can still act on the connection.
• No permanent guarantee. Filtering systems evolve, and a technique that works today may be detected later. That is why Colitu keeps four other modes ready.

#How Adaptive Connect uses it

On Android and iOS, VLESS Reality comes second, right after Hysteria2: it is the first choice once UDP turns out to be blocked or unusable. On Windows and Linux it competes with the other TCP modes on measured connect time. If its handshake fails, or the tunnel carries no traffic during the check, the app moves on (on mobile to VLESS XHTTP, then Trojan and Shadowsocks 2022) and pushes the failed attempt back.

#Security and encryption

• Encryption: a TLS 1.3 handshake with X25519 key exchange; the traffic is protected with TLS 1.3 AEAD ciphers.
• Server authentication: the app only accepts the server if the handshake proves knowledge of the private key behind its Reality public key. A man in the middle without that key cannot pose as the server.
• Client authentication: two layers, the Reality authentication block (key and short ID) and the VLESS user ID, which is part of each device's own credentials.
• Key handling: keys, short IDs and the target are delivered to the app in encrypted form and never published. On Colitu servers each VLESS mode has its own Reality key pair, so the two can be rotated independently.
• No access logs: see the security page.

#Sources

• Project X (Xray) documentation
• REALITY on GitHub
• RFC 8446: TLS 1.3

#Try it

VLESS Reality is ready in every Colitu app; the app picks it when the network calls for it. Download Colitu or look through the server locations.