What is VLESS? A protocol built for censorship resistance

VLESS is a proxy protocol. It moves your traffic from point A to point B through an encrypted tunnel, similar to what WireGuard or OpenVPN does. The difference is in what VLESS does not do: it does not encrypt your traffic itself. It hands that job to TLS and gets out of the way.

That design choice, made by a developer known as RPRX in 2020, turns out to matter a lot if you're trying to use the internet in China, Russia, or Iran.

The VMess problem

To understand VLESS, you need to understand what came before it. VMess was the original protocol in V2Ray, a proxy platform that became popular in the Chinese anti-censorship community around 2018. VMess worked, but it had a design problem that became increasingly painful over time.

VMess encrypts your payload with its own encryption layer. That's fine in theory. But you're also running this inside a TLS connection, because sending unencrypted VMess traffic over the internet would be immediately flagged by any DPI system. So the actual data flow looks like this:

VMess:  [TLS encryption [VMess encryption [your actual data]]]

You're encrypting everything twice. The VMess layer is redundant because TLS already provides confidentiality, integrity, and authentication. You're paying a performance cost for zero security benefit.

VLESS strips out that inner encryption:

VLESS:  [TLS encryption [VLESS header [your actual data]]]

The VLESS header is tiny, around 25 to 50 bytes depending on the address type. Compare that to OpenVPN, which adds 100+ bytes of overhead per packet. VLESS trusts TLS to do the encryption (which it's very good at) and limits itself to routing information: where the traffic should go, and a UUID to identify the client.

The name reflects this directly. VLESS stands for "VMess Less." Less overhead, less complexity.

How VLESS works at the protocol level

A VLESS connection follows a straightforward flow. There's no multi-round handshake, no key exchange dance. The protocol assumes TLS has already handled all of that by the time VLESS traffic starts flowing.

Here's what happens when you connect:

The client opens a TLS connection to the server. This is a standard TLS 1.3 handshake, identical to what your browser does when you visit any HTTPS website. Nothing about it identifies it as VPN traffic.

Once TLS is established, the client sends the VLESS request header:

Version (1 byte)  |  UUID (16 bytes)  |  Addons Length  |  Command  |  Address

The version byte is always 0 in the current spec. The UUID is your authentication token, a shared secret between client and server. The command is usually 0x01 for TCP proxy or 0x02 for UDP. Then comes the destination address, which tells the server where to forward your traffic.

The server validates the UUID, connects to the requested destination, and starts proxying data. There is no response header in the success case. Data just starts flowing. This is intentional: fewer bytes on the wire means less to fingerprint.

One thing that surprises people coming from traditional VPN protocols: VLESS has no built-in encryption, no integrity checks on its own header, no replay protection at the VLESS layer. All of that is handled by TLS. If you somehow ran VLESS without TLS (don't), your UUID would be transmitted in plaintext and anyone could hijack the session. The protocol only makes sense inside a TLS tunnel.

The XRay fork and where VLESS lives

VLESS was created by RPRX, who also developed the XTLS technology that makes Reality possible. In November 2020, RPRX forked V2Ray to create XRay-core after a licensing dispute over XTLS. The V2Ray maintainers had concerns about the XTLS license; RPRX wanted to move faster and ship XTLS under terms he controlled. So XRay became its own project.

The fork wasn't hostile exactly, but it split the community. V2Ray continued development separately, eventually adding its own VLESS implementation. XRay moved faster on protocol innovation. Today, when people talk about VLESS in practice, they almost always mean the XRay implementation.

XRay-core has over 35,900 stars on GitHub and 208 contributors. It's one of the most actively maintained anti-censorship tools in the world, though almost all development and discussion happens in Chinese. The English documentation exists but it's often incomplete or outdated. If you want to understand what a particular XRay feature actually does, you usually end up reading the Go source code. We've spent a lot of time reading that source code.

There's no RFC for VLESS, no IETF standardization process, no formal specification document. The protocol is defined by its implementation. This bothers some people, particularly those with a background in protocol design where a spec comes first and implementations follow. It doesn't bother the users in Shanghai who need it to work tomorrow.

Reality: the extension that changes everything

VLESS on its own is a clean, minimal proxy protocol. VLESS with Reality is something else entirely.

Reality was introduced in XRay-core v1.8.0 in early 2023, and it solved a problem that had plagued every previous anti-censorship tool: the server's TLS certificate.

With traditional TLS proxies, your server needs a certificate. You can get one from Let's Encrypt, but now the domain is registered to you. A censor can scan all IP addresses, find servers with certain certificate characteristics, and block them. Worse, they can perform active probing: connect to your server, check the certificate, and if it doesn't match a real website, flag the IP.

Reality flips this around. Your server doesn't have its own certificate. Instead, it borrows the TLS certificate from a real website, like www.microsoft.com. When a censor probes your server, they get a legitimate Microsoft certificate and real Microsoft content. Only clients with the correct Reality private key can establish the actual proxy tunnel.

We wrote a detailed breakdown of how Reality's TLS authentication works in our Reality deep dive. The short version: it's the closest thing to undetectable that exists in production today.

Where VLESS is actually used

VLESS is popular in exactly the places you'd expect: countries where the government actively blocks VPN traffic.

China has the longest history with the V2Ray/XRay ecosystem. The Great Firewall team and the anti-censorship community have been in an arms race for years. VMess, Shadowsocks, Trojan, and various other protocols have all been detected and blocked at different times. VLESS with Reality is the current state of the art on the anti-censorship side. It works. For now.

Russia escalated aggressively in 2025. By February 2026, Russia had blocked 469 VPN services. In December 2025, Roskomnadzor began targeting VLESS specifically, which tells you something about how effective it had become. The Russian DPI system (TSPU) is sophisticated, but Reality's design makes detection extremely difficult without blocking all TLS traffic to major websites, which would break half the internet.

Iran blocks VPN traffic during political unrest, which is frequently. VLESS Reality has been one of the more reliable ways to maintain connectivity during internet shutdowns, though Iran's filtering infrastructure is less technically advanced than China's or Russia's.

The pattern across all three countries is the same: traditional VPN protocols get detected within minutes or hours, while VLESS with Reality continues to work because censors can't distinguish it from regular HTTPS traffic without breaking legitimate websites.

Most VLESS users are individuals running their own servers. You rent a VPS outside the country, install XRay, configure VLESS with Reality, and share the connection details with people who need it. This grassroots model is how millions of people in censored countries access the open internet.

Why NordVPN doesn't offer VLESS

Here's an honest question: if VLESS is so effective, why don't the major VPN providers use it?

None of them do. Not NordVPN, not ExpressVPN, not Surfshark, not ProtonVPN. A couple of small providers (Trust.Zone, Octohide) have added VLESS support, but they're niche.

There are real reasons for this, not just ignorance.

The XRay ecosystem is almost entirely documented in Chinese. The codebase is in Go, well-structured but with Chinese comments and design decisions that reflect the Chinese censorship context specifically. Integrating XRay into a commercial VPN product requires someone who deeply understands both the XRay internals and production VPN architecture. That's a small overlap in the industry.

There's also a business calculus. NordVPN's customers are mostly in Western countries where WireGuard works fine. Investing engineering time in VLESS serves a market segment (users in censored countries) that's harder to monetize and carries regulatory risk. From a pure business perspective, it makes sense to skip it.

And then there's the integration complexity. VLESS with Reality isn't a drop-in replacement for WireGuard. It requires a TUN interface, a userspace proxy (like tun2socks), careful DNS handling, and platform-specific routing configuration. On Windows alone, getting all of this to work reliably without leaking DNS or dropping packets took us weeks of debugging. The performance characteristics are different from WireGuard too, so you need protocol-aware connection management.

How we use VLESS at Fexyn

We run VLESS Reality with the Vision flow (xtls-rprx-vision) as one of three protocols in Fexyn VPN, alongside WireGuard and OpenVPN. This is not a checkbox feature. Fexyn Stealth ships with the same verification pipeline as Bolt (WireGuard) and Secure (OpenVPN).

On our VPN servers, XRay-core runs with VLESS inbounds on two transports: TCP (port 443) with Reality, and XHTTP (port 8444) also with Reality. The TCP transport is the primary path. XHTTP is a newer transport that can tunnel through CDNs if the TCP path is blocked.

On the client side, we run XRay-core locally, connected to a Wintun TUN interface through tun2socks. All system traffic routes through the tunnel. The client provisions credentials from our API, writes a local XRay config, and starts the connection. If the VLESS connection fails (or if the user is on a network where it's not needed), the client can automatically fall back to WireGuard for better performance.

We verify every VLESS connection the same way we verify WireGuard and OpenVPN: public IP check, traceroute validation, and interface-bound ping. If traffic isn't actually flowing through the tunnel, the connection is marked as failed.

The protocol adds minimal overhead. VLESS header costs are 25 to 50 bytes per packet. TLS 1.3 adds its own overhead, but since you'd be using TLS anyway for censorship resistance, the net cost of choosing VLESS over a protocol with its own encryption layer is actually negative.

Should you care about VLESS?

If you're in a country with unrestricted internet access and you just want a fast VPN, WireGuard is the better protocol. It's faster, it runs in kernel space, it has a formal security proof, and its codebase is small enough that a single person can audit it in a weekend. Use WireGuard. It's great.

If you're in a country where the government blocks VPN traffic, or if you're on a network that performs deep packet inspection (this includes some corporate networks and universities), VLESS with Reality is the best option available today. Your traffic looks like a normal HTTPS connection to microsoft.com. No DPI system currently deployed can reliably distinguish it from real web browsing.

If you're somewhere in between, a VPN that supports both protocols and can switch automatically is worth having. Network conditions change. A hotel Wi-Fi that works fine with WireGuard today might run DPI tomorrow.

VLESS isn't a silver bullet. Russia's attempts to block it show that censors are actively studying the protocol. The Reality extension makes detection much harder, but the arms race continues. What matters is that VLESS exists, it works, and it gives people in some of the most censored countries on earth a way to reach the open internet.

That's worth building for.

Fexyn VPN includes VLESS Reality with the Vision flow alongside WireGuard and OpenVPN, with automatic protocol switching. For a head-to-head with another no-DPI-evasion provider, see Fexyn vs Mullvad. Mullvad is excellent on privacy but does not ship a Reality-class protocol. You can check plans on our pricing page.