2025-06-26
4 min read
Since June 9, 2025, Internet users located in Russia and connecting to web services protected by Cloudflare have been throttled by Russian Internet Service Providers (ISPs).
As the throttling is being applied by local ISPs, the action is outside of Cloudflareâs control and we are unable, at this time, to restore reliable, high performance access to Cloudflare products and protected websites for Russian users in a lawful manner.Â
Internal data analysis suggests that the throttling allows Internet users to load only the first 16 KB of any web asset, rendering most web navigation impossible.
Cloudflare has not received any formal outreach or communication from Russian government entities about the motivation for such an action. Unfortunately, the actions are consistent with longstanding Russian efforts to isolate the Internet within its borders and reduce reliance on Western technology by replacing it with domestic alternatives. Indeed, Russian President Vladimir Putin recently publicly threatened to throttle US tech companies operating inside Russia.Â
External reports corroborate our analysis, and further suggest that a number of other service providers are also affected by throttling or other disruptive actions in Russia, including at least Hetzner, DigitalOcean, and OVH.
Cloudflare is seeing disruptions across connections initiated from inside Russia, even when the connection reaches our servers outside of Russia. Consistent with public reporting on Russia's practices, this suggests that the disruption is happening inside Russian ISPs, close to users.
Russian Internet Services Providers (ISPs) confirmed to be implementing these disruptive actions include, but are not limited to, Rostelecom, Megafon, Vimpelcom, MTS, and MGTS.
Based on our observations, Russian ISPs are using several throttling and blocking mechanisms affecting sites protected by Cloudflare, including injected packets to halt the connection and blocking packets so the connection times out. A new tactic that began on June 9 limits the amount of content served to 16 KB, which renders many websites barely usable.
The throttling affects all connection methods and protocols, including HTTP/1.1 and HTTP/2 on TCP and TLS, as well as HTTP/3 on QUIC.
The view from Cloudflare dataCloudflare Radar exists to share insights and bring transparency to Internet trends. The high rate of connectivity errors to all our data centers has resulted in an overall decrease in traffic served to Russian users. The reduction in traffic can be observed on Cloudflare Radar:
Client-side reports via Network Error LoggingSome customers elect to enable W3C-defined Network Error Logging (NEL), a feature that embeds error-reporting instructions inside the headers of web content that users request. The instructions tell web browsers what errors to report, and how to do so. Below is a view of NEL reports that show an increase of TCP connections being âresetâ prematurely (as explained in our tampering and Radar resets blogs). Separately, the large growth in h3.protocol.error shows that QUIC connections have been greatly affected:
Corroboration of throttling using internal dataThe effects of the throttling can also be observed in our internal tooling. The chart below shows packet loss to our Russian data centers, each data center represented by a different line. The Y-axis is the proportion of packet loss:
High packet loss is a strong signal but does not on its own indicate throttling, since there might be other explanations. For example, an explanation may be our servers trying to resend packets multiple times in during some other mass failure that hinders, but does not completely halt, communication.
However, we have two additional pieces of information to work with. The first consists of public reports that âthrottlingâ in this case means blocking all connections after 16 KB of data has been transmitted, which takes 10 to 14 packets (depending on the underlying technology). Second, we have our recently deployed âResets and Timeoutsâ data that captures anomalous behaviour in TCP when it occurs within the first 10 packets. Since 10 packets can contain 16 KB of data, some connections that are blocked around 16 KB will be visible at the âPost PSHâ stage in the Radar data. In TCP, the âPSHâ message means Cloudflare got the initial request and data transfer has begun. If the connection is blocked at this stage, then many of the sent packets will be lost.Â
The graph below uses Radarâs Data Explorer to focus on just the Post-PSH stage, where there is a dip followed by an immediate and proportionally large increase before June 11. This pattern corresponds closely with the loss data seen above:
If you run Internet sites for Russian usersIf you are using Cloudflare to protect your sites, unfortunately, at this time, Cloudflare does not have the ability to restore Internet connectivity for Russia-based users. We advise you to reach out and solicit Russian entities to lift the throttling measures that have been put in place.
If you are a Cloudflare enterprise customer, please reach out to your account team for further assistance.
Access to a free and open Internet is critical for individual rights and economic development. We condemn any attempt to prevent Russian citizens from accessing it.
Cloudflare's connectivity cloud protects
entire corporate networks, helps customers build
Internet-scale applications efficiently, accelerates any
website or Internet application,
wards off DDoS attacks, keeps
hackers at bay, and can help you on
your journey to Zero Trust.
Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.
To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Internet ShutdownRussiaPolicy & LegalRelated posts
May 16, 2025 3:00 PM
Vulnerability transparency: strengthening security through responsible disclosureIn line with CISAâs Secure By Design pledge, Cloudflare shares its vulnerability disclosure process, CVE issuance criteria, and CNA duties. ...
April 22, 2025 1:00 PM
New year, no shutdowns: the Q1 2025 Internet disruption summaryIn Q1 2025, we observed Internet disruptions around the world caused by cable damage, power outages, natural disasters, fire, a cyberattack, and technical problems....
February 28, 2025 2:00 PM
Cloudflareâs 2024 Transparency Reports - now live with new data and a new formatCloudflareâs 2024 Transparency Reports are now live â with new topics, new data points, and a new format, consistent with the EUâs Digital Services Act...
January 28, 2025 2:00 PM
A diversity of downtime: the Q4 2024 Internet disruption summaryAfter a rather busy third quarter, the fourth quarter of 2024 saw significantly fewer Internet disruptions....
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4