We tried the most popular ways, and succeeded!
TSPU (the Russian abbreviation for “technical equipment for combating threats,” referring to the deep packet inspection boxes installed at Russian ISPs) block connections based on the first few packets, since they can’t handle the load otherwise. This means we can fool them without a full VPN and without routing all our traffic abroad.
We decided to check which open, free tools exist for this: ByeDPI, zapret2, youtubeUnblock, and a few others, as well as separately looking at encrypting the site name itself through ECH.
In this piece we only look at techniques that work locally on the user’s device (laptop, mobile device, or router). We won’t cover VPN protocols or client apps here.
Ways to fool DPI
1. Fragmentation (split, tlsrec)
When you open a blocked site like instagram.com, the browser or app sends a first packet that names the site in plain text, in the SNI field inside the TLS handshake. TSPU reads this field, compares it against its list, and if there’s a match, drops the connection with a TCP RST. But since TSPU reads traffic on the fly, this reading has weak points.
If we split the first packet into two small ones so the domain in the SNI field breaks in the middle (say, one piece is “instag” and the next is “ram.com”), we can fool TSPU. TSPU can’t reassemble the pieces at line speed, so it never sees the blocked domain. The real instagram.com server on the other end reassembles the pieces itself without any trouble (that’s just normal work for a standard TCP stack).
2. Desynchronization (disorder, fake, oob)
We can also slip a fake packet in before the real data. TSPU usually only looks at the first packet. If we send a fake packet with random or empty content before the real data, TSPU either decides everything is legitimate, or assumes it already processed this session and stops tracking the connection’s traffic.
3. Playing with TTL (–ttl, ip_ttl)
We can also play with the packet’s time to live (TTL). TSPU equipment sits on the path before the real server. We can send a fake packet with a TTL short enough to reach TSPU but expire before it reaches the real server. TSPU then processes this fake packet as if it were real, while the actual packet with a normal TTL arrives a bit later, already past the DPI checkpoint.
4. Spoofing fields in the fake packet (rnd, dupsid, sni=)
Also, we can fill the fake packet’s fields with harmless junk. If a fake packet from the previous techniques still reaches the real server, the server should just discard it as corrupted rather than break, so these packets get deliberately invalid but harmless values. This same trick usually gets applied both to the fake packet used for desynchronization (2.2) and to the fake packet with a shortened TTL (2.3). It isn’t a separate, standalone way to fool DPI, but a way to make an already-sent fake packet safe.
These four techniques (and combinations of them) underlie nearly all the tools we studied. They are based on the academic Geneva paper from the CCS 2019 conference (several of these tool authors cite it).
Separate from these four techniques is the idea of hiding the site name itself cryptographically, instead of tricking DPI. Read more on that below, in the section devoted to ECH (Encrypted Client Hello).
What we tried
ByeDPI
A simple local SOCKS5 proxy for Windows, Linux, and Android (through the separate ByeByeDPI app). It implements packet splitting, packet spoofing, and TTL tricks. Releases come out regularly. An active community has formed around the project, judging by the number of open discussions on GitHub.
zapret2
The successor to the much older zapret. zapret2’s engine has been rewritten so that strategies get described in Lua scripts instead of code, which gives it the flexibility to adapt to new filtering methods without rebuilding the program. It supports Linux, FreeBSD, OpenBSD, and Windows.
youtubeUnblock
A specialized version of the same principle, tuned specifically for YouTube’s detectors and aimed primarily at routers running OpenWrt or Entware. The author’s documentation says it’s only for YouTube, but technically the engine reacts to any list of domains you give it.
B4
An open-source tool with a convenient web interface that can pick a working strategy on the fly, without a restart. It’s written in Go. Judging by the pace of new releases, it’s maintained very actively. It runs on both regular Linux and routers with OpenWrt or Entware.
zapret-discord-youtube
A ready-made zapret build specifically for Windows, with .bat files for strategies. It has 32,000 stars on GitHub.
tg-ws-proxy
It is a tool by the same author, built not for bypassing blocks in general, but specifically for Telegram Desktop. It wraps the Telegram protocol in a regular WebSocket connection. Unfortunately, it only works on computers (Windows, macOS, Linux) and doesn’t work for mobile Telegram. The basic mode doesn’t need its own server, but the extended version with a custom domain depends on a cloud-based Cloudflare Worker. In theory, you could run it on a router and point the Telegram app on your phone at the router’s local IP instead of 127.0.0.1, since the MTProto protocol doesn’t care where the proxy sits (we haven’t tested this ourselves, so it’s only a theoretical possibility, not a ready-made solution).
ECH (Encrypted Client Hello)
The idea is to hide the site name inside the encrypted part of the packet, so only a shared alias is visible from outside. For Cloudflare, that alias is cloudflare-ech.com, the same one for many different sites. Selective blocking by hostname (the alias) is impractical, since it hides a mix of both allowed and potentially blocked sites. That leaves the filter with only one crude option: cut off every connection to cloudflare-ech.com wherever it finds that alias, instead of picking specific ones. That’s what happened in November 2024, when users started complaining that Cloudflare-hosted sites with ECH enabled stopped opening in their browsers and hung until they timed out. At the same time, the same sites from the same machine downloaded fine through wget, which doesn’t support ECH. After Cloudflare temporarily disabled TLS 1.3 on its end (which also disables ECH), the sites started opening again from Russia within a few minutes. This suggests that TSPU, upon detecting ECH, cuts the connection. That’s exactly what we want to test on our own nodes.
Our testing methodology
Sites we used
The ones relevant to our audience, broken down by group:
- Messengers: WhatsApp, Signal, Discord, Telegram
- Social networks: Instagram, Facebook
- Business services: LinkedIn
- Privacy and censorship circumvention: ProtonVPN, ProtonMail
- Independent media: Meduza, Novaya Gazeta Europe, Deutsche Welle
- We tested YouTube separately from the rest. We assumed beforehand that it was throttling rather than blocking, but in practice, without any tools, the domain was completely inaccessible across all our runs. We can confirm that in YouTube’s case it is a complete block rather than traffic throttling. Our throttling assumption didn’t hold up.
We tested all domains with encrypted DNS (DoH) already configured. It’s a baseline working condition.
All the tests in this round ran from a single connection:
- a Windows 11 laptop,
- VPN connection to a home internet line in St. Petersburg, with the tools running inside WSL2 on that same laptop while the VPN tunnel was active.
We tested the tools primarily designed for routers (youtubeUnblock, zapret2) inside WSL2 as well: they used the same engine, netfilter and NFQUEUE, as they did on OpenWrt or Entware. This lets us check whether the technique itself works, though it doesn’t test the opkg installation on a specific router model.
We separately checked two VPS servers in Russia (St. Petersburg and Moscow). We decided not to run full tests there, since most domains on our list already opened on these nodes without any tool, leaving no way to test circumvention tools there. The behavior pattern would have been the same anyway.
To compare “with circumvention” and “without circumvention” modes, we took addresses already known to be blocked and ran each one several times in a row. Some resources sometimes opened without any intervention, so we needed to tell whether a given circumvention method worked or it was just a coincidence.
We repeated the baseline check separately before launching each new tool to make sure the previous tool had fully shut down and hadn’t left any active settings that could affect the next tool’s results.
The results of the automated testing
- Social networks, business services, independent media, and messengers (except Telegram) opened with all four tool combinations, without exception.
- Telegram stayed blocked with all three tools we tested.
- ByeDPI behaves differently depending on the strategy. For example, with the disorder_tlsrec parameters it opens WhatsApp and Signal but not Meduza, while with fake_ttl8 it’s the other way around.
- For ProtonMail, the mail.proton.me domain didn’t open with any tool, while account.proton.me turned out to work through zapret2, by chance. That domain wasn’t originally on our test list, so the other three tools didn’t get tested against it. We suspect that mail.proton.me and account.proton.me sit on different IPs and that the block targets the specific address rather than the domain name as a whole. We didn’t test this separately, though (for example, by resolving the IP and hitting the bare address directly).
Summary of results by domain and tool
We ran each domain-plus-tool combination several times in a row (5 times for the tools, 11-12 times total for the baseline).
| Domain | Baseline | ByeDPI disorder_tlsrec | ByeDPI fake_ttl8 | youtubeUnblock | zapret2 |
| Messengers | |||||
| Blocked | Available | Unstable | Unstable | Unstable | |
| Signal | Degrades* | Available | Available | Available | Available |
| Discord | Blocked | Available | Available | Available | Available |
| Telegram | Blocked | Blocked | Blocked | Blocked | Blocked |
| Social networks | |||||
| Blocked | Available | Available | Available | Available | |
| Blocked | Available | Available | Available | Available | |
| Business services | |||||
| Blocked | Available | Available | Available | Available | |
| Privacy | |||||
| ProtonVPN | Blocked | Available | Available | Available | Available |
| ProtonMail | Blocked | Blocked | Blocked | Blocked | Partial** |
| Independent media | |||||
| Meduza | Blocked | Blocked | Available | Available | Available |
| Novaya Gazeta Europe | Blocked | Available | Available | Available | Available |
| Deutsche Welle | Blocked | Available | Available | Available | Available |
| Video | |||||
| YouTube | Blocked | Blocked | Blocked | Available | Available |
* curl matches the reference byte for byte, but manual browser inspection reveals a broken page layout, with some images failing to load
** account.proton.me (the login page) opens through zapret2, but the actual mail at mail.proton.me doesn’t. No other tool tested this subdomain separately
Where curl and manual checking disagree
Here it’s worth briefly explaining why curl can be misleading at all. It sends a single bare request for the main document and doesn’t fetch images, scripts, or follow-up connections the way a regular browser does. That means degradation of some resources within the page stays invisible to it, and you need a manual check in the browser with your own eyes, not a script in the terminal.
- On baseline, curl shows a perfect 200 status code for Signal, with a response body matching the uncensored internet byte for byte, but in the browser the layout is broken and not all images load.
- WhatsApp works overall, but all three tools (ByeDPI fake_ttl8, youtubeUnblock, and zapret2) show instability with it, while Facebook and Instagram (on the same Meta infrastructure) work fine with circumvention tools enabled. We don’t understand whether this is something specific to the WhatsApp protocol or a bug in how the circumvention tools are implemented.
Key takeaways
For developers and administrators
- Before deploying any of the tools below for your users, check exactly how the target site is being blocked. If the IP address is completely unreachable, even without TLS, that’s a full route cutoff, and none of the techniques in this piece will help. You’ll need a full tunnel instead. If the site is unreachable only over HTTPS while the IP address itself responds to something, it’s probably an SNI-based block, and in that case it’s worth trying these techniques.
- If you have a router that supports OpenWrt or Entware, we recommend installing youtubeUnblock, zapret2, or B4 directly on the router. That way, circumvention works for every device on the network at once, without configuring each one separately. If your router doesn’t support this, install the tool on each device separately instead (ByeDPI and zapret2 are available for Windows and Linux, ByeByeDPI for Android). It’s less convenient, but it still works.
- If you’re setting up circumvention for a group of people on Windows, say a family or a small team, it’s easier to put together a ready-made configuration once (based on zapret-discord-youtube, for example) and hand it out than to explain command-line flags to everyone.
- If you’re administering infrastructure, keep in mind that WinDivert (the driver most Windows tools run on) can get flagged by antivirus software as a potentially unwanted application. It’s worth warning users ahead of time, so they don’t give up because of an antivirus or operating system warning.
For users
You can set up encrypted DNS (DoH/DoT) at several different levels. It’s a separate layer, not connected to the techniques above, but it removes some of the problems caused by DNS response spoofing:
- On a Keenetic router: “Internet filters” — DNS setup — add a server — server type “DNS-over-HTTPS”;
- On Windows 11: Settings — Network & internet — select your connection — Properties — next to “DNS server assignment” click “Edit” — switch to “Manual” and enter the address of a DoH server with encryption enabled;
- In your browser: in privacy and security settings, turn on “Secure DNS” and pick a provider.
Next steps
- We need to test combining several techniques at once (packet splitting together with TTL tricks, for example). This approach might hold up better against targeted filter updates than any single technique on its own.
- This article does not cover decentralized and overlay networks (I2P, Yggdrasil, CJDNS, IPFS) and tools like Snowflake from the Tor project. Technically, they don’t require your own rented server, but they still wrap traffic in an entirely separate network rather than specifically fooling TSPU. We’ll cover them separately in one of our upcoming pieces.
- ECH. We’ll test it separately by checking the HTTPS-type DNS record (dig -t HTTPS domain) to see whether the ech= parameter is present, and compare the behavior against the reference domain cloudflare-ech.com, which exists specifically for this kind of check.