Why CDN Fronting: Working Under Whitelists

When a node is banned by IP rather than by protocol, a CDN helps: the client goes to the CDN's address, and the CDN pulls traffic from your node. I cover why this is needed, what hides behind a CDN and what doesn't, and why such a front survives even under whitelists. Theory, no commands.

This material is about engineering your own infrastructure and is educational in nature. It is about configuring your own infrastructure. You are responsible for complying with the laws of your own jurisdiction.

The problem: IP bans

There are various ways to pressure a VPN node. One that's crude but effective is to ban it by IP: your node's address simply stops being reachable. It doesn't matter what protocol you use or how well it's disguised — if the IP can't be reached, nothing else matters.

This is where CDN fronting enters. The idea is simple: the client connects not to your node directly, but to the CDN's address. A CDN is a network of intermediary servers that pull traffic from your source server ("origin"). From the outside, only the CDN's IP is visible. You can no longer ban your node by IP as long as the CDN lives — and operators won't ban the CDN itself, because thousands of legitimate sites sit behind it.

What you can hide behind a CDN and what you can't

An important limitation people trip over. Not every transport passes behind a CDN — only those that work over ordinary HTTP.

• Passes: XHTTP (built specifically for CDNs), and in some cases WebSocket. These are transports that look like ordinary HTTP requests — the CDN lets them through without question.
• Doesn't pass: Reality over raw TCP (flow: xtls-rprx-vision). It isn't HTTP by nature, and you can't run it through a CDN.

So CDN fronting is about XHTTP. If you're on Reality-Vision only, it won't hide behind a CDN — you need to understand this before building the scheme.

How it works in Russian realities

There's a subtlety specific to the Russian context. Russian CDNs (Yandex, Timeweb, Selectel, Beget) front a Russian source — meaning the CDN sits on a Russian node (the entry point), not an overseas one. But traffic has to exit from abroad, otherwise the client gets a Russian IP with all its geo-blocks.

The solution is a cascade: the Russian node behind the CDN bridges to an overseas exit. The resulting chain:

client → CDN (edge's Russian IP) → Russian node (origin) → bridge → overseas exit → internet

What this gives: from the outside only the CDN's IP is visible; the entry is Russian (and Russian CDNs don't ban their own subnets); and the real exit to the internet is overseas. Putting a CDN on an overseas node makes no sense — Russian CDNs won't front it, and Western ones are unreliable in Russia.

Two modes: "via GET" and "via POST"

No deep tech here, but it's useful to understand. XHTTP splits the channel into two HTTP transactions: the download comes down as a long GET, the upload goes up as a POST.

• "Via POST" (packet-up mode) — maximally CDN-compatible: short POSTs up + a long GET down. Works almost everywhere.
• "Via GET" — emphasis on long streams, fewer requests, lower latency, but the CDN must handle long-lived connections.

Why know this: some CDNs block the POST method. Then you have to switch the transport to GET-only — the upload data goes in HTTP headers. This isn't a whim, it's a workaround for a specific limitation of a specific CDN.

What any CDN needs to provide

For XHTTP not to break through a CDN, the provider must give four things. Without them, the stream falls apart:

1. GET and POST methods allowed (POST is often off by default).
2. Cache disabled on the proxy path — otherwise the CDN caches the stream and everything breaks.
3. Header pass-through to origin without rewriting.
4. Large timeouts, no buffering — a long GET must not be cut off.

If the provider fails even one of these, it's not suitable as a front, no matter how nice the panel looks.

Honestly about Russian CDNs

I won't sell an illusion: there are few Russian CDNs proven to work "out of the box" for this task. Some providers are documented to break streaming sessions, some don't confirm cache-free streaming proxying, some allow the methods but don't offer explicit cache disabling on the path.

The most predictable Russian one is Yandex Cloud CDN (in GET-only mode), and the most predictable foreign one is Cloudflare. Other Russian CDNs are worth treating as a backup channel and definitely testing before going live.

The connection to whitelists

A separate value of a CDN front surfaces during rolling shutdowns, when mobile internet in Russia is left working only against a "whitelist" of resources. An ordinary VPS IP is simply unreachable during that — it's not a block, it's an allow-list.

But a large CDN's network (Yandex, say) often falls into the "trusted" category for filtering — traffic to it isn't cut. So a CDN front can stay alive even where a direct node is dead. This makes it not just a "workaround for IP bans," but a survival tool under whitelists.

Wrap-up: how to fit it in

CDN fronting is a backup, not the primary channel. Keep direct Reality as primary (it's faster, without the extra hop). And add XHTTP behind a CDN as a second host in the subscription: the direct channel went down by IP block or under whitelists — the CDN works. Always give the client a subscription with several hosts, so that when one goes down another works.

Remember the limits: a CDN front adds latency and is good for messengers and browsing but heavy for large downloads and speed. It's a survival node, not a speed node.

Next — in the practice: there I show step by step how to put Yandex CDN in front of a node, including a POST-block workaround via GET-only. How whitelists themselves work is in a separate theory of this section.