What Reality is and why it keeps a node alive

Reality isn't "just another protocol on the list" — it's a way to look like someone else's big website. Below is the mechanics with no magic: how it differs from ordinary TLS, why DPI doesn't trip on it, and where its weak spot is. Commands and config are in the paired practice piece; this one is just about understanding it.

This material is about engineering your own infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is your responsibility.

Why ordinary TLS dies first

I've brought up dozens of nodes and seen the same picture every time. You set up VLESS with honest TLS on your own domain — it works for a couple of days, then DPI starts cutting it. The reason is simple: at the moment of the handshake your client sends a TLS ClientHello, where the SNI — the name of the domain it's connecting to — sits in plaintext. It isn't encrypted. DPI reads that name, sees an unknown domain on some obscure server hosting "something on 443," and tears the connection down. Even if the certificate is a valid one from Let's Encrypt, the mere fact of "rare SNI + fresh domain + lone IP" is already enough to draw suspicion and land on the cut list.

Obfuscation like WebSocket or plain header masking doesn't help here: it hides the contents, but doesn't change the fact that from the outside an unusual TLS profile is still visible on a suspicious host. DPI in 2026 looks not only at the SNI, but also at who owns that IP, whether the SNI resolves to that IP, and how the server responds to active probing. Ordinary TLS fails almost every one of those tests.

What Reality does differently

The key idea, the whole reason it was built: Reality doesn't stand up its own TLS at all. It doesn't generate its own certificate, doesn't flash its own domain, doesn't create a recognizable profile. Instead it presents itself as someone else's big donor site and reuses that donor's real TLS handshake.

Here's how it works. You pick a donor — a large, popular resource with TLS 1.3 that DPI is known not to nitpick (say www.microsoft.com). When a client connects to your node, it sends a ClientHello with the donor's SNI. The node intercepts that handshake. From there, two branches:

• If it's a real client with the right key — the node recognizes it by a cryptographic marker embedded in the handshake and starts proxying VPN traffic.
• If it's anyone else (DPI, a probing script, a random browser) — the node silently proxies it to the real donor. The donor answers with its own real certificate, its own real page. From the outside this is indistinguishable from an honest visit to the donor's site.

So DPI, poking at your server, sees valid TLS 1.3 from microsoft.com, a real certificate, a real response. Nothing to object to. And the VPN is hidden inside that same connection, visible only to whoever holds the key.

Why this breaks DPI's statistics

DPI catches VPNs three ways: by handshake/SNI, by traffic behavior, and by IP. Reality closes off the first two.

Handshake. From the outside it's honest TLS 1.3 to a real site. The SNI is the donor's — recognizable, "whitelisted." The certificate is real, the donor's. An active probe lands on the real site. There's no statistical "this is a VPN" signal.

Behavior. This is where the pair comes into play — Vision mode (xtls-rprx-vision). Ordinary VLESS-in-TLS gives you double encryption: an inner TLS inside an outer one. That creates a characteristic packet-length pattern by which obfuscated traffic still gets picked out by statistics. Vision strips the extra layer and mixes in padding, breaking that signature. I cover the Vision mechanics separately — it's important enough to deserve its own note.

The third marker remains — IP. Reality doesn't touch it: if the host is burned or the subnet is poisoned, no handshake masking will help; that's cured by rotating the IP or moving behind a CDN. But that's a separate layer of defense, not a fault of Reality's.

Where Reality's weak spot is

Honestly, no sugarcoating: someone else's donor is a compromise. You use serverNames = microsoft.com, but that domain does not resolve to your IP. Under deep enough analysis DPI may notice the mismatch: "the SNI says microsoft.com, but the IP belongs to some data center in an odd country." For most scenarios that's too little to warrant a block — there would be too many false positives. But under the harshest DPI it's a handle.

The solution is Selfsteal: instead of someone else's donor, the node masquerades as your own site on the same IP. Then SNI, IP, and content are all consistent: the domain resolves to the node, a real page lives on it, and an active probe sees a real site at exactly this address. There's no mismatch. This is the sturdiest option, and it too has its own pair of articles.

A couple more rakes from practice worth knowing in advance: don't use the same donor on all your nodes — rotate them, otherwise one wave of blocks takes everything down at once. And don't set the client fingerprint to chrome — it's a giveaway, and on some core builds the node won't even start; use firefox.

What's next

You've got the mechanics: Reality hides the VPN inside someone else's honest TLS, closes off the handshake and SNI, and Vision finishes off the behavior. This is the foundation on which almost all live nodes under Russian DPI hold up in 2026. How to build it by hand — generate keys, plug in a donor, verify the masking — is in the paired practice piece, "VLESS + Reality: a config that doesn't get burned." That's where the commands and a working config live.