Table of contents of the article:
As vendor-independent consultants, we feel it is our duty to bring to the attention of the technical community and IT professionals a new case of structured and systematic censorship against free access to the Internet.
Introduction
Since June 9, 2025, Russian Internet users attempting to access Cloudflare -protected websites and services have been subjected to systematic , selective throttling by local Internet Service Providers. This sophisticated and targeted technique forces connections to close after transmitting just 16 kilobytes of data, effectively rendering the vast majority of modern websites unusable.
However, the scope of the blockade goes far beyond Cloudflare services. Even widely used European and global cloud providers —including Hetzner , OVH , and DigitalOcean —are affected by this form of interference, with visible impacts not only on user experience but also on application delivery, content loading, and communication with third-party APIs. The targeted targeting of these providers is not accidental , but rather consistent with a broader political strategy aimed at Russia's digital isolation.
What is the “16 KB Wall” and How Does It Work?
According to Cloudflare in a technical analysis published on June 27, 2025, throttling manifests itself as a silent connection reset immediately after the first 10–14 TCP packets, corresponding to approximately 16 KB of data, have been transmitted. From that point on, the connection is deliberately terminated , without any obvious errors for the user, but effectively preventing the loading of key resources.
The tactic is applied without distinction to all major protocols and transmission modes , including:
- HTTP/1.1 over TCP
- HTTP/2 over TLS
- HTTP/3 on QUIC
- Traditional and encrypted connections (TLS 1.3 included)
The result is that, despite a seemingly working connection, the browser is unable to load content beyond the first few sections of the document. Images, scripts, videos, and interactive forms are unreachable. The observed behavior is similar to a broken or timed-out site, but the problem is artificial and deliberate.
Documented interference on Hetzner, OVH and DigitalOcean
Although media attention initially focused on Cloudflare – as one of the most popular security platforms for institutional websites, CDNs, editorial portals, and independent blogs – the same types of interference were also detected against services hosted by leading European cloud providers , which are particularly strategic for modern international IT infrastructure. These include:
- Hetzner Online GmbH (Germany)
Used extensively by European developers, startups and companies for its highly competitive VPS offer, Hetzner is one of the leading IaaS providers in the DACH region. It is often used for self-managed hosting, staging environments, decentralized nodes, REST APIs and open source projects. Russian throttling measures have compromised the reliability of connections to Hetzner instances, with sudden session resets e abnormal latencies, making even simple control panels and backend interfaces inaccessible. - OVHcloud (France)
Historically one of the largest European cloud providers in terms of volume and capillarity of presence, OVH hosts a significant part of European Enterprise Infrastructure: virtual servers, Docker containers in production, Kubernetes cluster and SaaS solutions. Throttling towards OVH has had repercussions on a very wide range of applications, including e-commerce platforms and management software. The reports indicate selective degradation even on non-standard doors, which confirms the presence of deep traffic inspection (DPI) from Russian ISPs. - DigitalOcean (USA/Europe)
Widely adopted by independent developers, small businesses and DevOps practitioners for cloud projects, DigitalOcean is known for its ease of use, direct APIs and scalable services. In Russia, many PaaS applications based on DigitalOcean droplets are either broken or only partially accessible. Again, the 16 KB threshold prevents administrative portals, graphical dashboards, and dynamic scripts from fully loading, causing a “page breakage” effect.
These providers represent a fundamental part of the European and international infrastructure. Their targeting confirms that the goal isn't simply to censor specific content (such as dissident blogs or Western media), but rather:
- Hindering the very infrastructure of the modern web, hitting the key points on which digital delivery is based;
- Compromising communication with backend and frontend services hosted in Western clouds, often used by Russian companies or private users for technical and professional purposes;
- Limit technological dependence on non-governable platforms at the national level, implicitly pushing towards the adoption of local alternatives (and therefore more easily controlled by the State).
In short, this is infrastructural censorship , not content-related censorship. A technically sophisticated and silent strategy, but with systemic consequences, affecting accessibility, interoperability, and net neutrality.
Technical confirmations from Cloudflare Radar and NEL
According to data collected by Cloudflare Radar and NEL (Network Error Logging) reports , connections from Russian ISPs show:
- Session breakup immediately after TCP handshake phase + first packets
- Sudden TCP Resets
- Timeout on modern protocols even encrypted ones
- Inbound traffic reduced by more than 30% from Russian territory

