VLESS and Reality explained: how Xray looks like HTTPS

VLESS is a lightweight proxy protocol from the Xray project that authenticates a client by a UUID and carries its traffic; it does no encryption of its own and relies on the layer underneath. Reality is that layer: a modified TLS 1.3 that makes the connection look, to anyone watching, like a visit to a real and well-known website - and if someone without the key connects to the server to check, they are passed through to that real website and see its genuine certificate. XTLS Vision, the usual "flow" setting, removes the statistical tell-tales of running TLS inside TLS. Together they produce a tunnel that networks blocking VPNs by their shape have nothing obvious to recognise. This post explains each piece, how Reality authenticates without a certificate of its own, what every field of a vless:// link means, and where the disguise stops - because no protocol is undetectable, and claims otherwise are worth distrusting.

Xray and where VLESS comes from#

Xray-core is an open-source proxy platform maintained by Project X (the XTLS organisation on GitHub). It began in 2020 as a fork of V2Ray, the platform behind the older VMess protocol, and has since become the main home of new work in this family. A single Xray process can speak several protocols - VLESS, VMess, Trojan, Shadowsocks - over several transports, with routing rules deciding what goes where.

The pieces of an Xray connection stack up in layers, and most confusion comes from mixing them:

A "VLESS + Reality" server is therefore the VLESS protocol, usually with the Vision flow, over the raw transport, secured by Reality. Each is a separate setting in the configuration and a separate parameter in the share link.

VLESS: deliberately minimal#

VMess, VLESS's predecessor, encrypted its own traffic and used time-based authentication, which made it heavier and sensitive to clock drift. VLESS dropped all of that. A VLESS request header carries a version, the client's UUID, an optional addon block (where the flow is named), a command, and the destination address and port. That is all.

The UUID is the credential: the server keeps a list of client IDs and drops anything that does not match. Because VLESS itself does not encrypt, the configuration says so explicitly - "decryption": "none" on the server, encryption=none in the link - and the confidentiality comes entirely from the security layer underneath. Running VLESS with security: none over the internet would send everything in readable form; nobody should do that outside a test.

The benefit of the minimalism is speed and simplicity. With encryption done once, by TLS or Reality, there is no double work, and the protocol has very little that can be fingerprinted on its own.

The detection problem: fingerprints and TLS in TLS#

Wrapping a proxy in TLS - the approach of Trojan and of VLESS over ordinary TLS - makes it look like HTTPS. It turned out that is not quite enough, for three reasons.

The ClientHello has a fingerprint. The first message of every TLS connection lists cipher suites, extensions and their order. Browsers produce distinctive, well-known lists; Go's standard TLS library, which Xray is written in, produces a different one. A network that sees "this looks like Go, not Chrome" on port 443 has a clue. Xray clients therefore use uTLS to imitate a browser's ClientHello exactly, chosen with the fingerprint setting (chrome is the common choice).

The certificate has to come from somewhere. Classic TLS proxying needs a domain you own and a certificate for it. The domain is a fixed identifier that can be listed, and a server that presents a certificate for an obscure domain on a hosting provider's IP fits a recognisable pattern.

TLS inside TLS has a shape. When you browse an HTTPS site through a TLS-wrapped proxy, there are two TLS handshakes, one inside the other. The inner handshake produces a burst of packets with characteristic sizes and timing, visible through the outer encryption as lengths and gaps. Researchers have shown that this pattern can be detected statistically.

XTLS Vision, set with flow: xtls-rprx-vision, addresses the third problem. It pads the packets of the inner handshake so their sizes stop matching the known pattern, and once the inner TLS connection is established it stops encrypting the already-encrypted data a second time and passes it through directly. The result is less to recognise and less CPU spent. Vision works with the raw transport only.

Reality addresses the first two.

How Reality works#

Reality removes the need for your own domain and certificate by borrowing someone else's handshake. The server is configured with a target - a real website such as a large company's homepage - and the list of server names (SNI values) it will accept, all of which must be names that target actually serves.

When a connection arrives:

1. The client sends a TLS 1.3 ClientHello that looks exactly like a browser's, with the target's name as the SNI. Hidden inside fields that are random in normal TLS - the session ID, combined with the key exchange - is authentication data derived from the server's x25519 public key and a short ID.
2. The server, which holds the matching private key, tries to verify that data. If it checks out, the server completes the handshake itself, presenting a temporary certificate that the client can verify using the shared secret, and the VLESS tunnel runs inside.
3. If it does not check out - a browser, a scanner, a censor's active probe - the server does not answer as itself at all. It forwards the connection, untouched, to the real target. The visitor completes a real TLS handshake with the real website and gets its genuine certificate and content.

The third step is what defeats active probing. A system that suspects a server and connects to test it receives a perfectly normal copy of a famous website. There is no fake page and no self-signed certificate to spot.

The key pair is x25519. The server keeps the private key; the client gets the public one. Current Xray documentation calls the client-side field password rather than publicKey, and the server field target rather than dest; the old names still work as aliases, which is why guides use both.

A minimal server configuration#

On a server you run yourself, the setup is three generated values and one JSON file. The xray binary generates them:

$ xray uuid                        # client ID$ xray x25519                      # server key pair; keep the private key secret$ xray x25519 -i "<private key>"   # prints the public key again from the private one$ openssl rand -hex 8              # a short ID: hex, even length, up to 16 chars

