# Domain Fronting

Domain fronting is a TLS/HTTPS trick that puts two different domain names on the same request: one visible to a network observer, one hidden from it. The visible name is the TLS SNI — which a DPI box, a TLS-inspecting proxy, or a basic SNI-based block list reads in the clear. The hidden name is the HTTP `Host:` header inside the encrypted tunnel, which only the endpoint CDN sees.

The technique works when a CDN hosts many domains on the same TLS terminator and routes incoming requests based on the inner `Host:` header rather than the outer SNI. In that case, a client can send:

```
ClientHello: SNI = innocuous.example.com
(TLS handshake)
GET /path HTTP/1.1
Host: actual-target.example.com
```

The on-path observer sees `innocuous.example.com` (which is allowed) and waves it through. The CDN receives both names, ignores the SNI for routing, and serves `actual-target.example.com`.

## Why it works (when it works)

CDNs like Cloudflare, Fastly, Akamai, and Google's edge used to route based on `Host:` by default, because it was simpler: multiple tenants share the same wildcard certificate and the same front-end IP, so using `Host:` as the routing key is natural. Anyone who could host a tenant on the CDN got fronting "for free" as a side effect.

The most-used fronts historically were `*.cloudfront.net` (AWS), `*.appspot.com` and `script.google.com` (Google), and `*.azureedge.net` (Microsoft). Because these run so much legitimate traffic, blocking them breaks too much of the internet to be politically viable — so a censor who can't distinguish fronted from legitimate traffic has to let all of it through.

## Why it mostly stopped working

Between 2018 and 2020, Google, AWS, Cloudflare, and Azure all announced they would enforce SNI/Host consistency: the inner `Host:` must match the outer SNI, or the request gets rejected at the edge. The motivation was largely external pressure — Russia and others had started blocking popular fronts with collateral damage, so the CDNs preferred to remove the capability rather than keep being the choke point.

The enforcement varies:

- **Google.** Enforces across most properties (App Engine, Firebase, etc.) but some Google-owned endpoints still accept mismatched SNI/Host when the request terminates at Google-operated infrastructure. `script.google.com` (Apps Script) is the current well-known example, which is why tools like [[masterhttprelayvpn]] use it.
- **Cloudflare.** Enforces consistency on paid plans; free tier historically had gaps that third parties exploited. Fronting through a Worker on your own Cloudflare zone still works in the sense that the outer SNI and inner Host can both point at Cloudflare, just to different routing paths.
- **Fastly, CloudFront.** Both rolled out strict enforcement.

So classic "use Facebook's cert to talk to a banned Telegram endpoint" domain fronting is mostly dead. What survives is narrower:

1. **Same-CDN fronting.** Put your own relay on the same CDN as a high-reputation service, then rely on the censor's inability to distinguish your TLS traffic from theirs. The outer SNI is still *your* domain, but your domain looks just like theirs at the IP and JA3 level.
2. **Google Apps Script fronting.** Specific to Google's serverless runtimes, where the routing still honors the inner Host for certain endpoints. This is the crack that [[masterhttprelayvpn]] exploits.
3. **"Domain hiding" via ECH.** Encrypted Client Hello (RFC 9746) encrypts the SNI itself. Different mechanism, similar effect: the censor can't see the real destination hostname. As of 2026, deployment is partial — Cloudflare supports it end-to-end, browsers ship it behind flags.

## Ethics and tradeoffs

Domain fronting is dual-use: it's used by activists, journalists, and people in censored countries, and it's also used by malware and phishing kits that want their C2 traffic to look like legitimate CDN traffic. The CDNs' pivot to enforcement was partly about keeping the anti-abuse story simple: "we don't support fronting" is easier to defend than "we support fronting for good actors."

Practical consequences for users:

- **Don't build long-term infrastructure on domain fronting.** The capability tends to get closed after a high-profile use case. Assume the specific trick will stop working in 6-24 months.
- **Shared-secret auth matters more than the front.** If the relay has no auth or weak auth, the front is just decoration — the censor doesn't need to break the front if the relay is abusable directly.
- **Fingerprinting is the real enemy.** Even a working front doesn't hide the client's JA3/JA4 fingerprint, timing patterns, or flow size distribution. Sophisticated DPI doesn't need to read the Host to identify fronted traffic.

## Related

- [[masterhttprelayvpn]] — uses Google Apps Script as a current working front (Python)
- [[masterhttprelayvpn-rust]] — same approach, Rust port with desktop UI and Android support
- [[serverless-relay-transport]] — the broader pattern where a serverless function (not just a CDN route) is the relay backend
- [[xray-tutorial]], [[vless-subscription-format]] — VLESS ecosystem, a different approach (uplink on uncommon ports/domains, TLS pretending to be a real site)
- [[store-now-decrypt-later]] — tangential: another "it works today, maybe not later" technique
- [[tls-desync-fake-clienthello]] — different lie to the DPI: confuse it with a fake ClientHello at the packet layer, instead of mismatching SNI/Host at the HTTP layer