These indicators cannot be explained by routing or congestion issues; on the contrary, they are exclusively consistent with an active interference strategy employed by access providers . Cloudflare has named some of the major Russian ISPs involved, including:
- Rostelecom
- Megafon
- Vimpelcom
- MTS
- MGTS
Reason: Censorship and digital isolation
Despite the absence of official statements from the Kremlin, technical evidence and historical precedents clearly indicate that this is a deliberate censorship measure, an integral part of the “sovereign Internet” strategy pursued by the Russian Federation.
The goal is twofold:
- Reduce technological dependence on Western suppliers, forcing citizens and businesses to use local alternatives (Yandex Cloud, VK Tech, etc.)
- Gradually isolate the population from access to foreign content and news, preventing the circulation of free information, criticism of the regime or protest initiatives.
This direction is consistent with existing laws such as the Sovereign Internet Law (2019) and continued investments in building a parallel, supervised and controlled national infrastructure (RuNet project).
Real impact on users and businesses
The consequences of throttling are tangible and serious:
- Inaccessible sites: even trivial portals do not load, due to the 16 KB threshold
- Interruption of essential services: online payments, OAuth authentications, support portals
- Unusability of external APIs: From maps to expeditions, every interaction fails
- Loss of productivity and information isolation
Companies with offices or customers in Russia can no longer guarantee stable access to their services, and the situation is worsening for open source projects , international media , technical support services , and SaaS tools used in the developer environment.
No Solution (For Now): Cloudflare Confirms Technical Impotence
In its official report, Cloudflare stated:
“Since the throttling is applied at the local ISP level, the action is beyond our control. At this time, we are unable to lawfully restore reliable and high-performance access to our products and protected sites for Russian users.”
And yet:
“Access to a free and open Internet is fundamental to individual rights and economic development. We condemn any attempt to deny access to Russian citizens.”
The Reverse Proxy and Port Forwarding Workaround
While we await structural and coordinated solutions at the international level, we at Managed Server have already successfully helped two clients restore the visibility of their websites in Russia, without having to migrate or overhaul their existing infrastructure . The solution was based on the implementation of a reverse proxy with targeted port forwarding on ports 80 (HTTP) and 443 (HTTPS), hosted on a non-throttling Italian network , such as that of Aruba Cloud.
In practice, it was sufficient to purchase a basic VPS Cloud OpenStack instance for €2,50 per month through Aruba's Cloud.it portal and appropriately configure the iptables rules for port forwarding traffic to the origin servers located in OVH and Hetzner datacenters , both of the providers currently affected by the restrictive measures of Russian ISPs.
This configuration acts as an intermediate entry point , invisible to selective censorship, allowing Russian users to correctly access content through an Italian transit node. The reverse proxy does not alter the content or logic of the application, and allows for effective mitigation at minimal cost , without modifying global DNS or compromising TLS security.
In specific cases, we have also combined port forwarding with DNAT and SNAT rules to maintain full compatibility with access logs and ensure persistent sessions even in eCommerce and WordPress environments.
Final considerations: a dangerous precedent
As vendor-independent consultants working in the web infrastructure and systems sector, we cannot help but publicly highlight this technical and geopolitical shift . This isn't simply a technical issue or a routing unknown: we're facing a veritable censorship architecture , planned and replicable.
European companies must be ready to face:
- Sudden blocks of services to geopolitically unstable areas
- International redundancies to mitigate state attacks or interference
- Active traffic and metadata analysis to detect throttling signals
- Legal and diplomatic strategies, especially in the B2B or IT export sector
Conclusion
The systematic throttling underway in Russia represents a critical case study for global internet security . The fact that it can be selectively applied to individual providers—Cloudflare, Hetzner, OVH—demonstrates how fragile the balance between connectivity and freedom is.
We are facing a new generation of censorship: silent, technical, distributed. As a technical community, we must analyze it, document it, and denounce it, to prevent it from becoming the norm in other regimes or contexts.

