I keep meaning to write about Reality, this VPN protocol from 2023, and every time I try the story sounds insane unless you sit with it for a few paragraphs. So let me just type it out properly this time, with the technical detail it deserves.
The 15-year arms race nobody questioned
For most of the past fifteen years, the VPN industry has been in a closed-loop game with internet filtering systems. The assumption underneath everything was that to evade detection, you obfuscate your traffic.
Every protocol that came along was answering the same question: how do we make our VPN traffic look not-like-VPN?
- OpenVPN — pluggable transports, obfsproxy, XOR patches
- Shadowsocks — randomized padding, AEAD ciphers, protocol-level obfuscation
- V2Ray (VMess) — WebSocket masquerading, gRPC transport, mKCP
- obfs4 — random byte streams that look statistically uniform
- Trojan — fallback to a fake HTTPS website on wrong handshake
And filtering systems on the other side would, with boring inevitability, learn the new pattern over a few months. The entire field was caught in this loop.
What's strange in retrospect is that nobody, in fifteen years of really smart engineering, stepped back and asked whether the question itself was right.
Hide better. Hide better. That just was the field.
Then in 2023, RPRX shipped Reality
A developer who goes by RPRX on GitHub released a thing called Reality as part of the Xray-core project. And what it does is, instead of trying to look-like-Google in a clever statistical way, it just establishes a real TLS connection to real google.com.
I had to read the docs three times before I believed it.
Let me break down what actually happens at the byte level.
How Reality actually works
Here's the simplified packet flow:
┌─────────┐ ┌──────────────┐ ┌─────────────┐
│ Client │ │ Reality │ │ google.com │
│ │ │ Server │ │ (real) │
└────┬────┘ └──────┬───────┘ └──────┬──────┘
│ │ │
│ TLS ClientHello │ │
│ SNI = google.com│ │
│─────────────────>│ │
│ │ TLS ClientHello │
│ │ (forwarded as-is) │
│ │─────────────────────>│
│ │ │
│ │ ServerHello + │
│ │ Real Google cert │
│ │<─────────────────────│
│ ServerHello + │ │
│ Real Google cert│ │
│<─────────────────│ │
│ │ │
│ ── handshake completes here ── │
│ │ │
│ Client provides │ │
│ Reality auth │ │
│ derived from │ │
│ Google session │ │
│─────────────────>│ │
│ │ HIJACK: switch to │
│ │ VPN tunnel mode │
│<════════════════>│ │
│ encrypted VPN │ (Google │
│ tunnel │ connection │
│ │ no longer used)│
Step by step:
-
Client initiates TLS to the Reality server with
SNI = www.google.com - Reality server proxies the first TLS messages to the real google.com
- The certificate that comes back is genuinely signed by Google's CA
- Handshake completes with a real Google session — keys are derived from real Google entropy
- At the very last step, the protocol uses keys derived from that real Google session to authenticate a Reality client and quietly hijacks the connection
- Subsequent traffic looks (statistically) identical to a long-lived TLS session with Google
The configuration looks like this
Server-side xray.json snippet (simplified):
{
"inbounds": [{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [{ "id": "uuid-here", "flow": "xtls-rprx-vision" }],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.google.com:443",
"xver": 0,
"serverNames": ["www.google.com"],
"privateKey": "...",
"shortIds": [""]
}
}
}]
}
The dest field is the real site that Reality proxies through. It can be google.com, microsoft.com, github.com, or any popular HTTPS site. The serverNames field is what shows up in SNI for clients.
Why DPI cannot detect it
I built a test setup to verify this myself. Watched the connection in tcpdump and Wireshark. There was no way the connection I was looking at had any VPN in it.
It wasn't VPN. It was Google traffic. Until it wasn't.
For DPI systems looking at this connection from the outside:
- The certificate is genuinely signed by Google's CA
-
The SNI is
www.google.com - The TLS fingerprint matches what a real Chrome/Firefox produces
- Active probes to the server respond like a real google.com (because they actually go through google.com)
- Traffic patterns match a normal long-lived TLS session
Even modern DPI systems with machine-learning classifiers cannot reliably distinguish a Reality connection from someone watching YouTube on Google's CDN.
Why it's structurally unblockable
The funny part is that to block a Reality connection, a network operator would have to block Google itself. The actual whole thing.
Modern infrastructure being what it is, blocking Google causes such cascading damage:
- Authentication flows (OAuth, SSO) break
- Banking apps that use Google Play Services fail
- Half of the SaaS supply chain runs through Google somewhere — Google Workspace, Cloud Run, Firestore, reCAPTCHA, Google Fonts, Google Tag Manager
- CAPTCHAs and fraud-detection services on countless websites stop working
Nobody has been willing to do it.
So Reality is, structurally, unblockable. Not "very hard to block." Architecturally not blockable while Google as a service exists on the internet.
The clever bit: keys from a real Google session
What makes Reality cryptographically sound is that authentication is derived from the real Google TLS session. The client and server both observe the same real Google handshake. From that shared observation, they can derive a shared secret that only the legitimate Reality client and server know.
An attacker (or DPI system) sitting on the wire can see the handshake but cannot reproduce the shared secret without:
- The Reality client's private key (held only by legitimate clients)
- OR the Reality server's private key (held only by the operator)
This means even if a DPI vendor knew exactly how Reality worked (which they do, the code is open source), they couldn't pre-compute or distinguish Reality sessions from real Google sessions.
What this means for the future
Reality has been live in production at scale since mid-2023. As of 2026:
- All major censorship-resistant VPN services that work in restrictive regions use it
- It has not been blocked anywhere as a protocol
- Multiple academic papers have analyzed it and concluded it's structurally undetectable
There are some practical edge cases (specific traffic-shape fingerprinting under certain conditions, timing analysis on small samples), but no general way to identify Reality traffic in the wild.
The meta-lesson I keep coming back to
The reason this story has been bouncing in my head for months isn't really the technology.
About six months ago my team was deep in optimizing a process. Two quarters in, metrics moving the right direction, everyone happy. A new colleague joined who hadn't been in the room when the original framing was set, and during her first week she stopped a meeting to ask, "wait, why are we doing this in this form, exactly?"
Twenty four hours later we'd figured out two thirds of what we'd been optimizing didn't need to exist.
She wasn't smarter than us. She just hadn't been in the room when the question got fixed.
That's what Reality reminds me of. Fifteen years of brilliant engineers grinding on "hide better," and what was missing wasn't more cleverness. It was someone outside the framing wondering whether hiding was the goal.
Try it yourself
If you want to play with Reality:
# Install Xray-core
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
# Generate Reality keys
xray x25519
Useful resources:
- Xray-core GitHub — the reference implementation
- REALITY documentation — protocol spec
- Hiddify — user-friendly client supporting Reality
If you don't want to set up your own server but want to understand how Reality performs in practice, SpaceRouts runs Reality at scale on European servers — useful as a reference implementation if you're benchmarking.
Closing thought
The deepest engineering insights are often not "we found a cleverer way to do X." They're "we noticed X was the wrong question."
Anyone else found themselves there more often than they'd like?
Discussion: which assumption have you been operating under for too long without questioning it?
Top comments (0)