What Is MTProto? The Encrypted Path That Keeps Telegram Open.
Telegram is blocked where you are. Or your ISP has learned to identify and throttle it — slowing your signals exactly when markets move. MTProto is the protocol Telegram built to solve both.
It encrypts your connection end-to-end, stays persistent so messages push instantly, and with FakeTLS it looks like ordinary HTTPS to anyone inspecting your traffic. Your ISP cannot classify it. Your network cannot block it. Your signals get through.
This guide covers the full stack: what MTProto is, how it encrypts, why it gets throttled, how FakeTLS defeats that classification, and what a proxy actually does for your delivery.
What is MTProto, and why does it matter for signal delivery?
MTProto is the proprietary messaging protocol Telegram built from scratch. It uses a combination of AES-256, RSA-2048, and Diffie-Hellman key exchange — three cryptographic layers in a single persistent TCP connection. Unlike HTTPS, which opens and closes a new connection for each request, MTProto keeps a single long-lived channel alive. That persistence is what makes real-time signal delivery possible.
The problem: MTProto has a recognisable protocol fingerprint. ISP Deep Packet Inspection (DPI) systems classify that fingerprint and route the traffic into a lower-priority queue. During news events — NFP, CPI, FOMC — that queue means your signals arrive after the move, not before it.
FakeTLS wraps the MTProto connection in a convincing TLS 1.3 handshake. The DPI classifier sees ordinary HTTPS. It moves on. Your signal gets normal-priority delivery.
MTProto is included on Standard ($15/mo) and Pro ($25/mo) — see plans
The protocol Telegram built because HTTP wasn't fast enough.
In 2013, Telegram launched with a custom messaging protocol rather than building on top of standard HTTPS or WebSockets. That decision looked unusual at the time. The reasoning holds up well from a signal-delivery perspective.
HTTP is a request-response protocol. Your client sends a request. The server responds. The connection closes, or is briefly pooled. For loading web pages, this model works. For messaging — where the server needs to push a signal to your device the moment it's posted — it creates overhead on every delivery.
WebSockets improve this with persistent connections, but they were designed for browser environments and carry assumptions about network reliability that do not apply to mobile users in volatile-connectivity situations: signal rooms open during London open while riding the tube, terminals connected over hotel WiFi during FOMC week.
Telegram built MTProto for these conditions. A single persistent TCP connection that stays alive, reconnects fast, handles mobile network switches gracefully, and encrypts at the protocol level rather than relying entirely on the transport layer. For messaging at speed — which is what signal delivery requires — the architecture was a deliberate choice, not a vanity project.
The same properties that make MTProto good for signal delivery also make it identifiable to network classification systems. That identification is the root of the throttling problem this stack is designed to solve.
The network path of encryption in one connection.
MTProto's encryption model is worth understanding because it's one of the most common sources of confusion about proxy safety. Three distinct cryptographic components work together in every connection.
Used during the initial handshake to authenticate the server and securely negotiate the session keys. Your client verifies Telegram's server identity using a 2048-bit RSA key before any session data is exchanged. This prevents man-in-the-middle attacks at connection setup.
Once RSA authenticates the server, DH is used to derive the shared session key — a symmetric key that neither side transmits directly. Both client and server compute the same key independently. Even if the RSA handshake were intercepted, the session key cannot be extracted from the exchange.
All messages are encrypted with AES-256 using a custom Infinite Garble Extension (IGE) mode that propagates errors through the cipher — a modification that prevents certain padding attacks. The session key from the DH exchange drives this encryption throughout the session lifetime.
The practical consequence for traders: the MTProto proxy sits at the transport layer and routes encrypted bytes. It has no access to the plaintext of your messages. It cannot see what the signal said, who sent it, or what room it came from. The proxy is a routing node, not a decryption node.
This is different from a VPN, which tunnels your traffic but can, in principle, inspect it at the VPN endpoint. MTProto's end-to-end encryption in Secret Chats means even Telegram's own servers cannot read those. For standard cloud chats — the kind used by signal rooms — Telegram's servers can read the content, but the proxy cannot.
Persistent connections vs request-response: why it changes everything for entries.
The architecture difference between HTTP and MTProto is not a technical footnote — it determines whether a signal notification is delivered in 200 milliseconds or 8 seconds.
In a request-response model, your Telegram app would need to poll Telegram's servers for new messages. "Anything new?" — response — wait — "Anything new?" — response. Even with aggressive polling, you're adding round-trip latency to every message. And during a news event when the server is handling millions of simultaneous requests, that polling queue lengthens.
MTProto uses a server push model over a persistent connection. The channel between your device and Telegram's data centre stays open. When a message is posted in your signal room, Telegram pushes it over that open channel immediately — no polling, no connection setup overhead, no new handshake.
The connection setup in MTProto — RSA handshake, DH key exchange, session establishment — happens once when you open Telegram, not on every message. After that, delivery latency is network latency only.
This is why signal room traders care about MTProto specifically. The protocol is doing real work. The 200ms delivery window that separates a valid entry from a missed one exists only because the connection is persistent and the channel is already warm when the signal fires.
When that persistent connection gets throttled into a lower-priority queue by your ISP, the warmth of the channel doesn't help. The packets are sitting in the queue regardless of whether the connection is persistent. The solution is not a faster connection — it's getting out of the throttle queue entirely. That's what FakeTLS does.
MTProto 2.0: what the upgrade fixed and why it matters.
The original MTProto protocol — now called MTProto 1.0 — had documented weaknesses. Cryptographers identified theoretical vulnerabilities in the AES-IGE mode as implemented, and the padding scheme was imperfect. Telegram addressed this with MTProto 2.0, which is what all current Telegram clients use.
MTProto 2.0 made three meaningful changes. First, it replaced the SHA-1 hash function with SHA-256. SHA-1 has known collision vulnerabilities; SHA-256 does not under current attack models. Second, it added random padding to messages, which closes the class of padding-oracle attacks that could theoretically exploit the original scheme. Third, it adjusted the message key derivation to use more of the auth key material, making the relationship between session keys and messages harder to analyse.
For traders, the version distinction matters primarily when evaluating proxy implementations. A proxy server that advertises "MTProto support" without specifying 2.0 may be running the older protocol. TradersProxy runs MTProto 2.0, which is what current Telegram clients negotiate by default.
MTProto 2.0 is also the version that introduced Obfuscated2 as a supported masking layer — the foundation that FakeTLS builds on. The two are complementary, not competing approaches.
Obfuscated2: the first layer of disguise.
Before FakeTLS, Telegram introduced Obfuscated2 as a way to disguise MTProto connections from basic protocol classifiers. It works by randomising the initial bytes of the connection — the first data your client sends when connecting to the proxy.
Standard MTProto connections begin with a recognisable byte pattern. DPI systems learned to detect this pattern quickly because it is consistent across millions of connections. Obfuscated2 replaces this opening pattern with random-looking bytes derived from a shared secret, making the connection look like noise to a simple classifier.
"Noise" is not the same as "identified as something else." That distinction matters. A DPI system can be tuned to drop or throttle anything it does not positively recognise as a known protocol. In that case, random-looking bytes are not safe — they are suspicious by being unclassifiable.
This is the gap FakeTLS fills. Obfuscated2 makes MTProto look like nothing. FakeTLS makes it look like HTTPS. Looking like HTTPS is far better than looking like nothing, because HTTPS is the most common protocol on the internet and almost no ISP throttles it aggressively.
The TradersProxy implementation deploys both: Obfuscated2 for the inner layer and FakeTLS for the outer presentation. This is the combination Telegram designed for DPI bypass and what the TradersProxy stack implements on Go-based server infrastructure.
FakeTLS: making MTProto invisible to your ISP.
FakeTLS is not a separate protocol. It is a presentation layer that wraps an MTProto connection so that its opening handshake is indistinguishable from a browser starting an HTTPS session with a trusted website.
When your Telegram app connects through a FakeTLS-enabled proxy, the first thing the ISP's DPI system sees is a standard TLS ClientHello — the message a browser sends to begin a secure web connection. The byte patterns, the handshake structure, the cipher suite advertisements all match what legitimate TLS 1.3 traffic looks like. The DPI system classifies it as HTTPS. The throttle does not apply.
The proxy's FakeTLS secret — the parameter in your tg:// link that starts with "ee" — is the key that the proxy uses to identify your connection as a legitimate TradersProxy session and unwrap the masking layer. Without the correct secret, the proxy refuses the connection. This prevents random users from abusing proxy servers that use FakeTLS.
On the other end of the proxy, the traffic is forwarded to Telegram's data centres as standard MTProto. The masking is point-to-point between your device and the proxy server. Beyond the proxy, it looks like normal Telegram traffic — because it is.
The practical effect: traffic that was sitting in your ISP's Telegram throttle queue now travels with normal HTTPS priority. The delta between throttled delivery and unthrottled delivery during a news event is the gap between missing an entry and having time to act on it.
What a proxy actually does — and what it never sees.
An MTProto proxy sits between your Telegram app and Telegram's data centres. It receives the masked connection from your device, removes the masking layer, and forwards the MTProto traffic to the appropriate Telegram DC. On the return path, it receives Telegram's response, re-applies the masking, and sends it back to your device.
What the proxy handles: connection routing, masking/unmasking, keepalive management, per-user connection enforcement. It knows your connection exists, when it was established, and how much data has passed through.
What the proxy never sees: the content of your messages, your Telegram credentials, your phone number, your account information, your message history. These are encrypted by MTProto's application-layer encryption before they leave your device. The proxy receives and forwards encrypted bytes. It has no key to decrypt them.
This is worth being explicit about because traders sometimes conflate proxy security with VPN security. A VPN endpoint has the ability to inspect your traffic because it holds the keys to the VPN tunnel. An MTProto proxy does not hold the keys to your MTProto session — those are derived between your client and Telegram's servers during setup, and the proxy is not party to that exchange.
The TradersProxy SOCKS5 relay operates under the same principle for your trading terminal traffic. Both proxies are routing infrastructure — they see that traffic exists, not what the traffic contains. This is also covered in the MTProto proxies guide.
Why protocol knowledge matters when choosing infrastructure.
Free proxy lists do not typically specify which version of MTProto they run, whether they implement FakeTLS or only Obfuscated2, what their keepalive configuration is, or how many concurrent users share the server. These are not edge-case details. They determine whether your proxy is effective during the moments you actually need it.
MTProto without FakeTLS — just Obfuscated2 — provides partial protection against simple classifiers but not against ISPs that throttle anything they cannot positively identify as a known protocol. A proxy that looks like "noise" to the DPI system may still end up in a degraded queue.
MTProto proxy keepalive defaults to Linux kernel defaults — typically two hours. This means a connection that has been idle for more than a few minutes may be silently dropped by an intermediate NAT device before the keepalive fires. When the signal arrives, Telegram has to reconnect before delivery. A proxy tuned to 60-second keepalives prevents this window.
Shared infrastructure adds another variable. A proxy running on a VPS shared with hundreds of other users will face resource contention under load — exactly during news events when you need it most. The congestion is not from your traffic. It is from the other traders on the same list who opened the same search result.
Understanding the protocol stack means you can ask the right questions of any proxy provider: What MTProto version? Does it implement FakeTLS with the correct "ee" prefix secret? What is the TCP keepalive configuration? Is the node dedicated or shared? How many concurrent users? These questions have specific, answerable answers — and providers who cannot answer them are telling you something.
Eight things worth knowing about MTProto.
MTProto was designed by Nikolai Durov and the Telegram team. It was built from scratch because existing protocols like HTTPS were not fast or resilient enough for Telegram's goals. The full specification is public.
The MTProto specification is publicly documented by Telegram. The Telegram client apps are open source. The server-side implementation is not open source, though the protocol itself is fully specified and independently implementable.
No. MTProto encryption is part of the protocol itself, below the proxy layer. The proxy routes encrypted bytes — it cannot read your messages or credentials. Your end-to-end encryption in Secret Chats is unaffected.
MTProto has a recognisable protocol fingerprint. ISP Deep Packet Inspection systems identify that fingerprint and classify Telegram traffic into a lower-priority queue. A proxy with FakeTLS masking makes the connection look like ordinary HTTPS so the classifier leaves it alone.
No. SOCKS5 is a general-purpose network relay protocol that works at the transport layer — it can proxy any TCP/UDP traffic. MTProto is Telegram's own application-layer messaging protocol. A SOCKS5 proxy forwards packets; an MTProto proxy speaks the Telegram protocol natively.
MTProto is included on Standard ($15/mo) and Pro ($25/mo) plans. The Starter plan does not include MTProto.
Yes. MTProto is the official Telegram protocol, and proxy support is built into the Telegram app by design. It is Telegram's own anti-censorship tool. The proxy sees only encrypted bytes — it has no access to your messages or account.
Yes. Telegram Desktop on Windows and macOS supports MTProto proxies. Open the tg:// link from your portal and it configures automatically, or go to Settings > Advanced > Connection type > Use custom proxy.