Bypassing the Russian Federation's mobile internet whitelists—we're stuck, looking for real-world experience

Across three testers all on MTS, whitelist behavior varied by network segment in ways that could not be explained by protocol configuration alone; the operator has zero confirmed data for MegaFon, Beeline, or T2 under whitelist conditions. The open question of whether whitelist policy (site+IP list) is centrally issued by the Ministry of Digital Development while implementation differs per carrier remains unresolved, making cross-carrier generalization of any circumvention finding unreliable.

Issue body — questions 1 and 2 evaluation ip-blockingsni-blocking ru

During apparent whitelist-activation periods on MTS mobile LTE, the affected user experienced a complete network blackout in which even explicitly whitelisted resources (gosuslugi.ru) were inaccessible — behavior inconsistent with a standard default-deny CIDR+SNI whitelist, which should pass approved destinations unconditionally. The operator concludes this may represent a stricter enforcement variant, a SIM-specific restriction, or a mechanism entirely separate from the documented whitelist architecture.

Issue body — main mystery paragraph detection ip-blockingsni-blocking ru

Community-maintained public CIDR lists of Russian mobile whitelist ranges allow operators to identify specific whitelisted IP blocks within cloud providers: a /22 subnet inside Yandex Cloud's /16 pool appears on these lists, while the ephemeral addresses from a different /20 pool of the same provider do not. Reserving a static IP from the whitelisted /22 allows the Reality handshake to complete and traffic to proxy from external vantage points, though in-whitelist passage on a real mobile device remained unconfirmed at time of writing.

Issue body — Yandex Cloud architecture paragraph deployment ip-blocking ru

VLESS+Reality with uTLS and decoy SNI pointed at popular domains (vk.com, cloudflare.com) bypasses standard DPI blocking on MTS and has operated stably for one real user over several weeks with thousands of connections logged. However, an identical configuration failed to establish a single connection for a second user on the same carrier but in a different network segment (Moscow number vs. regional/southern number), including during periods confirmed to be outside whitelist activation.

Issue body — confirmed working / not working sections evaluation dpisni-blockingip-blocking ru