{  "inbounds": [{    "listen": "0.0.0.0",    "port": 443,    "protocol": "vless",    "settings": {      "clients": [{ "id": "<uuid>", "flow": "xtls-rprx-vision" }],      "decryption": "none"    },    "streamSettings": {      "network": "raw",      "security": "reality",      "realitySettings": {        "target": "www.example.com:443",        "serverNames": ["www.example.com"],        "privateKey": "<private key>",        "shortIds": ["<short id>"]      }    }  }],  "outbounds": [{ "protocol": "freedom" }]}

network: "raw" is the current name of what older versions called tcp; on an older Xray, use tcp. The freedom outbound sends unwrapped traffic straight to its destination. A production configuration usually adds routing rules and a blackhole outbound to refuse traffic you do not want - connections to private address ranges, for one, so the server cannot be used to reach its own internal network.

One ID per device

The clients array can hold any number of entries, each with its own UUID, and shortIds can hold several values. On a server you manage yourself, giving each device or each person its own UUID is worth the small extra effort. When a phone is lost or a friend no longer needs access, you delete that one entry and restart Xray; every other device keeps working with the link it already has. With one shared UUID, revoking anyone means issuing a new link to everyone. Add an email field to each client entry - it is only a label, not an address that is ever contacted - and Xray's logs and statistics can then tell you which device a connection belongs to. Short IDs work the same way at the Reality layer, and an empty string in the list allows clients that send no short ID at all, which is convenient for testing and best removed afterwards.

A managed private VPN does this part for you. On RE:NODE, the server runs Xray with VLESS and Reality, generates the address and key for your server, and prints a link you paste into a client - the Renode VPN app on Windows, or any VLESS client on phones and Macs.

Anatomy of a vless:// link#

Clients exchange configurations as a single URI. Every parameter maps to a setting described above:

vless://3f1c8a2e-...-9b7d@203.0.113.10:443  ?encryption=none  &flow=xtls-rprx-vision  &security=reality  &sni=www.example.com  &fp=chrome  &pbk=Zx9...publickey  &sid=6ba85179e30d4fc2  &type=tcp  #my-server

The link carries the credential and everything else needed to connect. Anyone who has it can use your server, so share it like a password, not in a group chat. VLESS client setup covers importing it into v2rayNG, Hiddify, Streisand and Shadowrocket.

Choosing a target#

On a self-built server, the target is the one creative decision, and it matters more than it looks. The REALITY project's guidance and common practice point to a site that:

• Supports TLS 1.3 and HTTP/2, because the client's ClientHello must look like a modern browser visiting a modern site.
• Does not redirect its main name to another domain, so the handshake completes normally.
• Is plausible from your server's network - a large site hosted outside your country, ideally with servers in the same region as yours, so that connections to it from that IP range are not odd.
• Is not behind a CDN that would let your server be used as a forwarder. Xray's documentation warns that because failed authentications are forwarded to the target, a CDN-fronted target can turn your server into a relay for other people's traffic; the limitFallbackUpload and limitFallbackDownload settings cap that.

xray tls ping www.example.com checks a candidate's TLS support from the server itself.

The limits of the disguise#

Reality is the most convincing approach in widespread use, and it is still not invisible. Honest limits:

• The SNI and the IP do not match. The handshake names a famous website; the IP belongs to a hosting provider, not that website. An observer that compares the two - by resolving the name, or using lists of who owns which ranges - can notice. Choosing a target in the same region and hosting space narrows the gap; nothing closes it fully.
• Traffic patterns remain. One long-lived connection carrying hours of mixed traffic to "a homepage" is unusual. Vision reduces the TLS-in-TLS pattern; volume and timing analysis is a broader problem no proxy fully solves.
• IPs can be blocked without being identified. A network can block an address for any reason, including that many unknown connections go to it.
• It is not anonymity. The server is yours and rented in your name. Reality hides what the tunnel is from the network in between; it hides nothing from the sites you visit, which see your server's address, or from accounts you log into.

VPN use is legal in most places and restricted in some. Know the law where you are, and the acceptable-use rules of networks you do not own; a protocol that is hard to detect does not change what is permitted. What a VPN protects and what it does not and Xray vs WireGuard vs OpenVPN put this in context.

When it does not connect#

The third row is Reality working as designed: a client that fails authentication is treated like any stranger and handed the real site. If you see the target's page, re-import the link rather than editing fields by hand. For the clock case, servers can set maxTimeDiff to reject clients whose time is too far off; a phone with automatic time disabled can fall foul of it. Why is my VPN slow covers the case where it connects but crawls.

FAQ#

Is VLESS encrypted?

VLESS itself adds no encryption, by design. The encryption comes from the security layer - TLS or Reality - which is why a VLESS link says encryption=none and security=reality. With Reality, the traffic is protected by TLS 1.3 key exchange and encryption.

Do I need a domain for Reality?

No. That is one of its main advantages. The server borrows the TLS handshake of the target site, so you need no domain and no certificate of your own. Clients connect to the server's IP address with the target's name as the SNI.

What is the difference between Reality and ordinary TLS?

Ordinary TLS presents your own certificate for your own domain. Reality presents a borrowed identity, authenticates clients with a hidden key exchange, and forwards everyone else to the real site, so probing the server reveals nothing unusual.

Which clients support VLESS with Reality?

Clients built on Xray-core or sing-box with Reality support: v2rayNG on Android, Hiddify on several platforms, Streisand and Shadowrocket on iPhone and Mac, among others. Keep the client updated; older cores predate Reality.

Can a network still block it?

Yes. It can block the server's IP address, or flag unusual patterns, without understanding the protocol. Reality makes recognising the tunnel by its shape very hard; it does not make blocking impossible.