SNI, ECH and Domain Fronting for Censorship Bypass in 2026

Domain fronting exploited a mismatch between two places a hostname appears in an HTTPS request. The TLS Server Name Indication (SNI) is sent in cleartext during the handshake, so a censor reading the wire sees it. The HTTP Host header, by contrast, is sent inside the encrypted TLS session and is invisible to the network. On a shared CDN, a single edge IP serves thousands of domains, and historically the edge routed the request by its inner Host header while ignoring whether it matched the outer SNI.

That gap was the whole trick. A client could open a TLS connection advertising the SNI of a large, never-blocked property such as a cloud vendor's own site, then set the inner Host header to the blocked destination on the same CDN. The censor saw only the allowed front; the CDN quietly delivered the traffic to the hidden back-end. Blocking it would have meant blocking the entire shared front, which censors were unwilling to do. Signal, Tor's meek transport, Telegram and Psiphon all leaned on this at various points.

The clouds shut it down precisely because it was so hard to block at the network layer. Once a provider enforces that the inner Host must match the outer SNI, the front collapses. The crackdown rolled out across the industry over several years: Cloudflare moved first in 2015, Amazon CloudFront and Google both disabled it in 2018, Microsoft Azure announced it would stop fronting in 2022, and Fastly closed its remaining paths in 2024. By 2026 no major commercial CDN supports naive same-CDN fronting as a reliable, supported feature.

It is not entirely extinct. In May 2026 researchers disclosed Underminr, a domain-fronting-style flaw in shared-hosting and content-delivery infrastructure that revived the SNI/Host mismatch across a large pool of domains. Findings like that are unpatched-bug windows, not durable plumbing: they get fixed, and you cannot build a service on a technique that disappears with a vendor's next deploy. For a censored user who needs something that works next month, classic CDN fronting is no longer the answer.

ECH is frequently sold as "domain fronting, but legitimate." It is worth being precise about what it does. ECH encrypts the inner ClientHello, including the real SNI, under a public key the server publishes in DNS (an HTTPS resource record). The handshake still carries an outer, cleartext SNI, but that outer name is a shared placeholder rather than your true destination. On Cloudflare, every ECH-enabled site presents the same outer SNI, cloudflare-ech.com, so a passive observer cannot tell which of Cloudflare's millions of zones you actually reached. ECH is the successor to the older, failed ESNI, and Cloudflare enabled it by default on free zones, where it cannot be turned off.

So ECH genuinely hides the destination SNI, which is what fronting also achieved. The critical difference is the threat model. ECH was designed for privacy from your ISP, not for defeating a determined national firewall, and the protocol authors say so. Its security depends on the "do not stick out" property: ECH only protects you if so many people use it that blocking ECH is too costly for the censor. The moment ECH usage is sparse, the censor's move is trivial.

That is exactly what happened. Since November 2024, Russia blocks Cloudflare's ECH by dropping any TLS connection that carries both the cloudflare-ech.com outer SNI and the ECH extension together. The censor does not need to decrypt anything; the presence of the feature is the signal. China takes a similar posture. ECH also requires the destination to opt in (you cannot ECH-protect a server that does not publish the key), and it depends on encrypted DNS to fetch that key without leaking the lookup. In short, ECH is a real privacy gain against passive monitoring and an unreliable circumvention tool against a state adversary. Treat it as defense in depth, not as the load-bearing layer.

The technique that survived the CDN crackdown is not fronting through someone else's CDN, but borrowing a real site's TLS handshake on your own server. VLESS + Reality (in Xray-core or sing-box) is the closest practical descendant of domain fronting that you fully control. Instead of relying on a CDN to ignore an SNI mismatch, your VPS itself performs the front: for any handshake that is not from an authenticated client, it transparently proxies the connection to a real, popular third-party site (the dest) and relays that site's genuine certificate back to the prober.

The result is that a censor scanning your IP sees a clean TLS 1.3 handshake to a legitimate foreign site, with that site's real certificate, and an outer SNI that the site actually serves. There is no domain in your name, no self-signed certificate, and no CDN to cooperate with a takedown request. Authenticated clients are distinguished cryptographically by an X25519 key pair and a short ID; everyone else, including active probes, is silently handed off to the borrowed site and sees exactly what a direct visitor would. This is why Reality is currently among the most robust transports against both passive DPI and active probing.

Three practical points decide whether it holds up:

• Choose the dest carefully. It must support TLS 1.3 and HTTP/2, be a single-origin foreign site that is not itself blocked locally, not be a giant CDN property (whose edge topology contradicts your VPS IP), and not redirect. Pair it with an SNI the site genuinely serves.
• Run nothing else on port 443. An exposed panel, a fresh Let's Encrypt cert, or an open admin port reintroduces the very fingerprint Reality erases. Keep management on a separate firewalled port.
• Use a clean, unattributed IP. Reality's stealth assumes the IP is not already on a blocklist and that your provider will not hand over your identity. A fresh offshore IP with full root control removes both weak points.

For a single private endpoint a small offshore VPS is plenty; a 1 vCPU / 512 MB box runs a personal Reality endpoint comfortably, and our offshore VPS plans start around $19.99/mo with a clean IP and root access. For many concurrent users or higher throughput, an offshore dedicated server gives you the headroom and a non-shared address.

There is no single "best" answer; the right layer depends on who you are hiding from.

• If your adversary is your ISP or a workplace filter, ECH on a normal HTTPS site genuinely helps and costs you nothing to enable. It hides the destination SNI from passive logging without any custom tooling.
• If your adversary is a national firewall that does active probing and DPI (Russia's TSPU, China's GFW, Iran's filtering), ECH alone is unreliable and classic CDN fronting is gone. Self-hosted Reality on a clean offshore IP is the durable option, because there is no static artifact for the censor to match and no third party to lean on.
• If you need maximum metadata resistance and can tolerate latency, Tor with a bridge transport (obfs4 or a pluggable transport) remains the strongest anonymity layer, and it can be combined with a VLESS/Reality outbound hop on your own VPS so that your entry into Tor is itself disguised.

The throughline since the fronting era is consistency. Domain fronting died because the SNI/Host mismatch became something a provider could detect and refuse. ECH falters where its usage is too rare to blend in. Reality survives because, configured correctly, your server is genuinely indistinguishable from the real site it borrows. Whatever layer you pick, the foundation is the same: a clean, unflagged IP, full root control, and a provider that will not break the cover by disclosing who you are. That is what an offshore VPS or dedicated server is for. If you want to compare regions and specs for a circumvention endpoint, start with our offshore VPS plans.