Skip to main content
Back to Blog
protocolsirancensorship-bypass

How VLESS+Reality bypasses DPI in Iran

15.04.2026

Iran's filtering infrastructure can identify almost every common VPN protocol — but VLESS+Reality slips through because it borrows a real TLS handshake from a third-party site. Here's the exact mechanism, and why it matters for users on the ground.

Iran runs one of the most aggressive deep packet inspection (DPI) systems on the public internet. Every packet leaving the country passes through filtering boxes operated by the Telecommunication Infrastructure Company. They look for the fingerprint of common VPN protocols — OpenVPN handshakes, WireGuard noise messages, Shadowsocks AEAD ciphertext patterns — and either block them outright or throttle them down to dial-up speeds.

VLESS+Reality is the protocol family designed specifically to defeat that kind of inspection. NexTunnel uses it as the default standard link for every account. The trick is that Reality does not invent a new TLS profile. It borrows one.

What Reality actually does

When a Reality client wants to connect, it picks a real, popular HTTPS site (we use a rotating set of common CDNs) and performs a genuine TLS 1.3 handshake — Client Hello, Server Hello, certificate, Finished — to that site's IP. From the outside, every byte is identical to the byte stream a normal browser would emit. There is no extra RTT, no proprietary header, no novel cipher suite.

But the server-side endpoint is the NexTunnel edge node, not the borrowed site. After the handshake completes, the client sends an inner authentication signal that only the NexTunnel server knows how to recognise. If the signal is valid, the server routes the rest of the connection as a VPN tunnel. If the signal is missing or wrong, the server transparently proxies the connection to the real third-party site, so a censor probing the IP just sees the genuine site they expect.

Why DPI cannot tell

  • The Client Hello matches a real browser's JA3 fingerprint, including ALPN, supported groups and signature algorithms.
  • The certificate served is a valid leaf signed by a trusted CA chain — because it actually is the legitimate certificate of the borrowed site.
  • The encrypted application data has no characteristic length pattern, because the inner stream is wrapped in standard TLS records.
  • Active probing fails: a censor connecting directly will see the third-party site, not a VPN.

What this looks like for users in Iran

We track real-world success rates per protocol per ISP, and Reality consistently lands at well above 95% connection success across MCI, Irancell and Rightel mobile carriers, and on the major fixed-line ISPs (Shatel, Asiatech, Pars Online). The minority that fail tend to be on heavily regulated enterprise networks where outbound TLS to non-allowlisted IPs is dropped at the perimeter. For those users we offer the CDN (WebSocket) link, which fronts the same VLESS payload behind Cloudflare and inherits Cloudflare's reachability.

Operational details we tune

  • Borrowed-site rotation: each NexTunnel server cycles through a set of approved cover sites every few hours, so no single IP-to-IP pattern stands out in long-term traffic graphs.
  • MTU clamp at 1280: prevents the inner tunnel from emitting fragmented IPv6 or PMTUD-broken flows that DPI can spot statistically.
  • Reality public key sharing across servers: clients can roam between Helsinki, Nuremberg, Dubai and the US without re-pinning a per-server key.
  • Hysteria2 fallback: if Reality is locally throttled, the client can switch to UDP Hysteria2 in a second.

Why we publish this

Censorship circumvention works best when users understand it. If you know your tunnel is mimicking a real TLS connection to a real site, you can reason about why it sometimes fails (e.g. behind captive portals that intercept TLS) and what to try next. The protocol details are open; the operational discipline of running it well — fresh keys, rotated cover sites, monitored success rates — is what we provide.