On August 4, 2026, dozens of bypass services in Russia ceased to operate almost simultaneously. The issues were confirmed by the teams of Paper VPN, Amnezia, VPN Generator, VPN Legend, GaMMa VPN, LTVPN, ABS, and FoxyBot — in total, more than 20 services of varying sizes were affected. The Federal Service for Supervision of Communications, Information Technology, and Mass Media (Roskomnadzor) did not officially comment on the situation, but the nature of the failure speaks for itself: services went down not one by one, but in batches, grouped by specific hosting platforms.
This is not just "another wave of blockages." The object itself has changed: the filter now targets not the protocol or the application, but the address space — individual IPs and entire subnets of hosting providers, on whose servers the bypass infrastructure operates. Let's break down what exactly has changed, why this disrupts consumer VPNs more effectively than any DPI, and what this means for those who need reliable access to external services.
What Happened on August 4: Failure at the Borders of Hosts
Outwardly, it looked like a typical outage: users complained about the inability to connect or extremely unstable connections. However, an outage cannot be synchronous across eight independent teams that are not connected to each other except through rented resources.
Industry publications (Anti-Malware.ru, SecurityLab) described the mechanics similarly: IP addresses and entire subnets of major hosting providers fell under restrictions. If a range of addresses is filtered, a cascade of connections collapses — and services renting resources from the same provider disconnect simultaneously, even though technically they have nothing in common.
Comments from specialists are also telling. Lawyer Sarkis Darbinyan pointed out several detection channels: built-in VPN detectors in Russian applications and the simple purchase of premium accounts to obtain an up-to-date list of the service's servers from within. Mikhail Klimarev spoke about the identification of several dozen autonomous systems through which the bypass services operated.
The second point is worth rereading. A mass consumer VPN must provide the client with a list of servers — otherwise, the application cannot connect. This means that anyone who paid for a subscription receives a complete map of the service's infrastructure. This is not hacking or complex reconnaissance; it is a single purchase.
Dynamics: From 197 Services to 469 in a Year and a Half
Blockages based on lists have occurred before, but the pace has noticeably increased. According to Roskomnadzor itself, by the end of February 2026, access was restricted to 469 VPN services. For comparison, in October 2024, there were 197, and in October 2025 — 258. Thus, over the four months of winter, the list nearly doubled.
At the same time, starting from December 2025, restrictions on specific protocols — SOCKS5, VLESS, and L2TP — intensified. A separate line of concern is Telegram: restrictions have been in place since the summer of 2025 and significantly increased in February 2026, with complaints about uploading photos and videos still being recorded (according to Downdetector — about 500 reports per day on August 20).
An important detail for those trying to fix the problem with settings: based on the analyses of the August wave, the main selection criterion was the standard port. If only port 443 is closed, switching to a non-standard port does indeed help — but only until the selection begins to be based not on the port number, but on the nature of the server's response. Then, the move will only delay the blockage.
The Second Layer: Cleaning "White Lists" and the New Role of the Host
The most interesting aspect of the August incident is not the blockage itself, but what was discussed a couple of days before it. The Ministry of Digital Development brought up for discussion with hosting providers a mechanism for the constant verification of IP addresses from the "white list" of the Monitoring and Control Center for Public Communication Networks — a list of exceptions that includes legal corporate VPNs.
The logic of the discussed scheme is as follows:
- if monitoring detects signs of VPN infrastructure at an address within a week, a request is sent to the host;
- the provider has 24 hours to confirm the legality of the server assignments;
- if the client has undergone minimal identification — just a phone number or a bank card — services can be disconnected within 30 minutes;
- if the client is verified through "Gosuslugi," biometrics, or as a legal entity, they are first asked to remove the infrastructure;
- hosts that systematically allow this with weak client verification risk being labeled as unscrupulous — and along with that, entire subnets of the company may be restricted to access only resources from the "white list."
Let me emphasize: these are proposed measures, not enacted rules — the criteria, timelines for implementation, and application procedures have not been approved. However, the direction is clear: the responsibility for identifying bypass services is being shifted to the host, with their own address space being used as leverage. Since February 2024, only companies from Roskomnadzor's registry can provide hosting in Russia — as of July 2026, there are 584 providers in it, and this is a ready list of accountable entities.
Why This Disrupts VPNs More Effectively Than DPI
The classic struggle against bypassing blockages is a contest in traffic obfuscation: DPI searches for protocol signatures, developers hide them under regular HTTPS, and DPI learns anew. This is an endless game, and the defending side regularly wins rounds: protocols that obfuscate traffic as regular HTTPS are noticeably more stable in 2026 than "bare" standards.
Address-based blocking sidesteps this contest. It doesn't matter how well your traffic is disguised if the destination address itself is inaccessible. The attack is not on the signature, but on the scarce resource — clean IPs on a friendly platform. And this resource is arranged in the most vulnerable way for consumer VPNs: several hundred servers with a few hosts, a public client with a complete list of addresses, a single point of failure at the level of the autonomous system.
Three Levels at Which Access is Currently Cut Off
To avoid confusing causes and treating one issue with another, it is useful to keep a simple scheme in mind. Restrictions are imposed at three independent levels, and the protective measures at each are different.
- Protocol Level. DPI searches for signatures: handshakes, characteristic packet sizes, TLS behavior. This can be treated by disguising as regular HTTPS — and this is where the eternal race occurs. Since December 2025, SOCKS5, VLESS, and L2TP have been particularly pressured at this level.
- Address Level. The filter targets an IP, subnet, or entire autonomous system. Traffic obfuscation is useless here: the destination address is simply unavailable. This is what happened on August 4.
- Provider Level. The responsibility to search for and disable bypass infrastructure is being transferred to the host, and the sanction is the restriction of their own subnets. While this is still a proposed scheme, it impacts all clients of the platform simultaneously, including those unrelated to VPNs.
The most common mistake is trying to solve a second-level problem with first-level means: changing the protocol and port when the address is already on the list. The symptom is the same — the connection does not establish — but the causes are different.
What Changes for Those Who Need Access to External Services
This is where the practical part begins, and it should be discussed honestly, without promises of invulnerability.
The blockage surface for residential and mobile proxies is arranged differently. The outgoing address of such a proxy belongs not to the hosting provider, but to the home internet provider or mobile operator — the same ASN from which regular subscribers exit. Blocking an entire subnet here means disconnecting real people, so mass cleaning at the borders of the autonomous system does not work in this segment as it did with hosting on August 4. This also explains why mobile proxies with a shared CGNAT address for hundreds of subscribers are more expensive than datacenter ones: filtering out such an address is costly for the platform itself.
What this does not provide. Proxies do not eliminate DPI: if filtering is tied to the protocol signature or the nature of the TLS session, the type of outgoing IP will not save you. It will not protect you from the blockage of the destination service itself or from the restrictions imposed by the platform (CAPTCHA, login requirements, regional policies). A detailed analysis of how this line of defense works is available in the article on bypassing blockages with active DPI.
What to do right now if access is needed for work:
- Do not keep everything in one autonomous system. The August failure was precisely about this: one provider — one point of failure. A backup channel should go through a fundamentally different type of address, not through a second server from the same host.
- Differentiate tasks. Access to an external service for a person and automation with hundreds of requests are different scenarios with different requirements. For the latter, the type of address and session stability are more critical than speed.
- Do not consider a non-standard port a solution. This is merely a delay. If filtering shifts to analyzing the server's response, switching to another port will cease to help.
- First diagnostics, then purchase. The same symptom of "nothing works" can occur due to four different malfunctions, and proxies do not help in all cases. How to distinguish regional disconnection from the blockage of a specific service in a couple of minutes is explained in the diagnostics guide for disconnections.
- For Telegram, look at the protocol separately. MTProto and SOCKS5 behave differently under filtering, and the choice here is not limited to "taking any proxy" — details are in the honest guide to proxies for Telegram.
Conclusion
The August wave demonstrated a shift in tactics: from hunting for protocols to working with address space and shifting the search responsibility onto hosting providers. For mass consumer VPNs, this is a heavy blow — their infrastructure is compact, public, and concentrated among a few providers, and the server list is purchased along with the subscription.
For access needed in work, the conclusion is simple and dull: resilience is now determined not by the "coolness of the protocol," but by the diversity of the address space and how costly it is for the platform to filter out your outgoing IP along with regular subscribers. If the task is stable access to external services and automation, residential proxies provide a fundamentally different blockage surface than a server on rented hosting. It is not magic, but a different economy for that side.