How Whitelists Work and Why CDNs Save You

During rolling shutdowns, mobile internet in Russia is left working only to a "whitelist" of resources. This isn't a DPI block but an allow-list — and an ordinary VPS IP is simply unreachable during it. I cover how it works and how to build an entry that survives under whitelists. Theory.

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

A whitelist is not a block

The first thing to understand: a whitelist is fundamentally different from an ordinary block. Usually a block works "by exception" — what's on the blacklist is forbidden, everything else is allowed. A whitelist is the reverse: only what's on the list is allowed, everything else is forbidden.

During rolling shutdowns, Russian operators leave mobile internet working only to permitted resources — government services, banks, marketplaces, certain clouds. Anything not on the list is simply unreachable. Your ordinary VPS IP is dead during this not because it was blocked specifically, but because it isn't on the list of the permitted.

Hence an important consequence: masking doesn't help against a whitelist. However good your traffic looks — if the IP isn't among the permitted, it can't be reached. Reality, obfuscation, changing the protocol — all of that is about circumventing blacklists and DPI. Against an allow-list you need a fundamentally different approach.

Two types of whitelist

Permission is usually granted on two criteria:

• By domain — traffic to specific domains is let through (government services, banks, large Russian sites).
• By CIDR ranges — cloud and government-agency subnets are let through (for example, the networks of large Russian cloud providers).

The lists are maintained by the community, change by region, and must be taken fresh — what was "white" yesterday may drop out today.

How to build an entry that survives

Since masking doesn't help, the task is different — to be inside the permitted. Three components:

1. A server in a "white" subnet. You take a VM where the IP falls into a permitted CIDR. In practice the best chance is with large Russian clouds, whose subnets more often land in whitelists. But not every IP in such a subnet is actually "white" — you have to cycle through them.

2. The right SNI. In the Reality inbound and host you set an SNI donor from the whitelist — for example, a permitted resource's domain. Then the handshake looks like a request to a permitted site, and the filter lets it through.

3. A cascade. A "white" Russian entry (in a permitted subnet) bridges to an overseas exit. The provider sees only a permitted Russian IP, while the real traffic goes abroad. The client connects to the "white" entry — and it works even during shutdowns.

Why a CDN is the same tactic, but simpler

This is where whitelists and CDN fronting converge. A large CDN (of a Russian cloud, say) is a ready large network whose subnets often fall into the "trusted" category for filtering. Traffic to it isn't cut even under whitelists.

So a CDN front solves the same task as a "white" entry but without manually cycling through IPs: you hide the node behind a CDN, the client connects to the CDN domain (which is among the permitted), and the CDN pulls from your origin. From the outside it all looks like a request to a legitimate large service.

The difference in approach:

• A "white" entry by hand — you find the IP in a permitted subnet yourself, cycling through addresses. More control, more hassle.
• A CDN front — you use someone else's large "white" network as an intermediary. Less hassle, but you depend on the CDN staying "trusted."

Both tactics are about one thing: being inside the permitted perimeter, not trying to break through it.

Cycling through "white" IPs

Since not every IP in a subnet is actually "white," you have to cycle. The logic:

1. Keep a ready image of a configured node (a snapshot).
2. Deploy new VMs or change the public IP (detach/attach — faster than recreation).
3. Check each address for "whiteness" under mobile operators.
4. Put into service only those that actually work during shutdowns.

This is manual routine that IP-selection tools automate — they roll through clouds' "white" subnets and check addresses against operators. A separate topic about IP rolling.

What to give the client

• In the subscription, keep a separate "WL" host on a "white" entry (or a CDN front) — the client switches to it during shutdowns.
• In the app let the "Auto" mode be set — it'll move to a live server on its own.
• Warn in the bot: "during rolling shutdowns, choose the server marked WL."

Wrap-up

A whitelist is an allow-list, not a block, and masking is useless against it: you need to be inside the permitted. There are two ways — a "white" entry in a permitted subnet (by hand, cycling through IPs) or a CDN front (someone else's large "white" network as an intermediary). Both lead to one result: the client works even when an ordinary VPS is dead.

How to set up a CDN front technically — in the Yandex CDN practice; how to automate cycling through "white" IPs — in the IP-rolling theory.