The words VLESS, Reality, XTLS and XHTTP appear in almost every VPN setup guide, but it is rarely explained what lies behind them and why the same setup keeps working for years for some people and stops working within a week for others. In this article we will go step by step through how a provider sees your connection, which signs give a VPN away and how modern protocols remove those signs. After reading it, you will understand how our guides differ and which one to choose.
How a provider detects and blocks a VPN
To understand how modern protocols are built, we need to start with what they were designed against. A provider cannot read the contents of an encrypted connection, but it sees quite a lot around it. It knows the IP address your device connects to, the port, the transport protocol, the volume and rhythm of the data transfer, and the first bytes of every connection, which are often sent in plain text. This is the information that traffic filters rely on, such as the TSPU filtering systems used in Russia.
The crudest way to block is to ban specific IP addresses or entire subnets. It is simple, but it affects everyone hosted nearby, so it is applied selectively, for example to the addresses of well-known VPN services or to the subnets of popular hosting providers. A subtler way is to analyse the beginning of a connection. Almost every protocol opens a session with a characteristic message, and this message identifies the system as reliably as handwriting identifies a person. Finally, there are indirect signs, such as an unusual volume of traffic to a single address, an exchange rhythm that is untypical of an ordinary website, or a mismatch between the site name and the server address. On their own they prove little, but in combination they allow the system to make a decision with high confidence.
This leads to the main principle on which everything that follows is built. To keep a connection from being blocked, encrypting it is not enough. It has to be indistinguishable from connections that cannot be blocked because the ordinary internet depends on them.
Why classic VPNs have become easy to spot
OpenVPN and WireGuard were designed to protect data in untrusted networks, not to hide the very fact of connecting. Their encryption is reliable, but the handshake, that is, the exchange of service messages when a connection is being set up, has a fixed and well-documented structure. A filtering system only needs to learn to recognise this beginning once to find such connections on any server and any port. That is exactly why many providers have learned to block plain WireGuard.
The first response was protocols that change the outward appearance of well-known solutions. AmneziaWG, for example, keeps the reliable core of WireGuard but adds random junk to the handshake and changes the service headers, so the familiar handwriting disappears. This approach is described in the article about Amnezia VPN. Another response was Shadowsocks, which Outline runs on. It encrypts the connection from the first byte, and its contents look like a random stream of data. Over time, however, it turned out that a complete absence of structure is also a sign, because ordinary internet traffic almost always begins with a recognisable header. This gave rise to the idea that underlies VLESS and Reality. Instead of hiding the structure, it should be borrowed from the most widespread and untouchable kind of traffic, an ordinary website visit over HTTPS.
Xray and the VLESS protocol
Most modern anti-censorship setups run on the Xray core. It is a program that runs both on the server and inside the app on the device, and between them it carries traffic in the chosen way. The Marzban, 3X-UI and Remnawave panels do not carry any traffic themselves, they only make it convenient to manage Xray settings and hand out links to users.
VLESS is the protocol that the Xray client and server use to communicate with each other. It is extremely simple. The client sends the user identifier (UUID) and the address the data should be delivered to, and the server checks the identifier and starts forwarding. VLESS has no camouflage of its own, and this is a deliberate decision. The protection and the outward appearance of the connection are provided by an outer layer, usually TLS, and VLESS itself adds neither extra bytes nor recognisable features to it. In the latest versions of Xray, VLESS has also gained its own encryption, but together with TLS or Reality it is left off, which in the panel is the value none.
So when people say “VLESS Reality” or “VLESS + TLS + XHTTP”, they mean three independent layers. VLESS is responsible for who you are and where the data goes. The transport determines how exactly the bytes are packed during transfer. The security layer determines how the connection looks to an outside observer.
Transport and connection security
The simplest transport is called RAW, and in older versions it was called TCP. Data travels over a single long-lived TCP connection, as when an ordinary page is loading. This is the fastest option, and it is the one used together with Reality. The XHTTP transport is more complex. It splits traffic into many ordinary HTTP requests, and from the outside this resembles a website loading data through an API. In addition, such requests can in principle pass through a CDN, for example Cloudflare. In that case the provider sees a connection to the address of a CDN that millions of websites run through, while the address of your server stays hidden. In our article about VLESS + TLS + XHTTP, XHTTP works without a CDN, directly with your domain and a real certificate.
The security layer comes in two main kinds. The first is ordinary TLS with your own domain and a real Let's Encrypt certificate. The connection looks like a visit to your website, and this is honest camouflage, but it requires a domain, and the server has to respond like a real website. The second option is Reality, which the next section is devoted to.
How Reality works
Reality solves the camouflage problem without a domain or certificate of your own. Every TLS connection begins with the client's greeting (ClientHello), which states the site name in plain text in the SNI field. A Reality client puts there the name of an unrelated website that really exists, and this website is called the target. The provider sees the ordinary beginning of a connection to that website.
The difficulty is that any filtering system can check the server itself by connecting to it and seeing which certificate it presents. If a Reality server answered with its own certificate, the deception would be exposed at once. So the server acts differently. Hidden in the greeting of a genuine client is a mark computed with the server's public key and a short identifier (Short ID). The server, which holds the matching private key, recognises this mark and continues the connection as a VPN. The server transparently forwards any other connection, whether it is a check by the provider or a random scanner, to the real target website. Whoever is checking receives the genuine certificate of that website and sees its real pages, because in fact they are talking to that website, just through your server.
This scheme has a weak spot, and it is not in the cryptography. The provider sees both the site name and the IP address the connection went to. If the SNI names a large website such as microsoft.com while the address belongs to a small hosting provider, the combination looks unnatural. That is why small websites that are themselves hosted with hosting providers are chosen as targets, and the most reliable option is to imitate your own website on the same server. This setup is called self-steal, and in it the name, the address and the certificate are fully consistent with each other.
The XTLS Vision flow and the browser fingerprint
Even a perfectly disguised connection can give away the nature of the data it carries. Almost all internet traffic is already encrypted with TLS, so the connections inside a VPN tunnel are most often HTTPS. The result is “TLS inside TLS”, and the sizes of the first packets of such a connection form a recognisable sequence, because the handshake of the inner TLS has typical sizes. The XTLS Vision flow (xtls-rprx-vision) evens out these packets with padding, and once the inner handshake is complete it stops encrypting the already encrypted data a second time. The first hides the characteristic pattern, and the second reduces the CPU load and speeds up the transfer. For Reality over RAW, the Vision flow should always be enabled.
The last element is the TLS fingerprint. Each browser starts a connection in its own way, with a characteristic set of ciphers and extensions, and this set reveals which program created the connection. Xray-based apps can imitate common browsers, and the pattern to imitate is set by the fingerprint parameter, or uTLS. The choice of pattern also affects how noticeable the connection is. Why we recommend firefox rather than chrome for servers in Russia is explained in the article about Marzban.
Which setup to choose
All of these mechanisms can be put together in different ways, and our guides differ precisely in how much work you are prepared to do yourself and how much resilience you want to get.
| Task | What fits |
|---|---|
| A VPN for yourself and your family in 5 minutes, without any configuration | Marzban with our script, VLESS Reality with automatic site selection |
| A convenient panel with users, limits and subscriptions | 3X-UI |
| Several servers under one panel | Remnawave |
| Maximum camouflage, you have your own domain | Self-steal for Reality |
| Your own domain and a connection that looks like an ordinary website at work | VLESS + TLS + XHTTP |
| Everything in one app, without the command line | Amnezia VPN |
| A simple VPN with a single access key link | Outline, but it gets blocked more often |
If the connection has stopped working after all, the article “VPN on your own server does not connect” helps you find the cause. It explains step by step how to tell a blocked server from a configuration error.
Our resources
Telegram channel: https://t.me/f3cloud_news
F3 Cloud: https://f3cloud.com