russia-mobile-internet-whitelist: which domains survive a mobile shutdown

Three text files and a README, with no code behind them

The repository tree is short enough to state in one line: a LICENSE, a README, and three plain text files named cidrwhitelist.txt, ipwhitelist.txt and whitelist.txt. There is no source directory, no build system, no configuration and no test suite. Whatever value this project has, it is not code.

What it has instead is measurement. The README says the lists are a community effort, compiled by people who scan massive IP ranges during lockdowns to see what is still alive. That is the entire methodology: during a restriction event, someone sweeps large address ranges, records what responds, and the survivors end up in a text file.

That approach has an obvious virtue and an obvious limit. The virtue is that the data is empirical rather than theoretical, gathered by people who could see the failures. The limit is that it is only as good as the most recent sweep, and the README is direct about the consequence: the list is universal, a collection of what works across different operators and regions, not specific to any one provider.

The README is written in three languages, English, Russian and Ukrainian, mirrored side by side. The project is MIT licensed. Repository topics are unusually revealing for a documentation-only project: allowlist, censorship, censorship-circumvention, censorship-resistance, cidr, digital-rights, ipv4, proxy, roskomnadzor, sing-box, xray and xray-core, among others.

What the restrictions actually look like in practice

The README's description of the problem is the most valuable prose in the repository, because it explains why a static list is a hard thing to maintain. Its core claim is that there are no consistent rules. The situation varies by region, by mobile operator, by the cell tower you are connected to, and even by your MVNO.

The example given is Yota, which is owned by and runs on MegaFon's network but can have a radically different, and often stricter, whitelist than MegaFon itself, while you are standing in the same place. That single detail explains why a universal list can never be complete.

From there the README describes four observed behaviours. Total blackout in some regions, especially villages and rural areas, where the internet is simply turned off and sometimes only two or three government websites work. Brutal throttling, where traffic to a non-whitelisted resource is cut to an unusable 14 kb/s or lower. Connection resets or blackholing, where attempts to unapproved servers either get a reset packet or vanish into a timeout, with even ICMP pings blocked. And SNI whitelisting, where the operator only checks the server name you are connecting to, and if that name is on their list your server's IP address does not matter.

The ICMP point matters more than it first appears. The usual mental model is that a network is up if you can ping something, and the README is warning that under a whitelist that model stops working.

Why IP whitelisting broke the SNI trick

The repository's own history is recorded in its filenames. The README notes that ipwhitelist.txt is what cidrwhitelist.txt used to be, and that cidrwhitelist.txt is the new format, containing whitelisted IP subnets in CIDR notation with an example of 0.0.0.0/0. So the project moved from a flat list of individual addresses to subnets, which is the difference between a handful of usable servers and a range you could actually provision within.

The reason for the change is stated in the section the README calls the reality of SNI versus IP and CIDR. Operators are moving to a combined IP plus SNI model. Even if you spoof a whitelisted domain perfectly, the connection is blocked if your server's IP is not also on the allowlist.

That is the single most important sentence in the README for anyone planning an approach, because it invalidates the easiest method. SNI spoofing, taking a domain from whitelist.txt and presenting it as the server name, works only while the operator is checking names and not addresses. Once both are checked, you need an address that is also permitted, which is what the other two files are for.

The README also describes a phenomenon it calls the shield, attributed to the repository owner and observed only on the Tele2 network so far. The claim is that some connections are immune to whitelisting without it being a purchasable service or a static IP, since the README states there are no static IP services on mobile networks. The suggested mechanism is selective enablement, with a story about a user who could not reach government services during a whitelist, threatened legal action citing specific laws, and was compensated while the operator apparently enabled the shield on that account. The README is careful to add that it does not always work, since during the most severe state-mandated shutdowns even those with it lose connectivity.

Diagnosing your own connection in a minute

The README's first practical step is a test you can run without installing anything, which is genuinely the most useful thing in the repository for someone unsure what they are facing.

The test has two halves. First, check whether you can reach yandex.ru or gosuslugi.ru. If those work you have some connectivity, presumably through a whitelist. Second, check whether you can reach 2ip.ru or yahoo.com, or ping 1.1.1.1. If those all time out or get blocked while the first pair works, you are under a whitelist.

That is the whole diagnostic, and it distinguishes the state that matters from the state that does not. Being online is not the question. Being online only to approved destinations is.

The README then lists client recommendations by platform, recommending the vless and trojan protocols with encryption using reality or tls. On iOS the suggestions are Streisand and Happ. On Android, husi, v2rayng and lxbox. On Windows and Linux, throne, or a NekoBox fork by qr243vbi, with an explicit warning that the original NekoBox is abandoned and outdated and should not be used.

There is also a note on IPv6 that is mostly a warning: the README says to forget it, on the grounds that Russian mobile operators have not invested in IPv6 infrastructure and that nobody has tested whitelisting on it. The value of that note is that it stops you spending an evening on an approach the project says is untested and probably undeployable.

Three strategies, in increasing order of cost

Once you know you are whitelisted, the README lays out three options and is honest about the trade-off of each.

The first is SNI spoofing, described as the easiest method: use a domain from whitelist.txt as the server name. The stated limitation is exact, it works only if your operator is not checking IPs.

The second is to find a whitelisted server. The advice is to search for a hosting provider, and the README notes these exist both inside and outside Russia, whose IP subnets appear in ipwhitelist.txt or cidrwhitelist.txt, then buy a server and get an address from the list.

The third is a two-server setup, described as the most reliable solution. The traffic path is given as client to a Russian server with a whitelisted IP, then to a foreign server, then to the internet. The README concedes this is more complex and costly, and the reason it beats the others is that it bypasses IP-based whitelisting rather than trying to satisfy it.

That ordering is the useful part. Spoofing costs nothing and covers the case where the operator is still checking only names. Renting a whitelisted address covers the combined check at modest cost. The two-server path is the answer when your operator checks both and you cannot find a permitted address to rent, and it is where the money goes.

What none of the three requires is a copy-paste configuration. The README explicitly declines to include configs, describing itself as the tip of the iceberg and pointing to the project's Discord server for working configs, discussions of which MVNOs work in which regions at the current moment, and even bypassing censorship on wired internet. That split is a real limitation of the repository rather than of the approach: the lists are here, the working configurations are not, and neither are they likely to be, since configurations break as operators change behaviour.

Editorial conclusion

This repository is worth reading if you are behind a whitelist right now, because the diagnosis it teaches, testing whether yandex.ru resolves while 1.1.1.1 times out, tells you which of the three strategies applies to you, and the files themselves give you the inputs for two of them. It will not help if you need current regional detail, because the README is explicit that the list is a universal collection across operators and that current MVNO and region status lives on the Discord server instead. Read whitelist.txt for domains, match your situation against the three options, and treat the CIDR list as a starting point to verify with your own operator before you pay for a server on the strength of it.

Frequently asked questions

Official sources

1. hxehex/russia-mobile-internet-whitelist on GitHub
2. Issues
3. License: MIT
4. README