In late May 2026, a wave of MTProto proxy failures swept across the Russian internet. Services that users relied on to bypass Telegram restrictions stopped working almost simultaneously across all carriers. On May 27, Kod Durova reported an “unprecedented” volume of complaints. The disruptions were recorded nationwide, regardless of carrier or region.

A similar situation had occurred in April but the scale of the late-May blocking was significantly broader. The key difference was that TSPU (Russia’s “technical means to counter threats” — deep-packet inspection infrastructure operated by ISPs under Roskomnadzor’s direction) shifted from checking specific IP addresses and ports to analyzing traffic.

How It Works

Editorial study: MTProxy availability, May 2026

We collected availability data for MTProxy across 4 regions and 6 networks between May 27 and 31. Of the 27 configurations tested, three were functional.

Region	ISP	Connection type	Tested	Working
Rostov-on-Don	DOM.RU	Home broadband	11	1
Rostov-on-Don	MegaFon	Mobile	11	1
Moscow region	MTS	Mobile (4G)	4	0
Moscow region	Infolink	Home broadband	4	0
Yekaterinburg	YOTA	Mobile (4G VoLTE)	4	0
Novosibirsk	Elektronny Gorod	Home broadband	4	2

What we observed

Working proxies appeared only on regional carrier networks. On federal carriers (MTS, YOTA) none of the eight tested proxies established any connection. The same proxy — trump.chunkycorp.shop:443 from the @ProxyMTProto channel (11.7 million subscribers) — failed on YOTA in Yekaterinburg but worked on the Elektronny Gorod network in Novosibirsk. Updated TSPU rules were applied faster on federal networks than on regional carriers.

Three additional observations

• Non-standard ports (853, 8443, 7980, 44300) offered no advantage: they were blocked just as consistently as port 443.
• Fake-TLS (ee-secrets) did not help on federal networks.
• A ping of 778 ms on one of the working proxies indirectly suggests the server is located somewhere in Europe: Russian hosting infrastructure is increasingly being cut by entire ASN.

Our sample is small (n = 27, 6 networks, 4 regions) and does not claim to be statistically representative. It is more a snapshot than a nationwide measurement. Assessments from other outlets differ. Kod Durova describes the scale as record-breaking; Meduza notes that most VPNs continued working at the time of the outage. Our data aligns more closely with Kod Durova’s assessment as applied to MTProxy specifically: the disruption targeted MTProxy, not all circumvention tools simultaneously.

You can replicate these measurements on your own network using OONI Probe. It includes a ready-made Telegram test, and the results are published in an open database with ASN attribution.

History of Restrictions

Level 1. Blocking by IP address and port (before 2025)

The basic filtering method involved adding Telegram servers to the banned IP address registry. This approach was used during the 2018–2020 blocking period.

MTProxy was designed specifically to bypass IP-based blocks. Telegram updated its addresses faster than RKN (Roskomnadzor, Russia’s federal communications regulator) could add them to the registry.

Level 2. Detection by TLS fingerprint (March-April 2026)

MTProxy used a Fake-TLS mechanism. Traffic was wrapped so that the start of the connection looked like a TLS 1.3 handshake to a legitimate domain. TSPU identified this traffic as HTTPS and let the connection through.

In March 2026, according to Digital Report, TSPU received updated rules based on JA3/JA4 fingerprint analysis (hashes derived from TLS ClientHello parameters). Real Chrome constructs a ClientHello with a specific set of cipher suites, extensions, and elliptic curves in a defined order. Telegram’s Fake-TLS implementation did not match this set. The system began flagging connections where the ClientHello claimed to be Chrome but the JA3 hash did not match any real browser version. On April 1, proxies went down across the country simultaneously. Habr covered this wave of blocking.

Level 3. Statistical traffic signature analysis (May 2026)

JA3 detection has a known limitation: the fingerprint can be reproduced. If you know the exact hash of a current Chrome version, you can construct an identical ClientHello. Proxy developers applied this approach in April.

TSPU then moved to statistical traffic analysis, which is harder to imitate. Rather than inspecting individual packets, the system analyzes the behavior of the entire flow:

• packet size distribution (MTProto transmits data in blocks of predictable size);
• inter-packet timing (uniform intervals with no variation are atypical for real HTTP/2);
• concentration of connections to a single node.

RKN may have simultaneously shifted from blocking individual IPs to blocking entire ASN subnets. The agency begun restricting TCP traffic that lacks the characteristics of standard protocols (though this has not been directly confirmed by major outlets). As Meduza reports, 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 carrier. Some connections over these protocols continued to work in cases where MTProxy had failed entirely.

