IPSets-For-Bypass-in-Russia: CIDR lists for services blocked by ISPs

What the repository actually contains

The project describes itself as a collection of CIDR addresses of IPs from various companies, with an invitation to support the repository and submit your own addresses with the name of the service, site or company attached.

The top level layout shows the shape of it. There is an ipset-all.txt file that holds the main address list, an exclude.txt and an exclude-domains.txt for things left out of the collection, a directory holding domain lists for bypassing blocks, and a second directory covering the unblocking of multiple services with ChatGPT given as the example, and an AS Parser directory holding the maintenance script.

So there are three kinds of artefact here rather than one. A CIDR list, which is the core payload and is written in the format ipset consumes. Domain lists, which feed a different mechanism, the DPI circumvention lists rather than address blocking. And a tool for producing more of the first kind.

The licence field on the repository is not stated, and no licence file appears among the top level entries. That is worth knowing before you redistribute the data or build it into a product, since the absence of a licence means no explicit permission is granted for either.

Where the address list comes from and how it ages

The project page states that the list covers IP addresses that became inaccessible from 10.06.2025 through a date in 2026, and names Amazon CDN, Amazon Cloudfront, Cloudflare, BunnyCDN and OVH SAS among them.

The provenance is documented. The addresses were taken from stat.ripe.net, which is a public interface for routing and BGP data rather than a blocklist curated by the project. The list is also stated to be based on the zapret repository by Flowseal, a project concerned with DPI circumvention.

Both of those sources explain what the list can and cannot tell you. RIPE stat data describes which address space is announced and by whom, so a range that becomes unreachable appears there as a routing level fact, not as a policy document. The list is therefore a best guess at which blocks to route around, assembled from observable network behaviour rather than from a published policy. It is also inherently time sensitive, since blocks appear and disappear and the addresses involved move between operators.

That is the honest framing for the data. It is a snapshot of observed unreachability with a stated window, not a maintained registry, and the last push was on 2026-10-13 with no tagged releases to fall back on.

The AS Parser script is how you extend the list

The project page describes an AS Parser as a script that automatically finds CIDR addresses, sorts them into a readable form, and is useful if you want to build your own list and propose pull requests.

That is the maintenance story of the repository. Rather than asking contributors to hand-write address ranges, the parser takes an autonomous system number, works out which prefixes it announces, and formats the result so it can be read, reviewed and merged. A pull request then adds a range with the name of the service attached, which is exactly the contribution format the repository asks for.

The AS Parser directory is the only part of the tree that is code, and the project lists Python as its primary language. Everything else is data.

For a reader deciding whether to use this, the important point is that the repository is a convenient aggregation, not a unique dataset. If you already run your own monitoring of which destinations fail on your network, a script that does the same thing from RIPE data is worth having, and if you do not, this repository is where you can borrow one rather than write one. Either way the resulting list is only as good as your own verification of it.

The Telegram case the project page rules out

The project page is unusually direct about one scenario, and it is worth quoting the substance accurately because it defines the boundary of the whole collection.

It states that unblocking Telegram for people living in the south of Russia is impossible, and that SOCKS5 or MTProto proxies should be used instead. The reason given is that the blocking is implemented by the providers without the use of the equipment the project targets, so no list of addresses helps. Only the IP address of the web frontend at telegram.org is blocked outright, while mirrors and the addresses of all data centres are blocked by port, specifically ports 80, 443, 88 and 8443.

The advice for reaching both clients and the website in that case is a VPN. The page also says that zapret will not help there.

This is the clearest thing in the repository about what the data can achieve. The lists address a specific class of block, one that can be worked around by choosing different destination addresses. A block implemented at the provider level across a range of ports on the same addresses is a different problem, and the project says so directly rather than implying the lists will sort it out.

Two mechanisms in one repository: addresses and domains

The directory of domain lists alongside the ipset file is the part that most needs an explanation, because the two mechanisms operate at different layers.

The CIDR list works at the routing level. When a destination address falls in the list, traffic to it is handled differently, typically by sending it to a working address or by modifying the packet so that the filtering equipment no longer recognises it. This is why the address list is tied to address level blocking.

The domain list works at the name level. Domains are fed to a DPI circumvention mechanism such as the zapret tooling the list is based on, which selects traffic by the name in the request rather than by the address it resolves to. That handles a different failure mode, where the block follows the name or the protocol signature regardless of which address you connect to.

The domain list directory is where that domain data lives, and exclude.txt and exclude-domains.txt are the negative lists, presumably to keep entries that cause breakage out of the applied configuration.

That dual structure is the practical point. A user who installs only ipset-all.txt and expects it to cover a domain based block will find partial behaviour, because the two lists need to be applied through different mechanisms. The repository does not document a single unified application command, which means assembling the right configuration for your own router and DPI is the part you have to do yourself.

Adoption realities: no releases, no stated licence, one data format

There are no GitHub releases, so there is no version to pin. The last push was on 2026-10-13, so the data is being touched, but a consumer has no way to know whether a given file changed in a way that matters, or to roll back to a known good state through a release tag.

The data format is the other constraint. ipset-all.txt is written for the ipset tool on Linux, which means using it means either running ipset or translating the ranges into whatever your firewall supports. The addresses are a plain list of CIDR blocks, so the translation is mechanical, but the tooling expectation is not optional in the way a web proxy list would be.

The honest assessment is that this is a useful shortcut rather than a finished system. If you already maintain firewall rules for a router or a small server and you want a starting set of ranges for services that are known to be blocked, this saves you the work of working out which prefixes belong to which operator. If you want a tool that handles your problem, it is not that, and the Telegram case in the project page is the clearest example of where the approach stops.

The AS Parser and the pull request workflow are what keep the data honest, and they also mean the data improves when people whose network sees something different contribute the ranges they find. That is a real strength, and it depends on participation rather than on a publisher refreshing a feed.

Editorial conclusion

This repository is worth pulling if you run ipset or nftables on a router and you want a starting set of blocked service ranges to work from, and the AS Parser script gives a workable path for keeping your own list current as new ranges appear. It is not usable on its own for the Telegram case the project page describes, because that block is implemented by providers without the equipment the list targets, and it is not a general purpose circumvention tool for users who simply need to reach a blocked service. Before depending on the data, check that ipset-all.txt still matches what your own network sees, note that the repository has no tagged releases and the licence is not stated, and treat the Telegram limitation described in the project page as a hard boundary rather than something the lists can work around.

Frequently asked questions

Official sources

1. Issues
2. README
3. V3nilla/IPSets-For-Bypass-in-Russia on GitHub