The short answer: yes, but only for your message content
Free MTProto proxies are safe for one very specific thing: hiding your message text from the operator. They are not safe for hiding your metadata, your IP address from Telegram, or your connection pattern from a deep packet inspection (DPI) system. If your threat model is "I don't want a random VPS admin reading my chats," a free proxy works. If your threat model includes an adversary watching the network edge, the proxy itself is the weakest link, not the encryption.
The distinction matters because most "is it safe?" articles conflate transport security with anonymity. MTProto provides the former. A free proxy does nothing for the latter.
What the operator can see
When you connect to an MTProto proxy, you are not establishing a direct TLS tunnel to Telegram. The proxy terminates your connection, decrypts the outer transport layer, and forwards plaintext MTProto frames to Telegram's data center on your behalf.
This means the operator sees:
- Your real source IP address
- The Telegram data center IP you are connecting to (usually near you, geo-wise)
- The full packet timing pattern: when you send a message, how often, how long the gaps are
- Unencrypted MTProto headers, including the 64-bit session ID and the message sequence numbers
- Total bytes in and out, which correlates strongly with message length
That last point is not academic. An operator measuring a 3,000-byte upload followed by a silent period can predict with high confidence you sent a photo, not text. A 200-byte burst means a short message. Even with MTProto's transport obfuscation, the sizes are not padded. The telegram.org documentation confirms that only messages of the same class are padded to the same length, and that class distinction is visible at the transport layer.
| Data visible to proxy operator | Data protected by MTProto encryption |
|---|---|
| Your IP address | Message text |
| Packet sizes and timing | Attachments (downloaded via DC) |
| Session ID (64-bit) | Peer user IDs inside chats |
| Volume of traffic per session | Group titles and member lists |
| Destination Telegram DC | Search queries and bot commands |
The session ID is worth dwelling on. It is a per-connection random value, but the operator sees it on every packet. If you disconnect and reconnect using the same saved authorization key, the session ID changes; however, the authorization key lifecycle is not visible to the proxy because it is negotiated through the proxy and encrypted by the outer layer. So the operator cannot link two sessions to the same identity just from the key, but they can link them by your source IP and timing.
The end-to-end layer: what actually protects you
MTProto has two encryption layers. The outer layer, with the random 256-bit key and 128-bit IV, is designed specifically to look like random bytes to a DPI system. This is the layer that a proxy terminates. It protects your traffic from network-level observers between you and the proxy.
The inner layer, the encrypted payload, is between your Telegram client and Telegram's servers. The proxy only forwards ciphertext chunks of this layer. Wait—let me be precise here: the inner layer is end-to-end between your client and Telegram's DC, but not between you and your chat partner. That only happens when you enable Secret Chats, which add an additional layer and a separate key exchange that even Telegram's servers cannot read.
So the honest breakdown is:
- Default chats: Telegram servers can read them. Proxy operators cannot.
- Secret chats: Neither Telegram nor the proxy can read them, provided the client verifies the emoji/QR fingerprint.
- Your IP address: The proxy has it, Telegram has it. No free proxy changes that.
One subtlety: if the proxy is malicious and modifies the MTProto payload, it cannot create valid ciphertext for the inner layer without the authorization key. It can drop packets, which manifests as random "Connecting..." states. It can also log everything and sell the metadata. That is the realistic threat, not decryption.
The promoted-channel mechanism: where the real risk lives
Every free proxy provider wants you to join their Telegram channel. Usually the join link is embedded in the proxy URL as the ?promo=channel_id parameter. Joining that channel is safe in the sense that your participation only tells the channel owner your Telegram user ID, which you already reveal to any channel you join.
The actual risk is not the promo parameter. It is what the proxy link itself tells a third-party service. A public proxy listing page has to display the proxy's IP, port, and secret. Anyone running a scraper can scrape that page and then run their own scanner against those endpoints to confirm they are live. The Free MTProto proxy ecosystem operates on an open-arms model: the secret is deliberately public.
This creates a subtle anonymity failure. Suppose you are the only person in a given network using a freshly scraped proxy. The operator sees one user from one IP and can trivially correlate your behavior with a known Telegram account if they also run a public channel and match timestamps of your actions. The proxy becomes a tracking beacon, not a privacy shield.
A better design, and one that the free-mtproto-proxies project partially addresses by rotating and verifyong proxies, is to use a pool with high churn so that no single operator sees more than a fragment of your session. But rotation brings its own problem: every reconnection exposes your IP to a new operator.
How to sanity-check a proxy source
You cannot audit a proxy without running traffic through it. But you can run passive checks first, and one active test that costs nothing.
Passive checks
- Fetch the proxy's IP and run a reverse DNS lookuplookup. A VPS in a known hosting provider's range (OVH, Hetzner, DigitalOcean) is neither good nor bad; it just tells you the operator paid about $5/month and has zero incentive to maintain uptime, which correlates with the short lifespans documented in this teardown of why hundreds of MTProto proxies die within weeks.
- Check the port. A live proxy on port 443 is more likely to survive DPI than one on port 80 or a high port like 2083, because TLS-flavored DPI rules typically whitelist 443. That is a survival concern, not a privacy one.
- Verify the secret format. A valid MTProto secret is 32 bytes hex. If the secret is shorter or contains non-hex characters, the proxy is a typo collection service, not a scam. Scammers rarely bother with MTProto; they go after V2Ray or Shadowsocks with fake client apps.
The one active test that matters
Connect to the proxy using a throwaway Telegram account and a brand-new session, then send a picture through it and watch whether the proxy mangles the connection. A concrete failure mode: a proxy behind an overloaded VPS will hit Telegram's 30-second reconnection timeout and drop you mid-transfer. That is not malicious, just unreliable.
You cannot verify the operator is not logging. No client-side tool can. The only honest mitigation is the assumption that any free proxy is logging your metadata, and to route traffic accordingly: use it for ephemeral discussions, not for a permanent session that identifies you.
Why TLS-fake doesn't change the privacy calculus
Fake-TLS proxies wrap the MTProto stream in what looks like a TLS ClientHello and then a stream of encrypted records. In MTProto-land this is called "TLS mode" because the transport sends a valid ServerHello followed by a real TLS handshake to a bogus domain.
The security effect is that a passive DPI system sees an ordinary TLS connection to, say, cloudfront.net and does not flag it as Telegram. The privacy effect for the operator is zero—they still terminate the TLS stream and forward the inner MTProto frames.
In fact, from a privacy perspective, Fake-TLS can be worse. The operator sees the SNI you chose. If you connect to a fake-tls proxy for Telegram and your ISP inspects TLS SNI fields (which most modern DPI does), then the ISP logs "connection to binance.com" from your IP, and the proxy logs "connection from same IP bound for telegram.org, port 443." A subsequent metadata correlation between those two logs is trivial. A non-Fake-TLS proxy, by contrast, looks like random bytes to the ISP but only until the proxy's IP block becomes known—after which it is flagged and killed within about 48 hours, according to the link-loss data from the reliability report mentioned above.
So Fake-TLS is a anti-censorship tool, not a privacy tool. Do not conflate the two.
What a carefully chosen free proxy can protect, if anything
Given all the above, a free proxy still offers three legitimate protections:
- Your ISP cannot see you are using Telegram (only that you talk to one unknown IP).
- Your chat content is unreadable to a passive network observer beyond the proxy.
- Your IP is shielded from Telegram's data centers, which matters if Telegram is data-mining or is compelled to log addresses.
The weakness of each: your ISP sees the proxy connection, not Telegram, so if all Telegram is actively blocked in your country, the proxy IP will eventually be burned as well; a passive observer still reads the bytes sizes; and Telegram's data centers still see the proxy's IP, which under a legal request may be correlated with Telegram's own account registration logs.
FAQ
Can a free MTProto proxy read my messages?
No, unless you are using a fake client that ships its own broken MTProto implementation. The proxy only has the outer transport cipher. Reading the inner payload would require a key exchange with Telegram's server that the proxy does not participate in. The realistic risk is metadata logging, not message decryption.
Does the secret in the proxy URL protect me in any way?
The secret is not a password. It is a 256-bit pre-shared key used to fold into the transport encryptor's initialization. Leaking it, which every public listing does, only allows a third party to attempt a connection and pass a fake-server check. It does not expose your past traffic and does not give anyone a key to your chats.
How do I find out if a proxy is logging my traffic?
You cannot from the client side. There is no observable fingerprint for logging; a memory-dumping operator looks identical to a clean one. The only empirical signal is when a proxy's IP starts resurfacing in known malicious reputation lists, which is detected by services like abuseipdb about three days after the fact, not before. Use a fresh proxy for sensitive actions, and never reuse a proxy IP across distinct personal identities.
