VLESS + Reality: The Strongest Anti-Detection Without a Domain
Chapters
In the previous chapter, we upgraded our transport layer to XHTTP. Now we take a fundamentally different approach — VLESS + Reality. It needs no domain, no certificate, and achieves the strongest active-probing resistance of any current protocol. Think of it as the ideal backup line to your CDN-based primary.
This chapter is pure theory — dense and technical. We'll dissect how Reality works at the protocol level, why XTLS Vision is non-negotiable, and when Reality is (or isn't) the right choice. The next chapter covers hands-on deployment from scratch.
The Pain Points of Traditional TLS Proxies
A standard VLESS + TCP + TLS setup works like this:
This forces you to:
- Own a domain — with DNS records pointing to your VPS
- Obtain a TLS certificate — from Let's Encrypt or Cloudflare Origin CA
- Maintain certificate renewal — Let's Encrypt certificates expire every 90 days, and a lapsed cert means broken service
But the deeper problem is domain exposure. During the TLS handshake, the SNI (Server Name Indication) field transmits your domain name in plaintext. The censor sees exactly which domain you're connecting to. If that domain carries no legitimate traffic besides your proxy connections — it's a neon sign saying "look here."
The Core Idea Behind Reality
Reality's design philosophy is deceptively simple: borrow someone else's TLS certificate.
In a traditional setup, your server proves "I am proxy.example.com" using its own certificate. With Reality, your server impersonates "I am www.microsoft.com" — and to any observer, the connection looks exactly like the real thing.
What censors see: an IP address making a standard TLS connection to microsoft.com. Indistinguishable from the billions of normal HTTPS requests happening worldwide every second.
The Reality Handshake in Detail
Reality adds a clever authentication layer on top of the standard TLS handshake. It unfolds in three distinct phases.
Phase One — Disguised ClientHello with Hidden Authentication
The authentication data is invisible to passive observers. It's encoded within extension fields that TLS implementations are required to ignore if they don't recognize them — making it fully protocol-compliant and undetectable through passive observation.
Phase Two — X25519 Key Exchange
Reality's authentication bypasses the entire CA certificate system. It uses curve25519 key pairs you generate locally. Even if a Certificate Authority were compromised or coerced by a government, Reality connections remain completely secure — the trust model is based purely on the key pair you control.
Phase Three — Normal Proxy Operation
How Active Probing Gets Defeated
The censor's most powerful weapon is active probing — when it suspects a server is a proxy, it connects directly and checks whether the response looks like a legitimate website. Reality's defense against this is essentially perfect:
What the probe sees: this server IS a microsoft.com node. The certificate is real. The HTML is real. The headers are real. Because it literally is Microsoft's real data being proxied back.
Comparison with Traditional Fallback
| Approach | Behavior when probed | Credibility |
|---|---|---|
| Traditional TLS + Nginx fallback | Returns your self-hosted site (maybe a blank page or placeholder template) | Moderate — a tiny site probed repeatedly raises suspicion |
| Reality fallback | Returns genuine content from Microsoft/Apple/Google | Extremely high — you're hiding behind the most visited sites on Earth |
Configuration Parameters Explained
A typical Reality server-side configuration:
Key parameters:
| Parameter | Purpose |
|---|---|
dest | Fallback target — where unauthenticated requests get forwarded |
serverNames | Allowed SNI values that clients may use |
privateKey | Server's X25519 private key (the matching public key goes to clients) |
shortIds | Short IDs — an extra authentication layer preventing abuse if the key leaks |
flow: xtls-rprx-vision | XTLS Vision flow control (explained in depth below) |
Sniffing — Server-Side DNS Re-Resolution
A full configuration also includes a sniffing block:
What sniffing does: Xray inspects passing traffic to extract the real destination domain — from HTTP Host headers, TLS SNI, or QUIC SNI fields. It then performs DNS resolution server-side using that extracted domain name.
Why this matters: in censored networks, client-side DNS is often poisoned. Your machine might resolve google.com to an incorrect IP (a block page, or nowhere at all). With sniffing enabled, Xray ignores whatever IP the client resolved. It reads the actual domain from the traffic and resolves it independently from the server's uncensored network. DNS poisoning is neutralized without any additional client-side DNS tools.
Outbounds — Where Traffic Exits
Two built-in outbound types:
- freedom — Forward traffic to the internet normally. This is the proxy's actual exit to the world.
- blackhole — Silently drop traffic. Used with routing rules to block ads, malware domains, or specific traffic patterns.
Without additional routing rules, all traffic defaults to the first outbound (freedom — normal internet access).
Port Selection
The example uses "port": 443, the ideal choice — all normal HTTPS traffic uses port 443. But if your VPS already has Nginx or another service occupying 443, you can use an alternative like 8443:
When using a non-443 port, Xray logs: REALITY: Listening on non-443 ports may get your IP blocked by the GFW. A server claiming to be microsoft.com but responding on port 8443 is inherently less convincing. The practical risk depends on your situation — overseas VPS IPs are less commonly scanned on non-standard ports — but 443 remains the safest choice by far.
Choosing a Disguise Target
The choice of dest (your impersonation target) directly impacts security. This is one of the most consequential decisions in a Reality deployment.
Good Choices
www.microsoft.com— enormous global traffic volumewww.apple.com— samegateway.icloud.com— Apple devices connect here constantlywww.amazon.com— major e-commerce traffic
Selection Criteria
- Must support TLS 1.3 (mandatory — Reality relies on TLS 1.3 features)
- Should support HTTP/2 (recommended for realistic behavior)
- Has massive global traffic (your connections blend into the background noise)
- Not blocked by censors (google.com has enormous traffic but is already blocked in China)
- Has servers geographically near your VPS (latency must be plausible)
Bad Choices
- Sites already blocked (google.com, youtube.com) — suspicious to see in traffic logs
- Niche sites with minimal traffic — your connections stand out in the noise
- Your own other domains — creates linkage between your proxy and your real identity
The disguise target must make geographic sense. If your VPS is in Tokyo but you impersonate a service that only has servers in Virginia, the physical round-trip latency betrays you immediately. A request to "microsoft.com" that takes 200ms instead of the expected 5ms is a red flag. Always choose targets that deploy globally via CDN — Microsoft, Apple, and Amazon all have edge servers in virtually every region.
XTLS Vision Flow Control — Defeating TLS-in-TLS Detection
The flow field set to xtls-rprx-vision is not optional decoration. It solves a fundamental stealth problem that affects every encrypted proxy: the TLS-in-TLS fingerprint attack. This is arguably the most important concept in this chapter.
TLS Handshakes Have a Predictable Size Fingerprint
A TLS handshake is not random. It produces a highly predictable sequence of packet sizes:
This size sequence — small, small, LARGE, small, then random — is a fingerprint. Anyone observing traffic can recognize the pattern and conclude "a TLS handshake just occurred." Under normal circumstances this is fine. Every HTTPS connection in the world looks exactly like this.
The Problem — Proxy Scenario Creates Nested TLS
Without a proxy, the censor sees you performing a single TLS handshake to a website. Completely normal. But when you're using a proxy, there are two TLS connections:
Here's the timeline:
- You establish the outer Reality connection to your proxy server (this step looks fine — just a connection to "microsoft.com")
- Once the outer tunnel is up, your browser wants to reach google.com
- Your browser initiates a TLS handshake with google.com — this inner handshake passes through the outer encrypted tunnel
Now here's the critical insight. Encryption hides content but does NOT hide packet sizes:
The censor cannot read the content (it's encrypted), but they can observe every packet's size. They notice:
"Right after this connection was established, I see packets of approximately 547, 185, 3197, and 102 bytes in rapid succession, then random sizes afterward. That size sequence matches a TLS handshake fingerprint almost exactly — small, small, LARGE, small. There's a TLS connection nested inside another TLS connection. This is a proxy."
This is the TLS-in-TLS fingerprint attack — no decryption needed. Pure statistical analysis of packet sizes reveals the proxy.
How Vision Solves This
XTLS Vision's strategy: during the inner handshake phase, randomize packet sizes and disrupt timing so that the statistical fingerprint becomes unrecognizable.
Xray has a unique advantage — at the proxy layer, data passes through in cleartext before outer encryption is applied. Xray can identify when it's forwarding inner TLS handshake data by inspecting content type headers. Once identified, Vision applies two countermeasures:
Stage 1 — During the inner TLS handshake (padding and jitter):
Vision also introduces timing jitter — normally, handshake packets fire in rapid succession with sub-millisecond gaps (a telltale cadence). Vision inserts random micro-delays (a few milliseconds) between packets, making the timing indistinguishable from normal streaming data.
The result: the censor sees a sequence of seemingly random packet sizes (814, 329, 3691, 243) at irregular intervals. The "small, small, LARGE, small" signature is gone. No statistical model can confidently match it to a TLS handshake fingerprint.
Stage 2 — After the inner handshake completes (zero-overhead passthrough):
Once the inner TLS handshake finishes (typically 4-6 packets over less than one second), all subsequent traffic is encrypted application data — web pages, video streams, API responses. This data inherently has random packet sizes. No fingerprint to hide.
Vision switches to direct passthrough mode — zero padding, zero delay, zero CPU overhead. The expensive mitigation only applies to the handful of handshake packets.
Before and After Comparison
| Aspect | Without Vision | With Vision |
|---|---|---|
| Handshake packet sizes | 547, 185, 3197, 102 (obvious TLS pattern) | 814, 329, 3691, 243 (randomized per session) |
| Handshake timing | Rapid burst, sub-ms gaps (TLS cadence) | Random micro-delays inserted |
| Post-handshake data | Random sizes (inherently safe) | Direct passthrough (zero overhead) |
| Censor's verdict | "Size pattern matches TLS handshake — proxy detected" | "No recognizable pattern — allow" |
Why TCP is Mandatory — This is Non-Negotiable
Vision requires precise control over individual packet sizes and exact send timing. With raw TCP, Xray directly manipulates the socket — it decides exactly how many bytes go into each TCP segment and exactly when each segment is sent.
If you add WebSocket or gRPC as a transport layer, those protocols impose their own framing logic:
- WebSocket wraps data in frames with its own headers. It may merge multiple small writes into one frame, or split a large write into multiple frames. Your carefully padded 814-byte packet might get combined with the next one into a single 1143-byte WebSocket frame.
- gRPC uses HTTP/2 framing, which multiplexes streams, buffering small messages and splitting large ones according to flow-control windows. Packet boundaries are completely redrawn.
In both cases, the padding that Vision calculated gets destroyed by the transport's reframing. The fingerprint reappears because the packet sizes on the wire no longer reflect Vision's padding — they reflect WebSocket/gRPC framing decisions.
This is why Reality + Vision configurations MUST use "network": "tcp" and MUST NOT enable mux (multiplexing). This is a hard protocol-level constraint, not a preference. Any transport that reframes data — WebSocket, gRPC, HTTP/2 streams — is fundamentally incompatible with Vision's packet-size manipulation strategy.
Reality vs WebSocket + TLS + CDN
These are the two dominant proxy schemes today. They serve different threat models:
| Dimension | VLESS + Reality | VLESS + XHTTP/WS + TLS + CDN |
|---|---|---|
| Requires domain | No | Yes |
| Requires certificate | No | Yes (or CDN auto-manages) |
| Hides VPS IP | No — IP exposed | Yes — IP hidden behind CDN |
| Active probe resistance | Strongest (falls back to real major site) | Strong (falls back to your site) |
| CDN compatible | No | Yes |
| Performance | Excellent (direct TCP, zero framing overhead) | Good (extra WebSocket/HTTP layer) |
| Deployment complexity | Low (no domain, no cert, no DNS) | Medium (DNS + cert + CDN config) |
| If IP gets blocked | Must get a new VPS | Unaffected (CDN absorbs the block) |
Decision Tree
The most resilient setup runs both schemes on a single VPS: XHTTP + CDN as your daily driver (IP concealed, survives IP blocks) and Reality as backup (superior performance, works when CDN has issues). Your client switches between them in seconds.
Reality's Limitations
Reality is powerful but not universal:
- IP exposure — The client connects directly to your VPS. Censors know which IP you're talking to, even if they can't determine what you're doing.
- IP blocking vulnerability — If your VPS IP gets firewalled (port-level or full IP block), Reality connections fail. No CDN to absorb the hit.
- CDN incompatibility — CDN providers don't understand the Reality protocol. Traffic cannot route through Cloudflare or similar intermediaries.
- Single point of failure — One IP, one server. Unlike CDN setups where risk is distributed across edge nodes worldwide.
Current Ecosystem
As of 2026, Reality support is mature across the entire stack:
Server implementations:
- Xray-core — the original and most actively maintained implementation
- sing-box — cross-platform alternative with full Reality support
Clients:
- v2rayN (Windows)
- v2rayNG (Android)
- Clash Meta / mihomo (cross-platform, supports VLESS + Reality natively)
- Shadowrocket (iOS, paid)
- NekoBox (cross-platform)
Management panels:
- 3X-UI — web-based admin panel with one-click Reality presets
- Marzban — multi-user management with subscription and traffic tracking
Summary
VLESS + Reality represents the current state of the art in anti-detection proxy design — zero domain dependency, zero certificate maintenance, the strongest active-probing resistance available, and excellent raw performance. Its core innovations (borrowing real certificates from major sites + curve25519 authentication) form an elegant engineering solution to a seemingly impossible problem.
But it doesn't fit every scenario. If you need IP concealment (protection against VPS blocking), refer back to chapters 3 and 4 for XHTTP + TLS + CDN as your primary scheme, with Reality serving as a high-performance backup.
Recommended deployment strategy:
- Daily use: XHTTP + CDN (chapters 3-4) — IP hidden, resilient to blocking
- Backup line: Reality (this chapter) — better performance, use when CDN has issues
- Both together: Same VPS runs both schemes, client switches instantly
Next chapter: we put all this theory into practice. You'll deploy VLESS + Reality from scratch — installing Xray, generating key pairs, configuring the server, and connecting your first client.