The systematic nature of this escalation is reflected in budget data. The federal budget allocates approximately 40 billion rubles (about $532 million) to ASBI (the Automated Security System for the Russian Internet segment, which controls TSPU): 20 billion rubles (about $266 million) in 2026 and the same amount in total for 2027–2028. Additionally, 2.3 billion rubles (about $31 million) has been allocated to an AI-based traffic analysis system. The official target is 92% effectiveness in blocking circumvention tools by the end of 2030, according to Forbes Russia.

The client application: Fake-TLS bugs in Telegram Desktop

When the proxies went down on April 1, Telegram released no official fixes. Instead, the community took up the analysis. Habr reports that enthusiasts intercepted the TLS handshakes from both real Chrome and Telegram, then systematically swapped packet fields on a live network until they identified the detectable signature. Within 24 hours, two specific bugs were found:

• First bug: the code used extension identifier 0xFE02, which does not exist in any specification, instead of the correct codepoint 0xFE0D (ECH).
• Second bug: the X25519 public key was declared as 32 bytes but generated as 20 bytes — even though the specification requires exactly 32 bytes. Both findings are corroborated by identical fixes in the mobile clients.

The findings were submitted as Pull Request #30513 to tdesktop, but an admin with the username john-preston marked it as “in this form” (i.e., declined). The specific changes were eventually released as a separate commit with no public explanation from the team.

The fix, however, only reached the Desktop client. The iOS client, Android client, and all applications built on tdlib remain detectable via the same signatures. The PRs for mobile platforms were still open at the time of writing. Behind the two fixed bugs lies a longer list of unresolved behavioral signatures that cannot be addressed simply by patching JA3/JA4 parameters.

The claim that “Telegram did nothing while the community fixed everything” is disputed in the PR #30513 thread by maintainer ilya-fedin. He highlighted that Telegram had already done the bulk of the ClientHello work the previous year, introducing a bug in just two lines; the community’s research helped locate the bug, but the proposed patches were rough. In short: Telegram shipped a major fix before the blocking, the community conducted its analysis afterward, the PR was declined, and the corrective commit appeared without explanation.

The server application: state of the official MTProxy repository

Beyond the client-side bugs, the official MTProxy server has been deteriorating structurally.

