What is SNI (Server Name Indication)

Server Name Indication — SNI — is a field in the TLS handshake. When your browser connects to a site over HTTPS, it sends an unencrypted SNI value in the very first message: "I want to talk to www.example.com." The server uses that to pick the right certificate (multiple sites often share an IP via virtual hosting), then both sides set up encryption for everything that follows.

The catch: SNI is plaintext. Anyone watching the wire — your ISP, the café Wi-Fi, a DPI box — sees the hostname. Even though every page byte after the handshake is encrypted, the destination domain is in the clear at connection time.

Why SNI exists

Before SNI, every HTTPS site needed its own IP address. The server received an encrypted handshake and had no way to tell which certificate to present. SNI fixed that by adding the hostname to the unencrypted part of the handshake. Now hundreds of sites can share an IP — the server reads the SNI, picks the matching cert, and the handshake completes.

This is how shared hosting and CDN traffic works at scale. Cloudflare, Fastly, Akamai all serve millions of domains from a small set of IPs. SNI is what makes that possible.

What SNI reveals

Even with full HTTPS:

• Your ISP knows every domain you visit.
• Your employer's network knows.
• Government surveillance equipment knows.
• Anyone running DPI on the path knows.

The page content is encrypted. The destination is not. For privacy from the network, this is the side-channel that defeats "but HTTPS protects me" reasoning.

Encrypted SNI: the slow rollout

Encrypted Client Hello (ECH) and the older Encrypted SNI (ESNI) try to encrypt the hostname so the network can't read it. Both work by encrypting the SNI with a key the destination publishes via DNS.

Adoption is partial:

• Cloudflare supports ECH.
• Firefox supports ECH (off by default in some regions).
• Chrome has experimental support.
• Most CDNs and large sites haven't deployed it.

Until ECH is ubiquitous, SNI leaks. And on networks doing aggressive DPI, even ECH-using browsers get filtered or downgraded — the censor can detect the ECH attempt and block it.

How VLESS Reality uses SNI to disappear

VLESS Reality takes SNI and turns it into camouflage. The handshake's SNI is the SNI of an actual public site like microsoft.com. The certificate served back is microsoft.com's real certificate, signed by the real CA. To DPI watching the wire, this connection is indistinguishable from any other HTTPS session to microsoft.com — same SNI, same cert, same handshake timing.

To block it, the censor would have to block microsoft.com — which they generally won't, because too much other traffic depends on it. This is the structural difference between Reality and "obfuscated" VPNs that try to fake a TLS handshake. Reality uses real ones.

Read Deep packet inspection, explained for how this fits into the broader censorship picture, or the VLESS Reality protocol page for the implementation.

Try Fexyn free for 7 days — Stealth uses real SNI to public hosts so DPI sees normal HTTPS, not VPN.