Ux Uptrixia Monitor
iGaming · Russia

My casino site is up but Russian users can't reach it — what's happening?

Published 2026-05-27 · 9 min read

TL;DR

The domain is almost certainly on the Roskomnadzor Unified Register. Russian ISPs are legally required to enforce it via DNS poisoning, IP blocks, and DPI filtering through TSPU equipment. The origin is fine — a datacenter probe still gets 200 — but Russian users on MTS (AS8359), Rostelecom (AS12389), Beeline (AS3216), and MegaFon (AS31133) see a block page. Verify by checking from all four carriers; if 3+ are red while a datacenter probe is green, you have a confirmed Russia-specific block. Pause RU sources and rotate to a fresh mirror.

The signature

  • EPC from Russia collapses suddenly across all sources, not just one.

  • Russian affiliate partners report "the site doesn't open" — first from MTS Mobile users, then from Rostelecom users.

  • The origin server, when checked from AWS Frankfurt or any non-RU probe, returns a clean 200.

  • Inside Russia, the DNS resolves to a different IP than expected, or doesn't resolve at all, or resolves correctly but the TCP connection is reset mid-handshake.

  • Synthetic uptime monitors (Pingdom, UptimeRobot) stay green throughout.

How Roskomnadzor enforces a block

Roskomnadzor maintains the Unified Register of Banned Information, which all Russian ISPs are legally required to consume and enforce. The Register is updated continuously, and large carriers poll it every few hours.

Enforcement uses three mechanisms in combination:

  • DNS-level filtering. The carrier's resolver refuses the lookup, returns NXDOMAIN, or returns the IP of a regulator block page.

  • IP-level blocking. Traffic to the origin's IP is dropped or sent to a null route at the carrier's edge router.

  • DPI via TSPU. Since the 2019 "sovereign internet" law, ТСПУ (Technical Means of Counteracting Threats) equipment installed at major IXPs inspects TLS SNI, HTTP Host headers, and other metadata to block by pattern even when DNS and IP are intact.

Different carriers apply these in different proportions, which is why the failure mode looks different on MTS vs Rostelecom vs Beeline. MTS tends toward DNS poisoning and TSPU; Rostelecom relies heavily on DNS + IP block; smaller carriers may show only DNS-level interference. The practical implication: a single mechanism check (only DNS, only IP) misses real blocks. Check status + DNS + final URL + screenshot per carrier.

How to verify the block (step by step)

  1. 1

    Confirm the origin is up from a datacenter probe. If a cloud probe from outside RU gets 200, the server is fine — the issue is between the Russian carrier and the origin.

  2. 2

    Check from all four major Russian carriers. MTS (AS8359), Rostelecom (AS12389), Beeline (AS3216), MegaFon (AS31133). Use real residential and mobile ASNs inside Russia.

  3. 3

    Capture status, DNS result, final URL, and screenshot per carrier. The RKN block looks different per mechanism — DNS error / connection reset / ISP-branded block page.

  4. 4

    Compare against a check from outside Russia. Same URL, same minute. Outside RU: 200. Inside RU on 3+ carriers: blocked. That asymmetry is the proof.

  5. 5

    Pause Russian traffic sources and rotate to a clean mirror. Treat Russia as its own rotation pool — do not share domain history with KZ or BY mirrors.

  6. 6

    Set per-carrier RU alerts continuously. Catch the block at the moment Roskomnadzor enforces, not when Russian affiliates complain.

Russian carrier reference

CarrierASN (primary)Typical mechanismEnforcement speed
MTSAS8359DNS poisoning + TSPUHours — fastest
RostelecomAS12389DNS + IP blockHours — fast (state-owned)
Beeline / VimpelComAS3216DNS + selective IPSame business day
MegaFonAS31133DNS + TSPUSame business day
Origin reachable from outside RU · blocked from all 4 major Russian carriers Same URL · same minute · datacenter probe vs 4 Russian carriers Origin returns 200 from outside RU. All 4 RU carriers return blocks — Roskomnadzor at the carrier layer. Datacenter probe AWS Frankfurt · eu-central-1 200 OK · landing page rendered · cf-ray present Conclusion: the origin is fine. Anything that fails on Russian carriers is happening between the carrier and the origin — not at the origin itself. Inside Russia · same URL · 4 major carriers MTS · AS8359DNS poisoned→ RKN landing page Rostelecom · AS12389IP block→ connection reset Beeline · AS3216DNS error→ ISP block page MegaFon · AS31133TSPU drop→ TLS handshake fails 4 / 4 Russian carriers blocked · datacenter probe clean→ Confirmed Russia-specific block (Roskomnadzor). Pause RU traffic sources. Rotate to a fresh RU mirror. Do not waste budget appealing — operate the rotation pool.
The asymmetry — datacenter green, all four Russian carriers red — is the unambiguous Roskomnadzor signature. Different mechanisms on different carriers all add up to the same outcome for the user. Numbers illustrative.