The last commit in the repository (cafc338) is dated November 4, 2025. By May 2026, the project had gone six months without updates, having accumulated just 50 commits over eight years. Among the 39 open pull requests, the story of a crash bug triggered when PID > 65535 is telling: three separate contributors independently fixed it (PRs #653, #669, #673), and none received a response. Among the 296 open issues, crash reports and reports of complete non-functionality have gone unanswered. None of the 39 open pull requests has received a reply.

The Docker images have become a symptom of their own. The official telegrammessenger/proxy repository keeps its tags in fundamentally different states of disrepair:

• The “latest” tag has not been updated in approximately six years and contains a binary with no Fake-TLS support: it starts, but is fully detectable by modern DPI.
• The “2.0beta” tag, released in April 2026, does the opposite: it does not start at all. The startup script calls the ip command from the iproute2 package, which is absent from the base image. A user-filed issue about this has received no response. The practical result is literal: only what is detectable starts, and what is not detectable does not start.

MTProxy is built on a closed specification. One company decides unilaterally what to change and when. Unlike VLESS/XTLS or sing-box (where a distributed community contributes fixes), changes to MTProxy pass through a single vendor’s internal process.

Positions of Roskomnadzor and Telegram

• Roskomnadzor stated that organizations with legitimate needs can request access to VPN protocols by application, and that more than 57,000 addresses and subnets belonging to 1,730 organizations (including software developers) have already been added to the exceptions list. The regulator does not contest the scale of the restrictions but describes a “whitelist” mechanism: filtering applies by default, and access is granted on request.
• Telegram has made no public comment on the matter; its visible response has been limited to repository changes, and incomplete ones at that. On April 4, 2026, Pavel Durov wrote that the messenger’s team would continue adapting its traffic to make it harder to detect and block. Durov provided no further details.

Recommendations

Alternative MTProxy implementations

Against the backdrop of non-functional official images, the community maintains at least nine independent MTProxy implementations (in Go, Rust, Zig, and Python). For a full comparison and recommendations: telemt, mtproto.zig, teleproxy, 9seconds/mtg, alexbers/mtprotoproxy, Flowseal/tg-ws-proxy.

The official project lags by an order of magnitude. Where MTProxy accumulated 50 commits over eight years and has sat without updates for six months, active alternatives ship releases within days of being written about. Particularly noteworthy is telemt (Rust). It supports all MTProto modes and also ships with a fork of the official tdlib-obf library that closes exactly the client-side signatures that remain officially unpatched in tdlib: correct ClientHello profiles for different browsers, Dynamic Record Sizing, and inter-packet timing obfuscation. It is the only alternative that covers both server and client simultaneously.

Teleproxy deserves separate mention. It is the only implementation where every claim about DPI resistance is backed by an automated CI test (from JA3 hash computation to Shannon entropy in encrypted packets).

Alongside these tools, automated proxy aggregators running updates every 12 hours and channels with tens of millions of subscribers help compensate for the instability of individual proxy addresses — though they do not solve the problem of the protocol being detected in the first place.

The community has also released a fork of the Telegram Desktop client for Windows. It generates a unique ClientHello on each proxy connection instead of a near-identical one, making DPI detection harder. The tool is Windows-only and has not been incorporated into the official client. Its effectiveness has not been independently verified. We have not audited it and cannot recommend it.

Recommendations for developers

The MTProxy story is an example of how a closed specification with a single vendor fails to keep pace with a regularly updated detection infrastructure. A tool with an open specification and distributed maintenance gets patched faster than regulators can update their detection rules. The examples of telemt, teleproxy, and mtproto.zig confirm this.

On the technical side, the May 2026 data points to three priorities.

• Full closure of detectable signatures, not just JA3/JA4 fingerprints. The table in the “Client Application” section shows that L7-level signatures (mismatches between declared ALPN and actual protocol, fixed ClientHello padding, deprecated cipher suites) remain unpatched 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 timing variation eliminate the statistical signatures that fingerprint rotation cannot address.
• Automated DPI-resistance testing in CI. The approach implemented in teleproxy (testing JA3 hash, Shannon entropy, and DRS on every commit) catches regressions before they reach production.

Transport alternatives: general-purpose proxy protocols

MTProxy and its forks are Telegram-specific. They disguise MTProto traffic and do not work with other applications. The protocols below are general-purpose proxy tunnels, independent of any specific application. They are deployed as full exit nodes and route any traffic. Switching to them means a change in architecture, not just a change of tool.

All options require a VPS outside Russia. The protocols listed below also came under TSPU pressure in May 2026, but the degree and prevalence of blocking is lower than for MTProxy.

VLESS+Reality showed the lowest documented detection rate through late May 2026. TSPU receives a valid ClientHello with a real SNI and cannot distinguish the connection from legitimate HTTPS during signature analysis. However, from late May onward, Reality-based configurations have been experiencing failures on certain networks, suggesting a shift 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 standard WireGuard is already blocked by signature, while this fork removes the filter’s reliable packet-level detection point.

Hysteria2 over QUIC moves traffic to UDP, shifting analysis to the transport layer where TSPU has accumulated fewer heuristics. The protocol has documented a history of updating its obfuscation algorithms in response to GFW detection methods, confirming active maintenance.

NaiveProxy uses the HTTP/2 stack of the Chromium browser itself. Traffic is generated not by a proxy client but by a real browser engine. So behavioral characteristics such as timings, packet sizes, frame ordering match those of legitimate Chrome. Blocking it without blocking Chrome itself is fundamentally difficult.

TUIC runs over QUIC and is optimized for minimal connection establishment latency. Multiplexing requests within a single QUIC stream complicates traffic correlation analysis. It is well suited for environments where Hysteria2 has already attracted blocking attention.

Trojan mimics a TLS connection to a real web server. When TSPU performs active probing, the server returns a real web page. This makes detection via active probes harder. Active probing is increasingly being used alongside passive traffic analysis.

Mieru was designed specifically for high-filtering environments. It carries no fixed headers, packet sizes and timings are randomized, and there is no identifiable handshake. It is slower than the others in terms of throughput, but it is resistant to statistical analysis at low traffic volumes.

Conclusion

All three levels of MTProxy detection were applied in sequence with the gap of just two months (March-May 2026) between the steps two and three.

MTProxy has structural problems with addressing detection. On the client side, the fix reached only the Desktop version. Mobile platforms carry the same signatures. On the server side, the official binary is non-functional, and the sole vendor is unresponsive to community patches. These limitations are organizational rather than technical: a closed specification, a single point of maintenance, a slow release cycle.

Pressure on circumvention tools extended beyond MTProxy. In May, VLESS, WireGuard, XTLS/XHTTP, gRPC, and Hysteria were partially blocked as well. VLESS+Reality configurations, previously considered the most resilient, have been experiencing failures since late May. The community released a fork of the Telegram Desktop client claiming to bypass detection, but its effectiveness has not been verified.

No protocol covered in this analysis is immune to blocking. The degree of impact varies by configuration, carrier, and region. The tools showing the greatest resilience at the time of writing are those with open specifications, distributed maintenance, and automated DPI-resistance testing: telemt, teleproxy, and mtproto.zig within the MTProto ecosystem; AmneziaWG, Hysteria2, NaiveProxy, TUIC, Mieru, and Trojan outside it. Their update cadence is faster than the rate at which detection rules change.