What Is REALITY?

Definition#

REALITY is a transport-security mechanism for Xray that removes the need for a proxy server to have its own domain and its own certificate. Instead of proving its identity with credentials of its own, a REALITY server proves it by presenting the handshake of a real, unrelated website. Any client that is not authorised is passed through to that website.

The project’s own summary is that it replaces the use of TLS, eliminating the detectable server-side TLS fingerprint while maintaining forward secrecy.

What problem it solves#

A proxy server has an identity problem. A conventional TLS server needs a certificate for a domain it controls. That domain is published, resolvable, and either hosted on the same address as the proxy or discoverably associated with it. An operator who wants to find your proxy starts with the domain in the certificate.

A server fingerprint problem sits behind that one. Even when the cryptography is correct, a server’s implementation choices are not invisible. Extension ordering, cipher preferences, session ticket behaviour and similar details differ between implementations and can be measured on the first connection, before any authentication has happened. If a filter can tell that a TLS server on a given address is not the site it claims to be, the camouflage fails on the first probe.

REALITY’s answer to both is the same: do not have an identity. Borrow one.

How it works, at the depth that matters#

It only modifies TLS. The project’s documentation states this plainly, and the server-side implementation is a fork of Go’s standard crypto/tls package. This is why REALITY is specific to TLS-like transports: the current documentation lists RAW, XHTTP and gRPC as the transports it can be used with.

The client proves itself inside the ClientHello. A client holds the server’s public key and a short ID, an identifier the server keeps a list of. It builds its ClientHello so that it carries a value the server can decrypt with its private key and verify: the short ID and a timestamp inside the session ID, sealed with a key derived from the exchange. The server decrypts it, checks the short ID against its list and the timestamp against its allowed clock difference.

The official documentation notes that on the client side this mainly requires handling around a fully random session ID and custom certificate verification.

An authorised client gets a temporary certificate. When the short ID and timestamp check out, the server issues what the project calls a temporary trusted certificate, signed by a temporary authentication key the client can verify. Forward secrecy is preserved because the session keys come from the handshake itself, not from the certificate.

Anyone else gets the real website. This is the part that matters for resistance to probing. For camouflage reasons, Xray directly forwards traffic that fails authentication to the target, and the server completes the handshake with the real site before passing the response back. A prober receives a genuine certificate, issued by a genuine certificate authority, for the site it asked for.

The client must also look ordinary. REALITY requires a fingerprint setting on the client, and the documentation describes it as using a TLS library to emulate a browser’s client fingerprint. Without this, the client side carries its own distinctive signature and the server-side work is wasted. This is a genuine two-sided requirement, and it is the part most often skipped.

Server names must be genuine. The allowed serverNames are the hostnames the server will accept, and they must match the target’s certificate, because that is the certificate a non-authorised client will see.

What it explicitly does not do#

• It does not hide that your address runs a server. The certificate belongs to the target; the address does not. Anyone who knows the address can compare the two.
• It does not hide traffic volume or duration. A single long-lived connection to one address is still one connection to one address.
• It is not available for every transport. The documentation restricts it to RAW, XHTTP and gRPC.
• It does not remove the need for a client-side proxy protocol. VLESS supplies that. REALITY secures and disguises; it does not forward.
• It introduces a dependency. The target site is now part of your system. Its behaviour, its address range, and its popularity all become operational concerns.
• It has a documented operational hazard. The documentation warns that if the target’s address is shared, as with a site behind a large CDN, your server effectively becomes a port forwarder for that CDN, and can be abused after scanning. Choose a target accordingly.

How a censor sees it#

To an active prober: almost nothing. A prober connecting to the address receives a genuine TLS session with a genuine certificate for a real, popular site. There is no mismatch to report and no server fingerprint to compare against a known implementation. The project’s documentation is careful to state that a REALITY client receives the real certificate in three situations: the server rejects the handshake, an intermediary redirects it, or there is a man-in-the-middle. In all three the observation is indistinguishable from ordinary browsing.

To a passive observer: one TLS connection. This is the real residual exposure, and it is worth stating without hedging. What remains is statistical: how long the connection lasts, how much data it carries, whether the pattern resembles browsing to that site or resembles something else entirely. A filter that models expected traffic profiles for a given destination can still notice an outlier. Doing so reliably, against a varied population of targets, is an open research question rather than a solved problem, and Atlas treats it as one, rather than as “REALITY is undetectable”.

When it fits#

Good fit: you operate the server; you can choose a target that is popular, stable, on its own address and already TLS on 443; you run an Xray-based client; you understand that a misconfiguration on either side removes the benefit.

Poor fit: you need something to work over UDP as well; you want a protocol you can reason about entirely from its specification; you are unwilling to run a client that deliberately imitates a browser, or to depend on a third-party website’s behaviour.

Related#

• What Is VLESS? — the proxy core this transport is normally paired with
• What Is Deep Packet Inspection? — the classification problem behind the design
• What Is a VPN Protocol? — how this fits among the alternatives
• What Is Hysteria2? — the other answer: look like ordinary HTTP/3 rather than borrow a site

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