Translated material
The mechanism for bypassing Telegram blocking in Russia is working worse and worse. Analysis #9
How is this text structured?
What is this section?In the “Greenhouse Analysis” section, we understand a specific problem, Internet censorship news in real time and tell:
- what's happening;
- how it works;
- how can you fight this
Any thoughts on the topic? Share with us! Fill out a short form and tell us what you think about the new restrictions and how you can minimize the damage to VPN operators and ordinary users.
Briefly
At the end of May 2026, massive failures of the MTProto proxy were recorded in RuNet. Services through which users bypassed Telegram restrictions stopped working almost simultaneously for all operators. Code Durov reported on May 27 an “unprecedented” number of complaints; problems were recorded throughout the country, regardless of the operator and region.
A similar situation was observed in April, but the scale of blocking at the end of May was much wider. The fundamental difference: TSPUs switched to analyzing traffic characteristics instead of checking specific IP addresses and ports.
Mechanism
Editorial research: MTProxy performance, May 2026
We collected data on the performance of MTProxy in 4 regions and 6 networks from May 27 to May 31. Of the 27 tested configurations, three turned out to be working.
| Rostov-on-Don | DOM.RU | Home | 11 | 1 |
| Rostov-on-Don | Megaphone | Mobile | 11 | 1 |
| Moscow region | MTS | Mobile (4G) | 4 | 0 |
| Moscow region | Infolink | Home | 4 | 0 |
| Ekaterinburg | YOTA | Mobile (4G VoLTE) | 4 | 0 |
| Novosibirsk | Electronic city | Home | 4 | 2 |
What we noticed
Working proxies were only in the networks of regional providers. On federal operators (MTS, YOTA), none of the eight tested proxies established a connection. The same proxy trump.chunkycorp.shop:443 from the @ProxyMTProto channel (11.7 million subscribers) did not pass through YOTA in Yekaterinburg and passed through the network of the Electronic City operator in Novosibirsk. On federal networks, the updated TSPU rules were applied faster than those of regional providers.
Three more observations
- Non-standard ports (853, 8443, 7980, 44300) did not provide an advantage: they were blocked along with 443.
- Fake-TLS (ee-secrets) did not save on federal networks.
- A ping of 778 ms for one of the working proxies indirectly indicates that the server is probably located in Europe: the Russian hosting infrastructure is increasingly being “cut” entirely according to ASN.е.
Our sample is small (n = 27, 6 networks, 4 regions) and does not claim to be strictly representative; This is a cross-section, not a national measure. Estimates from other publications differ. “The Durov Code” qualifies the scale as record-breaking; Meduza records that most VPNs continued to work at the time of the failure. Our data is closer to the assessment of the Durov Code in relation to MTProxy: the failure affected MTProxy, and not all bypass tools at the same time.
You can reproduce measurements in your network through OONI Probe; it has a ready-made Telegram test, and the results are published in an open database linked to the operator’s ASN.
History of restrictions
Level 1. Blocking by IP addresses and ports (until 2025)
Basic filtering method: adding Telegram servers to the registry of prohibited IP addresses. This approach was followed during the 2018–2020 lockdown period.
MTProxy was developed as a tool for bypassing IP blocking: Telegram updated addresses faster than RKN could add them to the registry.
Level 2. Detection using TLS fingerprint (March–April 2026)
MTProxy uses the Fake-TLS mechanism: traffic is turned so that the beginning of the connection looks like a TLS 1.3 handshake to a legitimate domain. TSPU identified such traffic as HTTPS and passed the connection.
In March 2026, according to Digital Report , TSPU received updated rules based on the analysis of JA3/JA4 fingerprints (hashes from TLS ClientHello parameters). Real Chrome generates a ClientHello with a specific set of cipher suites, extensions, and elliptic curves in a specific order. Telegram's implementation of Fake-TLS did not comply with this set: the system began to mark connections where ClientHello is declared by Chrome, but the JA3 hash does not match any real version of the browser. On April 1, proxies “got up” all over the country simultaneously; Habr wrote about this wave.
Level 3. Statistical analysis of signatures (May 2026)
JA3 detection has a limitation: the fingerprint can be reproduced. Knowing the exact hash of the latest version of Chrome, you can generate an identical ClientHello. Proxy developers took this approach in April.
Then TSPU switched to statistical analysis of traffic, which is more difficult to simulate. The behavior of the entire stream is analyzed, not individual packets:
- packet size distribution (MTProto transmits data in blocks of predictable size);
- timings between packets (uniform intervals without variations are not typical for real HTTP/2);
- concentration of connections to one node.
It is possible that RKN simultaneously moved from blocking individual IPs to blocking entire ASN subnets and began to restrict TCP traffic without the characteristic features of standard protocols; this information has not been directly confirmed in major publications. As Meduza writes, the blocking affected not only MTProto, but also VLESS, WireGuard, XTLS/XHTTP, gRPC and partially Hysteria. The degree of impact varied by protocol, configuration, and operator: some connections on these protocols continued to work where MTProxy stopped completely.
The systematic nature of the escalation is evidenced by budget data. About 40 billion rubles are allocated in the federal budget for the automated Internet security system (ASBI), which manages the TSPU: 20 billion in 2026 and the same amount in total for 2027–2028. Another 2.3 billion has been allocated for an AI traffic analysis system. Official target: 92% effectiveness in blocking circumvention tools by the end of 2030, according to Forbes Russia .
Client application: Fake-TLS errors in Telegram Desktop
When the proxies went down on April 1, Telegram did not issue any official fixes; The community took over the analysis. Habr writes that enthusiasts intercepted the TLS handshake of real Chrome and the Telegram handshake and alternately changed the packet fields on the live network until they found a detectable signature. During the day, two specific bugs were discovered:
- First: the code used extension identifier 0xFE02, which is not in the specifications, instead of the correct codepoint 0xFE0D (ECH).
- Second: the public key X25519 was declared with a length of 32 bytes, and was generated with a length of 20, although according to the specification it always takes exactly 32. Both facts are confirmed by similar corrections in mobile clients .
The findings were submitted in Pull Request #30513 to tdesktop, but the admin with the nickname john-preston transferred this request to the status in this form. The specific changes ended up being released as a separate commit without any public explanation from the team.
However, the problem was fixed only in the Desktop client. The iOS client, Android client and all applications on tdlib are still detected using the same signatures; PR for mobile platforms remains in the works at the time of writing. Behind the two fixed bugs there is a list of unclosed behavioral signatures that cannot be eliminated by editing the JA3/JA4 parameters.
The thesis “Telegram was idle, and the community fixed everything” is disputed in PR thread #30513 by maintainer ilya-fedin: Telegram did the main work on ClientHello last year, making an error in two lines; Community research helped find the bug, but the proposed changes were crude. In general, Telegram made a major fix before the blocking, research was carried out by the community after, the PR was rejected, the commit with the edit appeared without official support.
Learn more about the identified issues(click to open table)
| Fixed length of the entire ClientHello (padding to exactly 513 bytes) | Critical |
| ECH-payload with a fixed length for the entire application lifecycle | Critical |
| After the handshake h2 is declared, but MTProto comes without HTTP framing | Critical |
| Legacy ALPS codepoint from Chrome 115 era | High |
| Darwin branch: cipher suites, removed by Apple back in 2021 | High |
| Smooth inter-packet timings without jitter | High |
Server application: status of the official MTProxy repository
In addition to client errors, the official MTProxy server part was structurally degraded.
The last commit in the repository ( cafc338 ) is dated November 4, 2025: by May 2026, six months without updates with 50 commits over the eight years of the project’s existence. In 39 open pull requests, the story of a crash bug with PID > 65535 is indicative: three participants independently fixed it (PR #653 , #669 , #673 ), and not a single one received a response. Of the 296 open issues , reports of crashes and complete inoperability remain unanswered; Among the 39 open pull requests, none received a response.
Docker images have become a separate symptom. The official telegrammessenger/proxy repository keeps tags in a fundamentally different state:
- The latest tag has not been updated for about six years and contains a binary without Fake-TLS support: it runs, but is completely detected by modern DPIs.
- The 2.0beta tag, released in April 2026, on the contrary, does not start at all: the startup script accesses the ip command from the iproute2 package, which is not in the base image; A request from users regarding this issue remained unanswered. The result is literal: only what is detected is launched, and what is not detected is not launched.
MTProxy is built on a closed specification: what to change and in what time frame is decided solely by one company. Unlike VLESS/XTLS or sing-box, where changes are made by a distributed community, MTProxy changes go through an internal process of a single vendor.
What did Roskomnadzor say and what did Telegram say?
- Roskomnadzor reported that access to VPN protocols is available to the necessary organizations upon request and that the list of exceptions already includes more than 57 thousand addresses and subnets of 1,730 organizations, including development companies. The agency does not dispute the scale of the restrictions, but describes the “white list” mechanism: filtering works by default, access is granted upon request.
- Telegram has not publicly commented on this topic; all visible reaction boiled down to edits in the repositories, and incomplete ones at that. Pavel Durov wrote on April 4, 2026 that the messenger team will continue to adapt traffic, making it more difficult to detect and block. Durov did not provide any details.
What to do?
Alternative implementations of MTProxy
Against the backdrop of non-working official images, the community supports at least nine independent implementations of MTProxy (in Go, Rust, Zig, Python). Full comparison and recommendations for selection: telemt , mtproto.zig , teleproxy , 9seconds/mtg , alexbers/mtprotoproxy , Flowseal/tg-ws-proxy .
The official project is lagging behind by an order of magnitude. Where MTProxy has accumulated 50 commits in eight years and stands without updates for six months, active alternatives release releases days before they are written about. Telemt (Rust) is especially indicative: it not only supports all MTProto modes, but is also accompanied by a fork of the official tdlib-obf library, which closes exactly those signatures in the client that have not been officially fixed in tdlib (ClientHello profiles for different browsers, Dynamic Record Sizing, obfuscation of inter-packet intervals). This is the only alternative that covers the server and client at the same time.
Teleproxy stands out separately: it is the only implementation where every claim about DPI stability is backed up by an automatic test in CI, from calculating the JA3 hash to Shannon entropy in encrypted packets. In parallel, there are automatic proxy collectors with updates every 12 hours and channels with tens of millions of subscribers; they compensate for the instability of individual addresses, but do not solve the problem of detecting the protocol itself.
Separately, the community released a fork of the Telegram desktop client for Windows , in which a unique ClientHello is generated instead of an almost identical one each time you connect to a proxy server; this makes detection via DPI difficult. The tool is only available for Windows and is not included in the official client. The functionality of the fork has not been independently verified. The editors have not conducted an audit and cannot recommend it.
Recommendations for developers
The MTProxy story is an example of how a proprietary, single-vendor specification cannot keep up with the pace of a regularly updated discovery infrastructure. A tool with an open specification and distributed support gets fixed faster than regulators can update rules. This is confirmed by the examples telemt, teleproxy and mtproto.zig.
On the technical side, May 2026 data points to three priorities.
- Complete closure of detected signatures, not just the JA3/JA4 fingerprint. The table in the “Client Application” section shows that L7 level signatures (mismatch between the declared ALPN and the real protocol, fixed ClientHello padding, outdated cipher suites) remain unclosed in official clients and provide a reliable detection point regardless of TLS parameters.
- Behavioral obfuscation at the traffic level: Dynamic Record Sizing and inter-packet interval variation eliminate statistical signatures that fingerprinting is powerless to combat.
- Automated testing of DPI stability in CI. The approach implemented in teleproxy : testing the JA3 hash, Shannon entropy and DRS in each commit allows you to detect regressions before they get into production.
Changing transport: universal proxy protocols
MTProxy and its forks are tied to Telegram: they mask MTProto traffic and do not work with other applications. The protocols below are universal proxy tunnels that do not depend on a specific application. They are deployed as a full-fledged exit node and pass any traffic. Switching to them means changing the architecture, not just replacing the tool.
All options require your own VPS outside of Russia. The listed protocols also experienced pressure from the TSPU in May 2026, but the degree and prevalence of blocking is lower than that of MTProxy.
VLESS+Reality until the end of May 2026 showed the lowest documented level of detection: TSPUs receive the correct ClientHello with real SNI and cannot distinguish the connection from legitimate HTTPS during signature analysis. However, since the end of May, it is Reality-based configurations that have been recording failures in a number of networks, which indicates a transition to statistical or ASN-level detection methods.
AmneziaWG randomizes the headers and first bytes of a WireGuard connection, making the traffic indistinguishable from random UDP. It is relevant now because the standard WireGuard is already blocked by signature, and the fork deprives the filter of a reliable detection point at the packet level.
Hysteria2 on top of QUIC transfers traffic to UDP, transferring the analysis to the transport layer, for which the TSPU has accumulated fewer heuristics. The protocol is documented to update obfuscation algorithms in response to GFW detection methods, confirming support activity.
NaiveProxy uses the HTTP/2 stack of the Chromium browser itself: the traffic is generated not by the proxy client, but by the real browser engine, so the behavioral characteristics (timings, packet sizes, frame order) coincide with legitimate Chrome. It is fundamentally difficult to block it without blocking Chrome itself.
TUIC runs on top of QUIC and is focused on minimal latency when establishing a connection; multiplexing requests in one QUIC stream complicates the correlation analysis of traffic. Well suited for environments where Hysteria2 has already been targeted for blocking.
Trojan imitates a TLS connection to a real web server: with active probing from the TSPU, the server returns a real web page. This makes detection difficult through active probes, which are increasingly being used in conjunction with passive traffic analysis.
Mieru was designed specifically for environments with strict filtering: it carries no fixed headers, packet sizes and timings are randomized, and there is no identifiable handshake. It is inferior to others in terms of throughput, but is resistant to statistical analysis for small volumes of traffic.
All three MTProxy detection levels were applied sequentially. Moreover, the detection of the second and third levels is separated by only two months (March–May 2026).
MTProxy has problems fixing detections. On the client, the fix only reached Desktop; mobile platforms carry the same signatures; on the server, the official binary is non-functional, and the only vendor does not respond to community edits. The limitations are not technical, but organizational in nature: closed specification, single point of support, slow release cycle.
The pressure on evasion tools has not been limited to MTProxy. In May, VLESS, WireGuard, XTLS/XHTTP, gRPC and Hysteria were partially blocked; VLESS+Reality configurations, previously considered the most stable, have been experiencing failures since the end of May. The community has released a fork of the Telegram desktop client with a claimed bypass of detection, but its functionality has not been verified.
None of the protocols reviewed are immune to blocking: the degree of impact varies by configuration, operator, and region. At the time of writing, the greatest stability is shown by tools with an open specification, distributed support and automated testing of DPI stability: telemt, teleproxy, mtproto.zig within MTProto; AmneziaWG, Hysteria2, NaiveProxy, TUIC, Mieru and Trojan beyond. A common symptom: the rate of updates is higher than the frequency of changes in detection rules.
Sources
Media
Greenhouse analysis
- “Roskomnadzor wants to block almost all VPNs. Or not? And what should I do? Analysis #6 .
Data from GitHub and Telegram publications
The material is being updated!
Any thoughts on the topic? Share with us! Fill out a short form and tell us what you think about the new restrictions and how you can minimize the damage to VPN operators and ordinary users.