Is Cloudflare blocked in Russia? Not by name, but in practice it often behaves like it. Since June 9, 2025, Russian ISPs have throttled connections to Cloudflare-protected sites so that only the first 16 KB or so of a response gets through, and TLS connections using ECH have been dropped since November 2024. Pages load half-way, then hang.
This guide is for owners whose sites sit behind Cloudflare and who have visitors, customers or staff in Russia. It explains what is actually being blocked, how to tell the causes apart from outside the country, and which infrastructure changes restore access for your Russian audience. It does not cover how individual users get around restrictions.
Is Cloudflare blocked in Russia right now?
There is no formal ban listing Cloudflare as a company, and some sites behind it still open from some Russian networks. But two separate measures now affect almost every Cloudflare customer with a Russian audience:
- Throttling of Cloudflare traffic (since June 9, 2025). Cloudflare's own post, Russian Internet users are unable to access the open Internet, describes Russian ISPs limiting connections to its network so that a visitor receives roughly the first 16 KB of each asset and then nothing. A small HTML page may render; scripts, stylesheets, images and API responses stall. Cloudflare reports that this happens regardless of protocol and that it cannot fix it from its side.
- Blocking of TLS Encrypted Client Hello (since November 2024). ECH hides the site name during the TLS handshake. Russian filtering equipment cannot see which site such a connection is for, so it drops the connection outright. Cloudflare enabled ECH by default on many zones, so sites went dark without their owners changing anything.
On top of that, Roskomnadzor (RKN), the Russian regulator, has publicly advised Russian site owners to stop using foreign CDNs, including Cloudflare. That is a recommendation, not a prohibition, but it tells you which way the policy is moving. Cloudflare keeps a status note for affected customers at Potential disruption of services for Russian users.
So "Cloudflare is banned in Russia" is inaccurate, and so is "everything works as before". For a site owner, the useful statement is this: if your Russian traffic goes through Cloudflare IP addresses, assume it is degraded until you have measured otherwise from inside Russia.
Was Cloudflare blocked in Russia in 2022?
No. In 2022 Cloudflare chose to keep serving Russian users while complying with sanctions, and its network stayed reachable. The trouble started in 2024 with the ECH block and grew into systematic throttling in 2025. Both are measures taken inside Russian networks; Cloudflare did not withdraw its service.
Why a site behind Cloudflare fails to load from Russia
Several different faults share one symptom, "the site does not open from Russia", and each needs a different fix. Work out which one you have before you change anything.
| What Russian visitors see | Likely cause | How to confirm | What the owner can do |
|---|---|---|---|
| HTML starts loading, then the page hangs; big files never finish; small pages sometimes work | Throttling of Cloudflare IP ranges (16 KB cut-off) | A download from a Russian vantage point stalls at about 16 KB and times out | Serve Russian traffic from addresses outside Cloudflare's ranges |
| Connection resets or times out during the TLS handshake; nothing loads at all | ECH connections dropped | The domain's HTTPS DNS record contains an ech= parameter | Turn ECH off for the zone |
| Down on some Russian ISPs, fine on others; registry check is clean | Shared Cloudflare IP also used by a blocked resource | Your domain is not listed, but the edge IP it resolves to is | Dedicated IP, configuration change or another provider |
| The ISP's "access restricted" page on every Russian network | Your own domain is in the Russian blocklist | Registry check returns a match for the domain | Follow the owner's process for delisting |
| A Cloudflare error page (1020, 1015) or endless challenges | Your own WAF, rate-limit or country rules | The page shows a Cloudflare error code and a Ray ID | Fix or remove the rule in your dashboard |
Throttling of Cloudflare IP ranges
This is now the most common cause and the one owners misdiagnose most often, because the site is not "down" in the usual sense. The TCP and TLS handshakes complete, the first bytes arrive and the browser shows a spinner. An uptime check that only fetches a small page from outside Russia reports 200 OK all day. The throttling is applied inside Russian networks by DPI equipment (the TSPU system); see how TSPU and DPI throttling work for the mechanics.
No Cloudflare dashboard setting fixes this, because the trigger is the destination address, not a feature. Turning ECH off, switching to HTTP/2 or disabling HTTP/3 does not help. The only lever you control is where Russian visitors connect to.
TLS ECH
ECH (Encrypted Client Hello, specified in the IETF TLS ECH draft) encrypts the start of the TLS handshake, including the server name (SNI). Filtering systems can no longer tell which site a connection targets, so such connections are dropped in Russian networks. Browsers learn that a site supports ECH from the HTTPS record in DNS, which is why the check below works.
To turn it off, go to SSL/TLS → Edge Certificates → Encrypted ClientHello (ECH) in the Cloudflare dashboard. Where the toggle is not shown, the zone setting is also available through the API; Cloudflare documents both routes on its ECH page. With ECH off, browsers fall back to plain SNI. Treat this as necessary but not sufficient: since June 2025 the throttling still applies to the same connections.
Shared IPs with blocked resources
Cloudflare serves many sites from shared anycast addresses. If a resource that is blocked in Russia ends up on the same address, some ISPs block the IP as a whole and your site goes with it, even though your domain is on no list. The symptom is patchy: unreachable on some networks, fine on others, clean registry status for the domain. The fixes are a dedicated IP on higher plans, a configuration change that moves you to different edge addresses, or another provider for Russian traffic.
Your own domain is in the registry
Sometimes Cloudflare is not the problem at all: the domain itself has been added to the Russian blocklist. Check it in a minute with the registry check tool; the guide on checking Russian registry blocks explains how to read the result, and the owner's guide for blocked sites covers what to do next.
Access errors caused by Cloudflare itself
The reverse also happens: Cloudflare turning Russian visitors away on your behalf, with error 1020 (Access Denied), 1006–1008, rate-limit errors or endless challenges caused by strict firewall or country rules. A rule written years ago, such as (ip.src.country eq "RU") with a Block or Managed Challenge action, is easy to forget. Search your custom rules for that expression before blaming the network. For diagnosis and fixes, see Cloudflare error 1020.
How to check whether your site is reachable from Russia
You cannot judge Russian reachability from a laptop in Berlin or New York; the throttling only exists on Russian networks. Use checks that run from inside the country and look at more than the status code.
- Registry status. The RKN check tests your domain and IP against the Russian blocklist. Rule this out first, since no infrastructure change fixes a listed domain.
- Headers and availability. The HTTP header checker shows whether the response comes from Cloudflare (
server: cloudflare, acf-rayheader), the status code and the time to first byte. - Monitoring from a Russian region. enterno.io uptime monitors can run from the ru-msk region, so they see your site the way a Russian visitor does and catch problems that are invisible from abroad. Plans are on the pricing page. Point one monitor at a large static asset (a JS bundle or a hero image), not only the home page, so a 16 KB stall shows up as a timeout.
- Mass-outage tracking. The outage tracker helps you tell a problem with your domain apart from a mass Cloudflare or ISP incident.
From any Linux or macOS shell, these commands tell you whether a domain is behind Cloudflare and whether it advertises ECH:
# Is the response served by Cloudflare? curl -sI https://example.com | grep -iE '^(server|cf-ray):' # Which addresses does the name resolve to? Compare with https://www.cloudflare.com/ips/ dig +short A example.com dig +short AAAA example.com # Does the zone advertise ECH? Look for "ech=" in the answer dig +short HTTPS example.com
If you operate a server or monitoring node located in Russia, this test separates throttling from a real outage. A healthy connection downloads the whole file; a throttled one stops at around 16 KB and hits the time limit (curl exit code 28):
curl -s -o /dev/null --max-time 20 \
-w 'code=%{http_code} bytes=%{size_download} time=%{time_total}\n' \
https://example.com/assets/app.js
echo "exit=$?"
The IP ranges Cloudflare announces are published at cloudflare.com/ips. The Cloudflare Radar dashboard shows country-level traffic trends, which helps you see whether a drop is yours or network-wide.
Measure before you migrate. Turn ECH off, add a monitor from a Russian region on a large asset, and watch it for 48 hours. If the asset completes, your problem was ECH or a rule. If it stalls at the same size every time, it is throttling, and no dashboard setting will fix it.
How to get rid of Cloudflare blocking for your Russian visitors
Once you know the cause, the options come down to one question: should Russian visitors keep connecting to Cloudflare addresses or not? The table compares the realistic choices.
| Option | Fixes ECH drops | Fixes the 16 KB throttling | What you give up | Effort |
|---|---|---|---|---|
| Keep Cloudflare, turn ECH off | Yes | No | Nothing noticeable | Minutes |
| Switch key records to DNS only (grey cloud) | Yes | Yes, if the origin is not on a throttled network | Cloudflare caching, WAF and DDoS protection; the origin IP becomes public | Low, but risky |
| Split by geography: Russian visitors go to a separate origin or CDN | Yes | Yes | Two delivery paths to maintain and keep in sync | Medium |
| Separate domain for the Russian audience (for example a .ru site) | Yes | Yes | A second site to run; SEO signals split between domains | Medium to high |
| Move the whole site off Cloudflare | Yes | Yes, if the new provider is not throttled | Cloudflare features for all visitors | High |
DNS only. Switching a record's proxy status from Proxied to DNS only makes it resolve to your origin's address instead of Cloudflare's. That removes the Cloudflare hop, but it also exposes the origin to direct attacks and scans, and it only helps if the origin itself is reachable from Russia. Foreign hosting and cloud providers have faced similar restrictions, so test the origin from a Russian vantage point first.
Geo split. A DNS provider with geolocation-based answers (for example Amazon Route 53 geolocation routing, or Cloudflare Load Balancing in DNS-only mode with geo steering, where your plan includes it) can return a Russia-hosted address to Russian resolvers and Cloudflare to everyone else. The Russian path needs its own TLS certificate, caching and DDoS protection. Keep the content deployment identical on both paths, or you will debug "works for me" reports for months.
Risks for owners with a Russian audience
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Throttling of Cloudflare IP ranges | High, observed since June 2025 | Pages hang, assets and API calls fail | Serve Russian traffic off Cloudflare addresses; monitor a large asset from ru-msk |
| ECH connection blocking | High, observed since November 2024 | Nothing loads from Russia | Turn ECH off, monitor from ru-msk |
| Shared IP with a blocked resource | Medium | Down on some networks despite a clean registry status | Dedicated IP, configuration change or another CDN |
| Your own domain added to the registry | Depends on content | ISP-level blocking everywhere in Russia | Regular checks via RKN check |
| Tighter regulation of foreign CDNs | Hard to estimate | Forced migration on short notice | Migration plan ready, TTLs lowered in advance |
| Higher latency on routes from Russia | Low to medium | Slow pages, lost conversions | Response-time monitoring from ru-msk |
If Cloudflare became completely unreachable from Russia, a site that depends on it would stay dark for Russian visitors until DNS and traffic were moved elsewhere. The real insurance is preparation: lowered TTLs, an exported zone, a chosen fallback provider and monitoring that shows the problem the hour it starts.
Cloudflare alternatives for a Russian audience
No Russian provider replicates Cloudflare's full bundle (CDN, DNS, WAF and DDoS protection in one panel), but the individual pieces are covered:
- Selectel: CDN and DDoS protection within a broader cloud platform; a fit if your infrastructure already lives with a Russian provider.
- EdgeCenter: a Russian CDN with DDoS protection and a WAF; feature-wise the closest to the familiar "CDN plus protection" model.
- VK Cloud: CDN as part of the VK cloud ecosystem; makes sense for projects using its other services.
- Yandex Cloud CDN: CDN inside Yandex Cloud, integrated with its load balancers and object storage.
There is also standalone DDoS protection from Russian providers, deployed in front of your origin without moving the whole site to a CDN. And an honest third option: a small site serving mostly Russian visitors may not need a CDN at all; fast local hosting plus good caching often does the job. See what a CDN is for when you actually need one. Before signing with any provider, run the 16 KB test above against a test subdomain on their network.
How to migrate away from Cloudflare
- Lower DNS TTLs to 300–600 seconds 24–48 hours before the move.
- Export the DNS zone from Cloudflare and verify completeness: A/AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), SRV. A lost MX record is the classic "email died after migration" cause. Snapshot the current records with a DNS check.
- Deploy the zone at the new DNS provider and confirm it answers correctly, by querying its name servers directly, before switching NS.
- Change the NS servers at your registrar. Delegation updates take anywhere from minutes to 24–48 hours.
- Reissue TLS certificates. Cloudflare edge certificates and Cloudflare Origin CA certificates only work behind its proxy; browsers do not trust Origin CA certificates directly. Install a publicly trusted certificate on the new edge or origin and verify the chain with an SSL check.
- Monitor in parallel for 1–2 weeks from both Russian and international regions: some resolvers will serve stale data for a while.
# Before the move: snapshot the current state dig NS example.com +short dig A example.com +short dig MX example.com +short # After the NS change: confirm delegation updated dig NS example.com +short @8.8.8.8 dig NS example.com +short @77.88.8.8 # Confirm the A record points to the new origin dig A example.com +short @8.8.8.8
Change NS early in the work week and keep the old Cloudflare zone alive for at least two weeks after the move: until resolver caches expire, part of your traffic will still follow the old records, and those must keep working.
Site owner's checklist
- Check your domain and IP against the Russian registry via the RKN check.
- Search your Cloudflare custom rules for country conditions on RU.
- Turn TLS ECH off in the Cloudflare dashboard (SSL/TLS → Edge Certificates).
- Monitor availability from a Russian region (ru-msk), including one large static asset, not only from abroad.
- Decide how Russian visitors should be served: via Cloudflare, DNS only, a geo split or a separate provider.
- Snapshot your DNS records via DNS check and keep a zone export.
- Verify the SSL chain via SSL check after any configuration change.
- Lower key DNS TTLs to 300–600 seconds so you can migrate fast.
- Pick a fallback CDN or anti-DDoS service and test it on a subdomain in advance.
- Watch mass outages on the outage tracker and keep the migration plan documented.
FAQ
Why is Cloudflare suddenly blocked?
For Russian visitors, usually because of one of two network measures: since November 2024, TLS connections using ECH are dropped, and since June 9, 2025, connections to Cloudflare addresses are throttled after about 16 KB. Neither needs any change on your side to start. Outside Russia, a sudden block is more often your own WAF or rate-limit rule.
Is Cloudflare completely blocked in Russia?
No. There is no formal ban, and TCP and TLS connections to Cloudflare still open. But with throttling in place, most real pages cannot finish loading, so for a typical site the practical effect is close to a block.
Will disabling ECH help?
It fixes connections that were being dropped because of ECH, so do it. It does not remove the 16 KB throttling, which applies to Cloudflare addresses regardless of ECH. If a large asset still stalls from a Russian vantage point, you need to change where Russian traffic connects.
How to get rid of Cloudflare blocking?
As a site owner: rule out the registry and your own firewall rules, turn ECH off, then serve Russian visitors from addresses outside Cloudflare's ranges with DNS only, a geo split or another provider. As a visitor seeing a Cloudflare error page, the block comes from that site's settings, and only its owner can change them.
Why is Russia blocking internet access?
The regulator restricts foreign infrastructure and technologies that hide which site a user is visiting, and it has told Russian site owners to move away from foreign CDNs. ECH hides the destination, and Cloudflare carries a large share of foreign web traffic, so both are targets.
Is it legal to keep using Cloudflare for a Russian audience?
Yes. The regulator's advice to move away from foreign CDNs is a recommendation, not a prohibition; no liability is defined for simply using Cloudflare. It is, however, a signal worth factoring into planning.
