Domain fronting in 2026: mostly dead, not actually gone

Domain fronting is a specific trick, not a synonym for "hidden TLS."

That sentence matters because a lot of current writing on the topic is just category soup. People use "domain fronting" to describe classic CDN SNI/Host mismatch tricks, ECH, MASQUE, WebTunnel, and basically any web-looking transport they find hard to classify.

Those are not the same thing.

If you blur the categories, you stop seeing the real tradeoffs and you start making sloppy architectural claims.

What classic domain fronting actually is

The clean definition from the 2024 measurement paper Measuring CDNs Susceptible to Domain Fronting is the right one to keep: classic domain fronting exploits the discrepancy between the TLS SNI and the HTTP Host header on shared CDN infrastructure.

In the classic form:

TLS SNI: front.example
HTTP Host: target.example
CDN edge: shared
Certificate selection follows SNI
Origin routing follows Host

If the CDN accepts that mismatch, the visible outer destination can look like one hosted domain while the actual HTTP routing goes somewhere else on the same shared platform.

That is a very particular technique. It depends on how the CDN handles shared infrastructure, certificate selection, and origin routing.

It is not just "encrypted traffic with confusing metadata."

Why the big-cloud story changed

The easy, outdated summary is "domain fronting died in 2018."

That is wrong, but it became popular because something important did happen: major hyperscalers shut down the most famous versions of the trick. The 2024 paper notes that Google and Amazon disabled domain fronting in 2018. Microsoft Azure moved later, disabling it for new resources in November 2022.

Azure's own Front Door FAQ gives the operational dates more precisely:

• resources created after November 8, 2022 have fronting blocking enabled
• enforcement for existing domains started on January 22, 2024

Azure also tells you what the failure looks like:

• HTTP 421 Misdirected Request
• diagnostic log marker SSLMismatchedSNI

That is all useful because it shows the real state change. Big clouds did not merely publish a blog post saying they disliked fronting. They changed routing behavior and surfaced explicit enforcement markers.

Those dates matter because "domain fronting died" often gets repeated with no timeline, as if every provider flipped the same switch at once. They did not. The shutdown story was staggered, and staggered enforcement is exactly how stale fronting advice manages to survive for years after a given provider changed its behavior.

Why "dead" is still wrong

The important correction from the same 2024 paper is that domain fronting was still feasible in 22 of 30 tested CDNs.

That does not mean "fronting works everywhere." It means the right 2026 summary is messier:

• classic hyperscaler fronting is much harder
• provider behavior is inconsistent
• some CDNs still allow fronting in some parts of their infrastructure
• mitigations are not uniformly deployed

That is a much better description than either "completely dead" or "totally available."

The useful operator lesson is that fronting capability is a property of specific provider behavior, not an eternal law of HTTPS. It comes and goes as providers tighten enforcement or leave odd gaps behind.

Azure's FAQ is a good example of how nuanced that behavior can get. It documents an exception where SNI/Host discrepancies are allowed when both domains belong to the same subscription and are included in the relevant routes or routing rules. That is not "fronting is alive" in the old public-abuse sense. It is proof that routing policy and administrative boundaries matter.

This is also why I dislike fronting guides that read like trading cards of "working domains." Provider behavior is operationally brittle. A technique that depends on undocumented permissiveness can disappear after a boring control-plane change, a regional rollout, or a cleanup pass in one product line while still half-working somewhere else.

What Tor still teaches us

Tor's current documentation is one of the best ways to avoid turning this topic into pure history.

The Snowflake explainer says Snowflake is built into Tor Browser and describes it as using volunteer-run proxies coordinated by a broker. Tor's transport docs also describe lyrebird as implementing obfs4, Snowflake, and WebTunnel; see pluggable transports.

And the bridge documentation still shows transport examples with provider-facing parameters that remind you front-like mechanics have not vanished from the earth. See using bridges.

That does not mean "go abuse a CDN." It means provider-specific transport assumptions are unstable and operationally narrow. Tor's own docs have had to change those assumptions over time. A 2025 Tor documentation issue notes that the old meek-azure option is gone and the built-in meek path now uses cdn77; see the issue here.

That is the 2026 pattern in one example: the category is still real, but the provider details are moving targets.

What domain fronting is not

This is the part most explainers still bungle, so let us make the comparison explicit.

Classic domain fronting: SNI/Host mismatch on shared CDN
ECH: encrypts ClientHello metadata
MASQUE: explicit HTTP proxying
WebTunnel: Tor transport over web-looking proxy paths

ECH

ECH encrypts the ClientHello under a server public key so that SNI-like metadata is less exposed to observers. That is important and current.

It is not classic domain fronting.

ECH hides client hello metadata. Domain fronting abuses a mismatch between visible routing signals on shared infrastructure. Those are different mechanisms.

MASQUE

RFC 9298 standardizes CONNECT-UDP, which is part of the MASQUE family of HTTP proxying technologies.

Again, adjacent but not identical.

MASQUE is explicit proxying over HTTP. Domain fronting is a mismatch trick that depends on CDN behavior. Calling MASQUE "new domain fronting" is lazy and wrong.

WebTunnel and other web-looking transports

Tor's docs discussing WebTunnel and related transport families are useful because they show where people get confused. A transport can look web-ish, use HTTP infrastructure, or hide inside familiar traffic without being classic domain fronting in the SNI-versus-Host sense.

The important distinction is not academic. It affects:

• what metadata is hidden
• what infrastructure behavior you depend on
• what breaks when providers change policy

So what still works in 2026?

The honest answer is:

• the old giant-cloud assumptions are much weaker
• fronting-capable CDN behavior still exists in parts of the ecosystem
• provider-specific opportunities are unstable
• front-adjacent transports are alive, but they are not all the same category

That is why I prefer the title "mostly dead, not actually gone."

The worst operational mistake now is not failing to memorize which CDN still allows what. It is failing to distinguish classic domain fronting from other techniques that solve related but different problems.

This is also why the topic connects directly to /blog/active-probing-defense, /blog/tor-technical-users-guide, and /blog/xray-reality-vs-wireguard. These systems all sit near the same classification battlefield, but they do not fight it in the same way.

The opinionated answer

In 2026, "domain fronting" is still a meaningful term, but only if you use it precisely.

Use it for the specific SNI/Host mismatch trick on shared infrastructure.

Do not use it as a generic label for:

• ECH
• MASQUE
• Tor transports in general
• any TLS flow that looks less obvious than raw WireGuard

The technical failure mode now is category confusion. Once you call every hidden-or-obfuscated HTTPS transport "domain fronting," you lose the ability to reason about what is actually being hidden, what infrastructure assumption the design depends on, and what breaks when a provider changes policy.

Classic domain fronting is no longer the easy hyperscaler trick many people remember from older blog posts. But it is not just a museum piece either. It survives as a narrower, more conditional, more provider-specific phenomenon, while adjacent transport designs keep evolving around it.

That is the useful mental model to keep.

It also gives you a better reading habit for future protocols. When someone says a system uses Snowflake, WebTunnel, ECH, or MASQUE-like behavior, ask first whether the change is in routing mismatch, handshake metadata exposure, or explicit proxy semantics. Once you ask that, the landscape gets a lot less mystical.