What to do — the iGaming Russia playbook

  1. 1

    Pause Russian traffic sources immediately. Continuing to buy clicks into a confirmed RU block is pure spend loss.

  2. 2

    Rotate to a fresh mirror from your RU pool. Switch DNS / tracking links to the new mirror. Verify it's reachable on all 4 carriers before resuming sources.

  3. 3

    Keep an evergreen mirror inventory. Pre-register fresh domains with diverse TLDs (.com, .net, country-neutral) on diverse hosting and CDN accounts. Rotate before death, not after.

  4. 4

    Set per-carrier alerts on every active mirror. Pause-on-2-of-4 is a safe trigger; pause-on-any-RU-carrier is paranoid but reasonable for mission-critical campaigns.

  5. 5

    Capture screenshots on every block. The dated history of which mirror lasted how long on which carrier is what tells you whether a TLD or a hosting pattern is being burned faster than the others.

  6. 6

    Don't waste cycles on appeals. For unlicensed iGaming, RKN appeals almost never succeed. The cost of an attempted appeal exceeds the cost of just rotating.

Related reading

For the RU-vs-KZ asymmetry, see my iGaming mirror works in RU but not in KZ. For the broader rotation playbook, see how to monitor rotating casino mirror domains. For status-code semantics, see what does HTTP 403 / 451 / 503 mean.

FAQ

Why is my casino site up but Russian users can't reach it?

Almost certainly because Roskomnadzor has added the domain to the Russian Unified Register of Banned Information. Russian ISPs are legally required to enforce that list — typically with DNS poisoning, IP-level blocks, and DPI filtering through TSPU equipment installed at IXPs. The origin server is still up, so a datacenter probe returns 200. But when a Russian user on MTS, Rostelecom, Beeline, or MegaFon requests the domain, the carrier intercepts the connection and serves a block page or drops the request. The signature is: clean from datacenter / outside RU, blocked across multiple Russian carriers.

What is Roskomnadzor and how does it block sites?

Roskomnadzor (RKN) is the Russian Federal Service for Supervision of Communications, Information Technology and Mass Media. It maintains the Unified Register of Banned Information, the authoritative blocklist that all Russian ISPs are required to enforce. Enforcement mechanisms include DNS-level filtering (the carrier's resolver refuses or rewrites the answer), IP-level blocking, and DPI-based filtering via TSPU (Технические Средства Противодействия Угрозам — equipment installed at major IXPs since the 2019 sovereign-internet law). Different carriers use different mechanisms in different proportions, which is why the block page and the failure mode can look different on MTS vs Rostelecom.

Which Russian ASNs do I need to check?

Cover the four major Russian carriers: MTS (AS8359), Rostelecom (AS12389), Beeline / VimpelCom (AS3216), and MegaFon (AS31133). Together they account for the overwhelming majority of Russian consumer traffic. MTS and Rostelecom enforce orders fastest; Beeline and MegaFon usually follow within the same business day. Mobile and fixed-line on MTS can also differ (MTS Fixed: AS43933) — for iGaming, mobile is usually the primary path.

How fast does Roskomnadzor enforce a new block?

A new domain added to the Register typically becomes unreachable on MTS and Rostelecom within hours of being added; Beeline and MegaFon usually within 24 hours; smaller regional ISPs within 48–72 hours. The Register is updated continuously, and ISPs poll it on a defined cadence. A fresh mirror often survives a few hours to a few weeks depending on TLD, hosting, redirect pattern, and how visible it is to regulator monitoring.

Can I appeal a Roskomnadzor block?

Formally yes — there is a process to request removal from the Register, typically through a Russian legal representative and the originating regulator or court that placed the block. In practice, for unlicensed iGaming / sportsbook domains, appeals are rarely successful because the underlying activity (offering gambling without a Russian license) is the actual issue. The working pattern for iGaming operators in Russia is mirror rotation — maintain a fresh mirror inventory and rotate when carriers go red.

How is the Russian block different from a Cloudflare block?

A Cloudflare block applies at the CDN edge and looks the same regardless of which country the user sits in — it usually shows a Cloudflare-branded challenge or 403 page with a cf-ray header. A Roskomnadzor block applies at the carrier level inside Russia: the user sees an ISP-branded or government-branded block page, the cf-ray header is absent, and a datacenter probe from outside Russia gets a clean 200. The screenshots make the distinction obvious.

Edits

  • 2026-05-27: First published.

Monitor your RU mirror across MTS, Rostelecom, Beeline, MegaFon

Per-carrier checks every 30 minutes with status, DNS, final URL, and screenshot proof. Catch Roskomnadzor enforcement at the moment it lands and rotate before the budget burns. Free trial includes 8 ASNs.

Start free trial Read: mirror rotation playbook