Why Maronix Uses VLESS + REALITY

Every private tunnel has two separate questions to answer. What does the traffic look like to something watching the path, and what happens when something watching the path decides to knock on the server directly. A design that settles only the first one works right up until it is probed.

Maronix runs VLESS inside REALITY because that pairing addresses both questions, in different layers and for different reasons. This article takes the two apart, says plainly where each one stops, and keeps the two ideas separate. They are related, they are frequently described as one thing, and they are not interchangeable.

Short answer#

VLESS contributes the proxy core and deliberately adds no encryption of its own. Nothing nested sits inside the outer TLS session for a filter to read out as a second layer, because there is no second layer.

REALITY contributes the transport and deliberately adds no identity of its own. A server that gets probed answers with a genuine handshake borrowed from a real, popular site, and only an authorised client is forwarded into the tunnel.

One is what carries the traffic, the other is what the traffic appears to be. Neither does the other’s job.

The problem this pairing answers#

Internet censorship at the level this is aimed at is a classification problem rather than a content one: something in the path reads a stream of bytes, decides which of several categories it belongs to, and then acts on that decision.

Deep packet inspection is the general name for doing that deliberately. The techniques behind it are ordinary and well understood, from address and DNS blocks up through SNI filtering and TLS interference.

Encryption on its own answers none of it. A perfectly encrypted tunnel announces itself by behaving like a tunnel, and on networks where tunnels are the category being filtered, correct encryption is the thing that gets classified.

Two distinct signals give a classifier something to work with. The first is structural: nested layers, a distinctive handshake, a fingerprint that does not match any browser anyone ships. The second is behavioural: one long connection to one address carrying an unusual volume of traffic. This pairing addresses the structural signal directly. The behavioural one it leaves alone, which is covered further down.

What VLESS contributes#

VLESS is a stateless proxy protocol. Its frame is a version byte, a UUID, a command, a port, an address, and the payload. That is close to the whole design.

Three properties follow:

• No inner encryption. The protocol carries no cryptography of its own, so nothing has to be wrapped inside TLS and then hidden. The Xray project’s guidance is explicit that pairing REALITY with proxy protocols other than XTLS leaves clear TLS-in-TLS characteristics, and that those characteristics have already been targeted.
• No session state. The server validates a UUID and forwards. There is no session table to build, no per-request randomness to generate, which is what the protocol removed when it dropped the earlier response-authentication mechanism in favour of a leading version byte.
• A framing that looks like nothing. VLESS does not disguise itself. It relies on the transport to supply whatever appearance is visible, which is the division of labour the pairing depends on.

The consequence for detection is straightforward. With no inner layer to strip away, the entire visible surface of the connection belongs to the transport. Whatever the transport looks like, that is what the connection looks like.

What REALITY contributes#

REALITY answers the second question: what happens when something connects to the server directly and asks it to prove what it is.

A conventional TLS endpoint has to hold a certificate for a domain it controls. That domain is published, resolvable, and either hosted on the same address or discoverably associated with it. The operator hunting for the server starts from there. Behind that sits a fingerprint problem: extension ordering, cipher preference and session ticket behaviour differ between implementations, and they can be measured on the first connection before any authentication happens.

REALITY’s answer is to have no identity and borrow one instead:

• The client builds a ClientHello carrying a value the server can decrypt with its private key: a short ID, and a timestamp inside the session ID sealed with a key derived from the exchange.
• The server checks the short ID against its list and the timestamp against its allowed clock difference, then issues a temporary certificate signed by a temporary authentication key. Forward secrecy holds because the session keys come from the handshake.
• Anything that fails that check is forwarded to the real site, which completes the handshake before the response is passed back. The prober receives a genuine certificate from a genuine certificate authority for the site it asked for.
• The client must also look ordinary. The fingerprint setting emulates a browser’s client fingerprint, because without it the client side carries a signature of its own and the server-side work buys very little.

Server names have to be genuine too, since the certificate a non-authorised client sees has to match the target.

Why neither replaces the other#

This distinction is the one most often collapsed, and it is worth taking slowly.

VLESS without REALITY#

A tunnel with no security of its own and no camouflage. Over plain TCP it is an unencrypted forwarding format. Inside ordinary TLS it produces exactly the nested structure the project warns about, because the proxy protocol’s own framing sits inside the transport’s encryption.

REALITY without a proxy protocol#

Secures and disguises but does not forward. It is a transport. Something still has to take an address and a port and move the payload, and that is the job VLESS holds. REALITY can also only run on TLS-like transports, currently RAW, XHTTP and gRPC, which is another reason it is never the whole stack.

The pairing#

Neither half is a substitute for the other. Each one supplies the piece the other structurally cannot, which is why the choice appears as a pair rather than as a preference.

What this does not buy you#

Stated without hedging, because a protocol choice that gets oversold here is worse than one that gets described honestly:

• The address still identifies a server. The certificate belongs to the target; the address does not. Anyone who already knows the address can compare the two.
• Volume and duration remain visible. One long-lived connection to one address is still one long-lived connection to one address.
• Behavioural profiling remains open. A filter modelling expected traffic profiles for a destination can still notice an outlier. Doing that reliably across a varied population of targets is an open research question, and Atlas treats it as one.
• The target site becomes a dependency. Its behaviour, its address range and its popularity become operational concerns. The documentation also warns that a target sharing an address, as with a site behind a large CDN, effectively turns your server into a port forwarder for that CDN.
• The client is now a required part of the camouflage. A client that does not emulate a browser fingerprint gives away on the first connection what the server side was built to conceal.

What Maronix does with it#

For the service itself, the pairing is the reason the rest of the operating model exists. Servers are tested against countries with restricted networks rather than on an open route, because the failure modes only appear when something in the path is participating. A trial is sized in days and traffic so that a user can test social media, video and streaming on their own connection instead of reading a claim about them.

Both of those exist because no amount of protocol selection proves anything about your particular path. The tunnel has to survive your network, on your day, with your traffic. That is what the trial is for, and the channel is where the access instructions live.

Common misconceptions#

“VLESS + REALITY is a single protocol.” It is a proxy protocol and a transport. They are configured separately, versioned separately, and fail separately. Treating them as one name is the fastest route to misreading a configuration file.

“VLESS + REALITY is undetectable.” It removes two specific structural signals. Volume, duration, the server address and the behaviour of the target site all remain, and the client’s own fingerprint has to be handled correctly for the server-side work to mean anything.

“More layers would make it stronger.” Adding a second encryption layer inside TLS reintroduces the nested structure this design exists to remove. Strength here comes from having fewer distinguishable layers, not more of them.

Related#

• What Is VLESS? — the proxy core, defined on its own terms
• What Is REALITY? — the transport, including what it explicitly does not do
• What Is Deep Packet Inspection? — the classification problem behind the design
• What Is Internet Censorship? — the wider context this sits inside
• What Is Hysteria2? — the planned second option, and the trade it makes

Last reviewed October 30, 2026. This article was revised after publication. Corrections and additions are welcome.