Cloudflare Reports 16 KB Internet Throttling for Users in Russia

For people in Russia trying to reach websites protected by Cloudflare, the reported limit is stark: many connections deliver only the first 16 KB of a web asset. Cloudflare says the restriction began on June 9, 2025, and its effects make much ordinary browsing unreliable or impossible. The company traces the disruption to internet service providers (ISPs) inside Russia, where it says it cannot restore reliable access to its products or customers’ sites.

The 16 KB ceiling matters because web pages depend on multiple assets and exchanges of data. A connection that stops after a small initial transfer may fail to load page content or supporting resources, even if it reaches a server successfully. Cloudflare’s internal analysis indicates that the limit affects a broad range of web assets; the company characterizes the result as most web navigation becoming impossible.

What Cloudflare says is happening

Cloudflare reports several forms of interference with connections from Russia. Its observations include packets injected to interrupt a connection and packets blocked until the connection times out. The newer behavior, first observed on June 9, restricts how much content can pass: Cloudflare says a connection may be cut off after around 16 KB has been transmitted.

The reported disruption spans HTTP/1.1 and HTTP/2 over TCP and TLS, as well as HTTP/3 over QUIC. That breadth matters for site operators: changing a site’s connection protocol alone may not resolve the problem, because Cloudflare says each of these methods is affected. The company also sees errors on connections initiated inside Russia when those connections reach servers outside the country, which points to interference near users’ access networks.

Cloudflare identifies Rostelecom, Megafon, Vimpelcom, MTS and MGTS among the ISPs it has confirmed are applying disruptive measures. It says that list is not exhaustive. Reports from Zona Media describe similar throttling and disruptions affecting other providers, including Hetzner, DigitalOcean and OVH. The available information does not establish that every provider or customer experiences the same symptoms.

Cloudflare says it has received no formal communication from Russian government entities explaining the reason for the actions. It connects the disruption to longer-running efforts to limit external internet services and points to a reported threat to throttle US technology companies operating in Russia. That background offers context, but the company’s measurements document network effects rather than the stated intent behind them.

Signals in traffic and browser reports

Cloudflare Radar shows a decline in traffic served to users in Russia alongside a rise in connectivity errors across its data centers. The company makes the trend visible through its Radar view for Russia. A fall in traffic is consistent with access problems, though traffic trends alone cannot identify the mechanism causing them.

Some Cloudflare customers enable Network Error Logging (NEL), a W3C-defined browser reporting feature. Site responses can include instructions for browsers to report certain network failures, and Cloudflare says its NEL data shows more TCP connections being reset before they complete. It also reports a large increase in h3.protocol.error, a signal associated with failures affecting QUIC connections.

Those browser reports add detail to the traffic picture. A premature TCP reset indicates that an established connection ended unexpectedly; QUIC errors show that the disruption extends to HTTP/3 traffic. Neither signal, by itself, identifies who caused a failure or why. Their value comes from appearing alongside Cloudflare’s other observations, including packet loss and the apparent transfer limit.

Why the 16 KB pattern is technically plausible

Cloudflare’s internal tooling records high packet loss to its data centers in Russia. Packet loss alone does not prove throttling: servers may retransmit packets during other network failures, and overloaded or impaired paths can also lose data. The company therefore compares the loss pattern with reports that connections are interrupted after approximately 16 KB has crossed the network.

That amount of data can fit within roughly 10 to 14 packets, depending on the connection technology. Cloudflare’s recently introduced Resets and Timeouts measurements track unusual TCP behavior at different points in a connection. Their “Post-PSH” stage refers to traffic after a server has received the initial request and begun sending data. If a connection is cut near the reported 16 KB threshold, packet loss may rise at that stage.

Cloudflare says its Radar Data Explorer shows a dip followed by a sharp increase in Post-PSH events before June 11, matching the timing of the packet-loss pattern. This alignment supports the throttling explanation. It remains an inference drawn from multiple data sources, rather than a direct view of the equipment or rules causing the interruption.

What site operators can expect

Cloudflare says it cannot restore reliable connectivity for Russia-based users while the restrictions are applied by local ISPs. For organizations serving customers there, the practical issue is that a site can remain available at its servers while still failing on the user’s network path. Monitoring traffic volume, browser error reports and connection failures can help teams distinguish that pattern from a site-side outage, although those measurements cannot remove the restriction.

Cloudflare advises affected site operators to contact Russian entities and ask for the throttling to be lifted. Enterprise customers can also contact their Cloudflare account teams for help. The company’s account of the incident points to a wider operational constraint: when disruption occurs inside the access network, a web service’s own hosting and protocol choices may have limited ability to restore access. Further changes in traffic and connection-error data will show whether the reported pattern persists.

Cloudflare’s analysis and links to its supporting measurements are available through its earlier account of internet access in Russia, its connection-tampering analysis and its discussion of TCP resets and timeouts. Taken together, those sources make the 16 KB limit a technically grounded explanation for why many users cannot reliably load protected sites, while leaving the cause and future scope of the disruption unresolved.