MTProto vs SOCKS5 for Telegram, the complete guide to both proxy protocols

Telegram is one of the very few mainstream apps with proxy support built straight into its settings menu. no system tweaks, no third-party VPN app, just Settings, Data and Storage, Proxy. and that menu offers exactly two protocols: MTProto and SOCKS5.

they sit next to each other in the same list, they both say “proxy”, and they are not interchangeable. they were designed for different problems, they behave differently, they fail differently, and picking the wrong one is the single most common reason someone sets up a “telegram proxy” and then wonders why it doesn’t do what they expected.

I’ll give you the answer up front, because not everyone needs 12,000 words:

• if your problem is “Telegram won’t connect in my country”, you want MTProto. it exists to unblock the app, and only the app, in places where it’s censored.
• if your problem is “I run multiple Telegram accounts, or bots, or automation, and I need them on clean separate IPs that don’t get flagged”, you want SOCKS5 on a dedicated proxy you control. ideally a mobile one.

everything below is the detail behind that answer: what each protocol actually is on the wire, where the secrets and links come from, what the proxy operator can and can’t see, why free proxy lists behave the way they do, what Telegram’s anti-abuse systems actually score, and how to decide for your specific situation. it’s long because the topic deserves it. use the headings.

why Telegram has proxy support built in at all

no other major messenger ships with a proxy menu. WhatsApp added a limited version in 2023, years late and far more restricted. to understand why Telegram has had one for years, you need a little history, because the feature wasn’t built for marketers or scrapers. it was built for censorship.

Iran, 2018

Telegram was, for a stretch of years, effectively the internet in Iran. estimates at the time put it at around 40 million users in a country of 80 million, carrying everything from family group chats to news distribution to a huge share of small-business commerce. when protests spread in late 2017 and early 2018, the app was throttled, then temporarily blocked, and on 30 april 2018 the Iranian judiciary ordered a full ban.

the ban did not really work. usage dropped and then substantially recovered, because Iranians moved en masse onto proxies and VPNs. Telegram’s response during this period shaped the feature set you see today: proxy support directly in settings, shareable one-tap proxy links, and a protocol designed to be hard for national firewalls to recognize. that protocol is the MTProto proxy.

Russia, 2018 to 2020

the same month as the Iranian ban, Russia’s regulator Roskomnadzor began blocking Telegram after the company refused to hand over encryption keys to the FSB. what followed is one of the most famous censorship failures on record. Telegram kept hopping between cloud IP addresses, and Roskomnadzor chased it by blocking entire ranges, at one point over 18 million IP addresses belonging to Amazon and Google cloud infrastructure. that broke banks, retailers, ticket systems and assorted government services, while Telegram in Russia kept mostly working. proxies, including MTProto proxies run by volunteers, were a core part of how. the official block was quietly abandoned in june 2020.

Telegram’s founder called the volunteer proxy and VPN operators of this era the “digital resistance”, and the #DigitalResistance tag still floats around proxy channels today. that’s the cultural root of the giant free MTProto list channels you’ll find on Telegram itself, some with hundreds of thousands of subscribers.

everywhere since

the censorship map shifts every year, and I won’t pretend a blog post can stay current on it. Telegram has been blocked or throttled at various times in China (continuously, as part of the Great Firewall), Iran (the 2018 ban stayed formally in force for years even as usage continued), and intermittently in a list of countries during protests or elections, including Iraq, Azerbaijan, Bahrain, Cuba, Belarus and others. each blocking event produces the same spike: a flood of searches for “telegram proxy”, a wave of fresh MTProto servers, a round of those servers dying, repeat.

we see the demand side of this directly. search interest in “telegram proxy” sits at a baseline of around 1,000 monthly searches in the US, and in january 2026 it spiked to over 18,000 in a single month before settling back down. censorship events drive this market in bursts, and the free-proxy ecosystem is built around those bursts.

the reason this history matters for a practical guide: MTProto proxies were designed for exactly this scenario and no other. one person, blocked app, get connected, move on. every design decision in the protocol makes sense in that frame and stops making sense the moment you try to use it for account operations. which is what the rest of this guide is about.

how Telegram connects, the 60-second version

before comparing the two proxy types it helps to know what they’re proxying.

Telegram runs its own protocol called MTProto (currently version 2.0) between your app and its data centres. it doesn’t ride on HTTPS the way most apps do. your client holds an authorization key negotiated with a specific Telegram data centre, all message payloads are encrypted under that key (and again end-to-end for secret chats), and the wire format is Telegram’s own.

two practical consequences:

1. the encryption is between your app and Telegram, not between your app and the proxy. any proxy you add, MTProto or SOCKS5, sits outside that encryption. this is worth internalizing because it answers most of the “can the proxy read my messages” questions later. it can’t. the cryptography doesn’t pass through the proxy’s hands.
2. the traffic pattern is recognizable. a national firewall doing deep packet inspection can learn what raw MTProto flows look like, and the IP ranges of Telegram’s five data centres are public knowledge. so a censor blocks the DC addresses, and then starts hunting the protocol itself. that’s why a plain SOCKS5 proxy is often not enough to beat a serious censor (the firewall can still see Telegram-shaped traffic inside the tunnel’s destination), and why MTProto proxies go to such lengths to look like something else.

a proxy of either kind changes the path: your app talks to the proxy, the proxy talks to Telegram. your ISP sees you talking to some server, not to Telegram’s ranges. what differs between the two protocols is everything else: how the connection authenticates, what it can carry, what it looks like to an observer, and who tends to operate the servers.

MTProto proxies in depth

what it actually is

an MTProto proxy is a purpose-built relay that speaks Telegram’s own transport. it is not a general proxy. you cannot point a browser at it, you can’t tunnel SSH through it, it forwards Telegram traffic and nothing else.

the client and proxy share a secret, a 16-byte value usually written as 32 hex characters. that secret isn’t a password in the login sense, it’s the key material the client uses to derive the obfuscation applied on the wire between you and the proxy. anyone holding the secret can use the proxy, which is exactly the point: secrets are distributed openly in t.me links, tapped once, and the app is connected. zero accounts, zero usernames, zero friction. perfect for handing out connectivity during a blackout, useless for controlling who’s on your server.

the three secret formats

you’ll meet three shapes of secret in the wild, and the prefix tells you which obfuscation mode the proxy runs:

• plain, 32 hex chars (d41d8cd98f00b204e9800998ecf8427e): the original mode. the stream between client and proxy is obfuscated but has a recognizable handshake shape, and several national firewalls learned to detect and kill it years ago. you still see these on old lists. they tend not to survive in heavily censored networks.
• dd-prefixed (dd + 32 hex): “padded” mode. the client adds random-length padding to packets, which breaks the packet-size fingerprinting that DPI boxes used against plain mode. better, still detectable by smarter firewalls doing statistical analysis on the flow.
• ee-prefixed (ee + 32 hex + hex-encoded domain): fakeTLS. this is the current state of the art and what any serious proxy runs. the entire connection is dressed as a TLS 1.3 session to some innocent domain, real TLS record framing, plausible handshake, the works. to a firewall it looks like you’re browsing some-cdn-domain.com over HTTPS. the domain is baked into the secret, which is why ee-secrets are so much longer. operators pick popular domains that would be expensive to block.

in t.me proxy links you’ll often see the same secrets base64url-encoded instead of hex. same data, different encoding, the app handles both.

none of this requires you to understand it as a user, you tap a link and it works. but it explains two things you’ll observe in practice: why old proxies from stale lists “connect” and then die instantly under censored networks (plain mode, detected, killed), and why working proxies in hard-censorship countries are almost always ee-type.

proxy links and the one-tap flow

MTProto proxies spread as links:

https://t.me/proxy?server=203.0.113.10&port=443&secret=ee...
tg://proxy?server=203.0.113.10&port=443&secret=ee...

tap one anywhere in Telegram and the app shows a confirmation sheet with the server details and an enable button. that single interaction is the entire onboarding. it’s why MTProto lists work as Telegram channels: a channel posts twenty links a day, subscribers tap whichever is newest, and when one dies they come back for the next. the distribution mechanism lives inside the thing being distributed, which is genuinely clever and also exactly why these channels have enormous subscriber counts.

sponsored channels, or why free proxies are free

here’s the part of the MTProto design that surprises people. Telegram gave proxy operators an official monetization hook: a proxy registered through Telegram’s @MTProxybot can attach a sponsored channel. every client connected through that proxy gets the sponsored channel pinned at the top of their chat list for as long as they’re connected, marked “Proxy Sponsor”.

so the deal of a free MTProto proxy is explicit: you get connectivity, the operator gets your eyeballs on a channel of their choosing. usually it’s crypto signals, gambling, piracy, or just the operator’s own proxy-list channel to complete the loop. the moment you understand this you understand the whole free-list economy. those servers cost real money to run under tens of thousands of users. the sponsored slot is what pays for it.

is that sinister? mostly no, it’s just an ad. but you don’t choose the channel, you can’t remove the pin while connected, and operators can change it at any time. for a personal account used to read the news, fine. on a client device you manage for someone else, or a fleet of work accounts, it’s an obvious nonstarter.

what the operator sees, and what they can’t

worth being precise here because both the fear and the reassurance get overstated.

an MTProto proxy operator cannot read your messages, see who you talk to, or impersonate you. all payloads are encrypted between your app and Telegram’s DC under keys the proxy never has. the protocol was explicitly designed so that volunteers could run proxies for strangers without those strangers having to trust them with content.

what the operator does see: your real IP address, the fact that you use Telegram, when you connect and disconnect, and your rough traffic volume and timing. that’s connection metadata, and in some threat models it matters a lot. a proxy run by a hostile party in front of dissidents is a surveillance sensor for who uses Telegram and when, even though it can’t see what they say. if your threat model includes the people who might run free proxies in your region, that’s an argument for a paid server you or your community controls, or a reputable VPN, over a random list entry.

running your own MTProto proxy

if you have a $5 VPS and basic docker literacy you can run your own. the realistic options:

• the official C implementation (MTProxy, with the telegrammessenger/proxy docker image): canonical, somewhat stale in maintenance, doesn’t do fakeTLS well. mostly historical at this point.
• mtg (golang): the one most people should use. single binary, fakeTLS by default, tiny resource footprint, sane defaults, easy secret generation.
• mtprotoproxy (python, by alexbers): popular in the volunteer era, easy to read and modify, still works fine.

the operationally important choices: listen on port 443 (so the traffic looks like HTTPS at the port level too), use an ee/fakeTLS secret with a believable domain, and register with @MTProxybot if you want stats and a sponsored channel slot. rotate the secret if it leaks onto public lists and your server gets swamped, which happens fast, scrapers grep Telegram channels for tg://proxy links continuously.

a self-run MTProto proxy is the right answer for a specific, narrow problem: you have friends/family/a community in a censored country, you control the server, you don’t want to manage accounts and passwords for them, and everyone’s traffic is just personal Telegram use. it’s a genuinely good solution to that problem.

the hard limits of MTProto

and now the boundary that this entire guide turns on. MTProto proxies, by design:

• carry only Telegram traffic. your browser, your scraping stack, your other apps don’t go through them. (in fairness, for some users that’s a feature: no chance of accidentally routing the wrong thing.)
• have no authentication identity. there is no “user” at the proxy level, just whoever holds the secret. you can’t give account A one exit IP and account B another on the same server in any controlled way.
• are invisible to automation libraries. Telethon, Pyrogram, GramJS, none of the MTProto client libraries accept “an MTProto proxy” as a normal proxy parameter the way they accept SOCKS5. (a couple have partial experimental support, it’s not how anyone runs production.)
• mostly run on datacenter IPs, because that’s what volunteers and list operators rent. so even when they work, the IP reputation behind them is the worst tier for account trust.

which hands the conversation over to SOCKS5.

SOCKS5 in depth

what it actually is

SOCKS5 is old, boring infrastructure, and I mean that as a compliment. it’s a general-purpose proxy protocol standardized in 1996 (RFC 1928, with username/password auth in RFC 1929). it knows nothing about Telegram. it forwards TCP connections, full stop. your client says “connect me to host X on port Y”, optionally proves who it is with a username and password, and the proxy opens the connection and shuttles bytes.

that generality is the whole value. the same SOCKS5 port that carries your Telegram session can carry a browser, a scraper, an anti-detect profile, anything. and because it’s a 30-year-old standard, everything supports it: every OS, every automation library, every tool you’ll ever touch in account work.

Telegram supports SOCKS5 natively in its proxy settings on iOS, Android and Desktop. (Telegram Desktop additionally supports plain HTTP proxies, the mobile apps don’t.) the fields are exactly what you’d expect: server, port, and optional username and password.

authentication is the feature

the username/password pair looks mundane next to MTProto’s exotic secrets, but it’s the load-bearing difference.

an MTProto proxy is open to anyone holding a string that’s designed to be passed around publicly. a SOCKS5 proxy with auth is yours. the operator can issue one credential per customer, per port, per account. nobody else lands on your exit IP unless the operator puts them there, which is a policy question you can actually pay for, rather than a free-for-all baked into the protocol.

this is what makes per-account IP isolation possible at all. when we say a port on our service is dedicated, the mechanism is exactly this: one SOCKS5/HTTP credential pair, one SIM, one customer. the protocol gives the operator a knob MTProto simply doesn’t have.

(side note for completeness: there are free SOCKS5 lists out there too, including “free socks5 with username and password” lists, which should strike you as odd on its face. a credentialed proxy being given away means either it’s stolen, it’s a honeypot logging everything, or the credentials are shared with ten thousand people and the auth means nothing. all three are common. treat every free credentialed proxy as compromised by default.)

what rides through it

with Telegram pointed at a SOCKS5 proxy, all of the app’s traffic exits from that IP: login, session traffic, media uploads and downloads, API calls if it’s a bot or library session. one consistent address for the whole account lifetime, if you want it that way.

and crucially, the automation stack speaks it natively:

# telethon
import socks
client = TelegramClient(
    "session", api_id, api_hash,
    proxy=(socks.SOCKS5, "sg1.example.com", 45001, True, "user", "pass"),
)

# pyrogram
app = Client(
    "session", api_id=api_id, api_hash=api_hash,
    proxy=dict(scheme="socks5", hostname="sg1.example.com",
               port=45001, username="user", password="pass"),
)

// gramjs
const client = new TelegramClient(session, apiId, apiHash, {
  proxy: { ip: "sg1.example.com", port: 45001, socksType: 5,
           username: "user", password: "pass" },
  useWSS: false,
});

three lines of config in any library, and a given session lives permanently behind a given IP. this is the entire technical basis of professional multi-account operations, and it’s why the question “MTProto or SOCKS5 for account management” isn’t really a question. one of the two options can’t do the job at all.

the IP behind the proxy is what Telegram judges

here’s the thing the protocol choice doesn’t solve, and where most SOCKS5 setups actually fail. SOCKS5 is just plumbing. what Telegram evaluates is the IP at the end of it, and IPs come in three reputational tiers:

• datacenter IPs (AWS, Hetzner, OVH, DigitalOcean and friends): identifiable from the ASN in one lookup. platforms know no normal human chats from an OVH range. cheapest, most abused, first to hit registration walls and login challenges.
• residential IPs: home broadband addresses, usually resold through peer-to-peer SDK pools. better reputation than datacenter, but pool-based residential means the exit you’re on was someone else’s exit an hour ago, and you inherit the pool’s collective behaviour. quality varies wildly by provider and by the specific exit you draw.
• mobile carrier IPs: addresses from a real carrier’s CGNAT range, the kind every phone on SingTel or StarHub or M1 sits behind. this is the top of the trust ladder for one structural reason: behind any single mobile IP there are hundreds or thousands of legitimate users at once, because that’s how carrier-grade NAT works. a platform that hard-bans a mobile IP takes out a crowd of real customers as collateral. so enforcement against mobile ranges is conservative, trust starts high, and per-IP punishment is rare. Telegram itself is a mobile-first app, a mobile IP is its single most ordinary sight.

so the practical hierarchy for Telegram account work: SOCKS5 on a dedicated mobile IP, then SOCKS5 on good residential, then a long gap, then datacenter, then a longer gap, then shared free anything.

what a SOCKS5 operator sees

same deal as MTProto, with one addition. the operator sees your real IP, connection times, destinations and volumes. message content stays sealed inside MTProto encryption end to end with Telegram, the SOCKS5 hop can’t open it.

the addition: because SOCKS5 is general-purpose, if you route other apps through the same proxy, those carry their own (separate) security properties. your browser through the same port is protected by whatever TLS the sites use, not by Telegram’s crypto. not a problem, just a different mental model: the proxy is a pipe, each protocol inside it brings its own locks.

which is also the honest pitch for why you pay for this category: you’re not paying for secrecy of content (you have that for free, from the protocol), you’re paying for who else is on the IP (nobody) and what the IP is (a real carrier address with a clean history).

head to head

security and privacy, threat by threat

“is a telegram proxy safe” has no single answer because safe from whom varies. four threat models cover most readers:

threat: the censor (a government or ISP blocking Telegram). MTProto with an ee/fakeTLS secret is the purpose-built answer, your traffic impersonates ordinary HTTPS. plain SOCKS5 helps only against lazy blocking (DC IP blacklists), because DPI can still recognize Telegram’s protocol inside the forwarded stream. if you need both censorship resistance and everything else in this guide, the usual production answer is a VPN (wireguard/openvpn, or shadowsocks where VPNs are hunted) with Telegram inside it, or MTProto for the personal device and SOCKS5-behind-VPN for the work.

threat: the proxy operator. covered above, but the asymmetry bears repeating. content is safe under both protocols. metadata (your IP, your schedule, your volume) is exposed under both. so operator trust is about metadata. a random free proxy means an unknown party logging unknown things for unknown reasons, and the going theory for several large free networks is that connection logs are the product. a paid provider with a name, a jurisdiction and a billing relationship is a different risk class. self-hosted is a third.

threat: Telegram’s anti-abuse systems. this one inverts the logic, the “adversary” is the platform’s spam defense and what it judges is mostly your IP’s reputation and your behaviour. protocol choice matters only through what it implies about the IP: MTProto means shared datacenter exit (bad), paid SOCKS5 means whatever tier you bought. more in the next section, it deserves its own.

threat: man-in-the-middle on the proxy hop. people worry a malicious proxy will tamper with traffic. with Telegram specifically, tampering gets you a broken connection, not a compromised account, MTProto authenticates the Telegram endpoints cryptographically. the realistic MITM risk on a hostile proxy applies to other traffic you route through it, e.g. a browser hitting plain-HTTP sites. keep the proxy single-purpose for Telegram and this threat mostly evaporates.

one more, because it gets asked: does using a proxy itself flag your account? no. proxy use is normal and expected on Telegram, enormous user populations connect through them by necessity. what gets accounts flagged is the reputation of the exit IP and what the account does. a clean dedicated IP with human-looking behaviour through a proxy reads better than a flagged raw connection without one.

performance, the honest version

every proxy adds a hop, so some overhead is physics. what determines whether you feel it:

geography of the triangle. your latency is you→proxy plus proxy→Telegram-DC, instead of you→DC direct. a proxy roughly on the path costs single-digit milliseconds; a proxy on the wrong continent costs hundreds. for chat traffic, even bad latency mostly doesn’t matter, Telegram is async messaging. for calls it matters a lot, for media it matters some.

server load. this is what actually kills free proxies. a popular list entry has tens of thousands of concurrent users on a VPS with one shared uplink. it was fast the hour it was posted, it’s molasses by the weekend. the “fast proxy for telegram” searches you see are mostly people cycling through dying free servers. a dedicated port doesn’t have this failure mode because there’s nobody else on it.

protocol overhead. negligible difference between the two for payload throughput. fakeTLS framing adds a small constant; SOCKS5’s handshake happens once per connection. you will never notice either next to load and geography.

mobile carrier characteristics. a mobile-IP proxy rides an actual radio network, so expect slightly higher jitter than a datacenter line, with bandwidth that’s entirely fine for Telegram (4G/5G uplinks comfortably carry chat, media and bot traffic). the trade is jitter-for-trust, and for account work it’s the right trade, you’re not gaming through it.

calls. voice and video calls are latency- and jitter-sensitive, and by default Telegram clients have a separate “use proxy for calls” toggle, off, precisely because of this. flip it only if your threat model requires calls to hide behind the proxy too, and expect quality to track the proxy’s jitter.

what Telegram’s anti-abuse actually scores, and why this decides the protocol question

if you’re reading this guide for account management, this section is the core of it.

Telegram’s spam and abuse defense is opaque by design, but its observable behaviour is consistent enough that operators of large account fleets agree on the rough shape. the system scores a combination of:

• the IP and its ASN at registration and at login. registration is the strictest gate: new accounts created from low-reputation ranges face instant SMS re-verification loops, “too many attempts” walls, or accounts that are born shadow-limited. login from a flagged range on an aged account triggers challenges more often.
• behaviour rate and shape. message velocity, add/invite velocity, joining patterns, identical-message fanout, peer-flood signals. the dreaded PeerFlood error that automation people know is a behaviour verdict, not an IP verdict, but IP reputation sets how much slack you get before it fires.
• account age, phone number origin, session history. older accounts on stable sessions get more rope. accounts on voip-range numbers get less. every fresh login from a new IP spends a little of the account’s credibility, which is why IP stability matters as much as IP quality.
• clustering. this is the one that kills entire operations. when many accounts share an exit IP plus correlated behaviour, a ban on one propagates to the cluster. shared proxies don’t just risk inherited reputation from strangers, they make your own accounts each other’s contagion.

read that list against the two protocols:

an MTProto proxy gives you a shared datacenter exit you can’t authenticate, can’t isolate per account, and can’t keep stable (free servers die in days). it fails every single criterion. not because it’s bad at its job, because this was never its job.

SOCKS5 on dedicated IPs lets you give each account (or each small fixed cell of accounts) its own stable, clean, authenticated exit. with mobile IPs specifically, the registration gate and the clustering logic both soften, because the IP class is the same one real users are on and because carrier CGNAT makes IP-level collective punishment expensive for the platform.

none of this is a license to behave like a spam cannon, behaviour scoring will still get you. the honest claim is narrower: a dedicated mobile SOCKS5 setup removes the network layer as your limiting factor. what you do with it is on you. anyone promising “unbannable” is selling something.

we keep a more operational version of this playbook, including warm-up pacing and port-per-account patterns, on the telegram proxy for account management page.

the free list economy, and how to read it

a few thousand words ago I promised an explanation of why free telegram proxies behave the way they do. here’s the system in one paragraph.

censorship events create demand spikes. volunteers and channel operators spin up MTProto servers because it’s cheap and the sponsored-channel slot pays for popular ones. lists distribute as Telegram channels and as scraped aggregator sites with “updated hourly” banners. each posted server accumulates users until it’s either overloaded into uselessness or detected and blocked by the censor it was beating, typical lifespan days, sometimes hours during active crackdowns. the churn itself drives the engagement, subscribers keep coming back for fresh links, which keeps the channel valuable, which pays for the next batch of servers. it’s a self-sustaining loop and as a piece of grassroots infrastructure it’s honestly impressive.

how to use it well, if it fits your need: prefer ee-secret (fakeTLS) entries; prefer proxies posted in the last few hours; expect to switch often; expect a sponsored channel pinned at the top; route nothing commercial through it; assume the operator logs connections.

and the two red flags worth knowing. free SOCKS5 lists with credentials are, as covered earlier, compromised by construction, stolen, honeypot, or meaninglessly shared. and proxy entries that ask you to install anything are malware distribution wearing a proxy costume, a real MTProto or SOCKS5 proxy never needs software beyond Telegram itself.

auditing a proxy before you trust it

whichever protocol you land on, you’ll at some point hold a server address and wonder what’s actually behind it. ten minutes of checking saves weeks of confusion later, and almost nobody does it. here’s the audit, in order of effort.

what kind of IP is it really

take the proxy’s exit IP (for SOCKS5, connect through it and hit any what-is-my-ip service; for MTProto the server address in the link is usually the exit too) and look it up on ipinfo.io, ip-api.com or plain whois. you’re reading two fields:

• the ASN and org name. “DigitalOcean, LLC” or “Hetzner Online GmbH” means datacenter, whatever the seller called it. a carrier name like “Singapore Telecommunications Limited” or “StarHub Ltd” means an actual mobile network. residential resellers show up as consumer ISPs. this single lookup catches the most common scam in the proxy market, datacenter IPs sold as “premium residential” or “mobile”. if a provider’s “mobile” proxy resolves to OVH, you have your answer about the provider too.
• the usage type / privacy flags. ipinfo and similar services classify IPs as hosting/business/ISP/mobile and flag known proxies and VPN exits. an exit already flagged as “proxy” in commercial databases is an exit other platforms will treat with suspicion as well. mobile carrier IPs essentially never carry that flag, because they can’t be distinguished from the thousands of normal users behind the same CGNAT address, which is the entire trick.

while you’re there, check the geolocation. an SG proxy that geolocates to Frankfurt will produce exactly the localization problems you’d expect on any geo-sensitive surface.

is it shared

harder to verify directly, but there are tells. connect and watch latency over an hour, a dedicated port is flat, a shared exit sawtooths as other users load it. check the IP against open abuse databases (abuseipdb and friends), a dedicated fresh IP has no history, a recycled shared one often arrives pre-flagged from previous tenants. and the commercial tell: pricing. genuinely dedicated mobile IPs cost what a SIM plus hardware plus carrier data costs, which is why they’re tens of dollars a month, not two. anyone selling “dedicated mobile” at shared-pool prices is reselling a pool.

does the operator answer questions

boring but predictive. ask a provider what carrier their IPs are on, whether ports are 1:1 per customer, and what happens to your IP when you rotate (fresh from the carrier pool, or recycled from another customer). a real operator answers all three in plain language because they’re operational facts. evasive answers about “premium pools” and “millions of IPs” mean pool reselling. for what it’s worth, our answers: SingTel, StarHub, M1 or Vivifi per port, strictly 1:1 (the architecture page covers why), and rotation pulls a fresh address from the live carrier via the modem, nobody else has used through us.

proxies vs VPNs vs shadowsocks, placing the proxy menu in the bigger toolbox

Telegram’s proxy menu isn’t the only way to change where your traffic appears from, and being honest about the alternatives makes it clearer when the proxy menu wins.

a VPN tunnels your whole device. every app, all traffic, one exit. strengths: covers everything including Telegram with zero per-app config, modern protocols (wireguard) are fast, reputable providers exist with audited no-log policies. weaknesses for our purposes: one identity for the whole device (useless for per-account isolation), VPN exit ranges are publicly catalogued and carry mediocre reputation with platforms (better than datacenter proxies, worse than mobile), and in hard-censorship countries the VPN protocols themselves get hunted by DPI, which is an arms race wireguard is currently losing in several places.

shadowsocks and its descendants (v2ray, vless, trojan and the rest of that ecosystem) are encrypted SOCKS5-like tunnels built specifically to be hard for DPI to classify, the spiritual cousins of MTProto’s fakeTLS but general-purpose. in heavy-censorship environments they’re often what actually works day to day. the trade: you need a server outside the firewall and a client app, more moving parts than tapping a t.me proxy link. for a censored-country user with a bit of technical comfort, shadowsocks-on-a-VPS is frequently the most durable option, with MTProto links as the zero-setup fallback.

the in-app proxy menu wins when the problem is Telegram-specific and the trait you need is per-app, per-account control. it’s the only one of the three that can put account A on IP A and account B on IP B on the same device or stack, and the only one automation libraries configure natively per session. it’s also the only one a non-technical user can be walked through over the phone in a minute, which still matters.

they compose, too. a common professional pattern in restrictive networks: device rides a VPN or shadowsocks tunnel for general reachability, while each Telegram session inside the stack pins to its own SOCKS5 mobile port for identity. the censor sees the tunnel, Telegram sees the mobile IPs, each layer solves the problem it’s good at.

running your own SOCKS5, and why it mostly doesn’t solve this

every so often someone technical reads all this and reasonably thinks: SOCKS5 is a trivial protocol, I’ll just run my own on a VPS for $5. and you can. dante, 3proxy and microsocks are all fine, or skip the daemon entirely and use SSH’s built-in dynamic forwarding:

ssh -D 1080 -N user@your-vps.example.com
# now localhost:1080 is a SOCKS5 proxy through the VPS

point Telegram Desktop at 127.0.0.1:1080 and it works immediately. it’s a genuinely useful trick for ad-hoc situations, testing geo-behaviour, getting around a hotel network, giving yourself a stable exit while travelling.

what it doesn’t give you is a good IP. your VPS is a datacenter address, with everything that implies from the anti-abuse section above. self-hosting moves the operator trust problem (you trust yourself completely, great) but not the IP reputation problem, which for account work is the binding constraint. there’s no self-hosted route to a real carrier IP short of building what is essentially a small mobile proxy farm, racks of modems or phones with live SIM cards, power and cooling and a carrier data plan per line, plus the management software to keep PPP sessions alive and rotate cleanly. we know exactly what that takes because it’s literally our infrastructure, over a hundred modems across three servers in Singapore, and the short version is: as a hobby project for two accounts it’s hilarious overkill, which is why a per-port subscription exists as a product category at all.

so: self-host for tinkering and for stable-exit convenience, buy carrier IPs for account work, and don’t let anyone sell you a VPS SOCKS5 as a reputation solution.

sessions, logins, and what actually happens when your IP changes

a cluster of fears in this space comes from misunderstanding how Telegram sessions interact with IPs, so let’s pin the mechanics down.

when you log in, the client negotiates an authorization key with Telegram and that key is the session, stored on your device. the session is not bound to an IP. switch from wifi to cellular, hop proxies, land in another country, the session continues, you don’t get logged out by movement alone. anyone who’s flown internationally with Telegram on their phone has experienced this without thinking about it.

what IP changes do affect:

• risk scoring on the margin. wild IP careening (datacenter in one country, residential in another, hours apart, repeatedly) on a young account contributes to a suspicion picture. on an aged personal account it’s nothing, on a week-old account doing automation it’s part of how PeerFlood gets you sooner.
• fresh logins. a new login (new session) from a low-reputation IP is scored much more harshly than continuing an existing session. this is why the discipline “create and warm the account on the IP it will live on” exists, the riskiest event in an account’s life is its first login, so you spend it on your best IP, once.
• rotation within one carrier. rotating a mobile port (our rotation link, for instance) gives you a different address from the same carrier’s pool, same country, same ASN, same network class. from Telegram’s perspective this is exactly what happens when any phone user drives across town. it does not look like proxy churn, it looks like Tuesday. this is the difference between rotation on a mobile port and “rotation” by jumping between unrelated proxy providers, and it’s why the earlier advice says rotate with a reason but don’t fear it.

two pieces of session hygiene that out-earn any proxy advice, while we’re here: turn on two-step verification (a cloud password makes a leaked SMS code insufficient for takeover), and check Settings → Devices occasionally to revoke sessions you don’t recognize. proxy or no proxy, most account loss is credential mishandling, not network anything.

a buyer’s checklist for SOCKS5 proxies

condensing everything above into the questions that actually separate providers. ask, or test on a trial:

1. what is the IP, verifiably? look it up yourself per the audit section. carrier ASN for mobile claims, consumer ISP for residential claims. no exceptions, no “premium pool” hand-waving.
2. is the port dedicated, contractually? 1:1 means your reputation is yours. “up to N users per IP” means you’re buying a lottery ticket.
3. what’s the rotation story? on-demand via a link/API you control beats timed rotation for account work (sticky by default, fresh IP when you decide). confirm whether rotated IPs are carrier-fresh or recycled between customers.
4. which protocols and auth? SOCKS5 with user/pass at minimum, HTTP alongside is convenient for browser tools. IP-whitelist auth as an option is a plus for servers with static egress.
5. is there a real trial? a provider confident in their IPs will let you put a real session on one and watch it behave. (ours is 24 hours, full port, for exactly this reason.)
6. where does support actually live? when a port misbehaves at 2am before a campaign, “open a ticket, response in 48h” is a very different product from a human on Telegram. ask how incidents are handled, the answer tells you whether you’re buying infrastructure or a reseller’s margin.
7. does the jurisdiction matter to you? for some buyers a provider operating openly under a real legal identity in a stable jurisdiction is a feature (it is, for what it’s worth, how we operate in Singapore, PDPA and all); for others it’s irrelevant. know which buyer you are.

price-shopping across providers without these questions is how people end up with five cheap subscriptions that all fail the same way. one dedicated port that holds beats five shared ones that don’t, in both money and accounts lost.

which one do you need, six scenarios

you’re in a country where Telegram is blocked and you just want your chats. MTProto, fresh from a list, ee-secret if available. switch when it dies. cost: zero, plus one pinned sponsored channel. this is the use case the protocol was born for and it remains genuinely good at it.

you’re a journalist, activist, or otherwise a target, in a censored country. MTProto run by someone you actually trust (your org, a known NGO, you), or a reputable VPN. the random-list operator seeing your IP and schedule is the part of the threat model casual users can ignore and you can’t.

you run multiple Telegram accounts for marketing, community ops, or clients. SOCKS5 on dedicated mobile IPs, one port per account or per small fixed cell, sticky sessions, rotation only with a reason. this is the configuration everything above has been arguing for.

you’re building bots or automation (Telethon/Pyrogram/GramJS). SOCKS5, because it’s the only thing your library actually supports. IP tier matters by what the bot does: a notification bot can live on anything; session-based userbot automation needs the same clean dedicated IPs as manual multi-accounting, the platform can’t tell the difference and doesn’t try.

you’re scraping public channels/groups at scale. SOCKS5 with rotation. here the pattern flips, you want many IPs over time rather than one stable identity per account, so rotating mobile pools or rotation-on-demand ports fit. (our ports expose a rotation link and API for exactly this switch-when-you-need-it pattern.)

you want privacy from your ISP on principle, no censorship involved. honestly, a VPN serves you better than either proxy type, it covers all your traffic, not just Telegram. the proxy menu is the right tool when Telegram specifically is the problem.

quickstarts

MTProto, 30 seconds: find a current proxy link (the big list channels, or any aggregator), tap it, tap “connect proxy” on the confirmation sheet. done. to manage or remove it later: Settings → Data and Storage → Proxy.

SOCKS5, two minutes: get your credentials (host, port, username, password, from your provider’s dashboard; ours are on the port page in the client area). then Settings → Data and Storage → Proxy → Add Proxy → SOCKS5, fill the four fields, save, and check for the “connected” state. Desktop: Settings → Advanced → Connection type → Use custom proxy.

platform-by-platform walkthroughs with screenshots-level detail, deep-link formats, multi-proxy management and a full troubleshooting matrix live in the companion piece: how to set up a proxy in Telegram on every platform.

benchmarking your setup, five minutes of measurement

before blaming Telegram, the proxy, or your ISP for slowness, measure. the whole battery takes five minutes:

baseline first. with no proxy, send yourself a photo in Saved Messages and time the upload, then check a speed test. that’s your ceiling, nothing through a proxy will beat it, and if the baseline is already bad the proxy isn’t your problem.

latency to the proxy. ping your-proxy-host from your machine. under ~50ms is invisible for chat, 100-200ms is fine, 300ms+ means the proxy is geographically wrong for you and media will drag. for SOCKS5 you can time the full tunnel with curl: curl -x socks5://user:pass@host:port -o /dev/null -s -w "%{time_total}\n" https://telegram.org, run it five times and look at the spread, a tight spread is a healthy dedicated line, a wild one is congestion (or radio jitter on mobile lines, some spread there is normal).

the same photo, through the proxy. repeat the Saved Messages upload with the proxy enabled. the delta against baseline is the true cost of your proxy for the heaviest thing you do. on a well-placed dedicated port the delta should be small single-digit percent for chat-sized media; if upload time doubles, you’re load-shedding on a shared exit or hairpinning across continents.

watch it over a day, not a minute. free and shared proxies famously benchmark fine at the moment you test (you found the link when it was fresh, so did everyone else) and degrade by evening as load piles in. a dedicated port’s numbers at 9am and 9pm match, that flatness is most of what the money buys, and it’s the single easiest thing to verify on a trial before you pay.

troubleshooting the protocol-specific stuff

(the full troubleshooting matrix is in the setup guide, these are the failures specific to protocol choice.)

MTProto proxy connects then dies within minutes, repeatedly. the proxy is being detected and reset by a firewall, typical for plain or dd secrets under serious DPI. find an ee-secret proxy.

MTProto works but a strange channel is pinned in your chat list. that’s the sponsored channel, it’s not malware and it unpins when you disconnect the proxy. it’s the price of free.

SOCKS5 stuck on “connecting…” forever. wrong port, dead server, or your network blocks the proxy port outbound. test the same creds in a desktop client or with a curl through the proxy; if nothing connects, it’s the proxy or the path, not Telegram.

SOCKS5 connects but Telegram says proxy unavailable. auth failure more often than not, re-paste username and password, watch for trailing spaces. also worth checking you didn’t put SOCKS5 creds into an MTProto form or vice versa, the settings screens look similar at a glance and the failure is silent.

works on wifi, fails on cellular (or vice versa). some carriers and corporate networks block outbound connections to common proxy ports. switch network to confirm, then ask your provider for an alternate port, any serious one offers several.

automation library throws connection errors with proxy set. double-check the proxy tuple/dict format for your specific library version (the three snippets earlier are current as of mid-2026), and confirm the library has python-socks/pysocks (or your runtime’s equivalent) actually installed, several libraries fail with a misleading error when the socks dependency is missing.

running an MTProto proxy for a community, the operational notes

the self-hosting section above covers the technical install. if you’re the person who ends up running a proxy for more than a handful of people, a diaspora community, an org with staff in a censored country, a big family in the wrong place at the wrong time, the install is the easy 10%. the operational notes nobody writes down:

capacity reality. a $5 VPS handles a surprising number of chat-only users (hundreds, comfortably), because text is tiny. what melts it is media, one viral video forwarded into three big group chats can saturate a small uplink for everyone. watch bandwidth, not CPU, and when you outgrow a box it’s usually cheaper to run two small proxies in different providers than one big one, which also buys you…

redundancy, because blocks come in waves. when a censor finds your server (and at any real scale, eventually they do), users go dark all at once. the standing pattern that works: run two or three servers on different providers/ASNs, distribute all of them in advance through a channel or pinned message your users already have, and rotate the secrets periodically so leaked links age out. the failure mode to design against isn’t technical downtime, it’s your users having no fallback address the morning the primary dies.

the leak problem. any link you give to fifty people is public, assume it from day one. scrapers harvest tg://proxy links from channels continuously, and a leaked server gets load and attention you didn’t plan for. mitigations are imperfect but real: rotate secrets on a schedule (old links die gracefully, you re-pin the new one), keep one quiet unpublished server as the fallback-of-last-resort, and if your users are genuinely at risk, distribute by DM rather than channel posts.

the social contract. you’ll see connection metadata for everyone using your proxy, when they’re online, from what IP. for an at-risk community that’s a real responsibility: log nothing you don’t need (mtg can run effectively logless), tell users plainly what you can and can’t see, and think about what happens to the box if you lose access to it. a proxy run by a trusted community member with no logs is one of the better privacy arrangements available under censorship, but the trust is doing heavy lifting, hold it accordingly.

don’t attach a sponsored channel for this use case. yes it’s free money, no it isn’t worth the pinned-channel confusion for users you’re trying to keep calm during an internet crackdown.

none of this applies to the commercial side of the guide, you’ll notice. that’s the point of the two-protocol split: community circumvention infrastructure and account-management infrastructure optimize for opposite things, and the protocols encode that difference.

myths that refuse to die

collected from years of forum threads, support tickets and sales calls. some of these are sold to people, some are self-inflicted.

“MTProto is encrypted, SOCKS5 isn’t, so MTProto is safer.” the comparison is malformed. your Telegram content is encrypted by Telegram’s own protocol under both, end to end with the data centre. MTProto-the-proxy adds obfuscation against firewalls, not extra secrecy of your messages. SOCKS5 adds neither, and needs neither, for content. the real security differences are operator trust and IP reputation, which cut in different directions depending on who runs what.

“using a proxy will get my account banned.” proxy use is normal, expected, and built into the app by the vendor. millions of users connect through proxies out of necessity. accounts get limited for what they do and for the reputation of where they connect from, not for the existence of a proxy hop.

“a proxy hides me from Telegram.” no. Telegram still knows your account, your phone number, your contacts graph and everything you do in the app. a proxy changes the IP Telegram sees, which matters to network-level scoring and to local observers, and that’s all it changes. anonymity from the platform is a different problem that a proxy does not address.

“free proxy today, paid proxy later, same thing really.” the failure you’re risking isn’t symmetrical. a free exit that goes bad doesn’t just stop working, it can spend your account’s credibility on the way down (limits, challenge loops, peer-flood headroom). you can’t un-spend that by upgrading afterwards. infrastructure quality is cheapest before the account has history.

“rotating constantly makes me look more human.” backwards, for account work. humans are boring, they’re on the same carrier IP for hours and days. constant rotation across unrelated ranges is the signature of cheap pool proxies. sticky-by-default with occasional carrier-pool rotation is what an actual person’s network life looks like.

“residential and mobile are basically the same tier.” they’re adjacent, not equal, and the gap shows at the hardest gates (registration, fresh logins). the structural difference is CGNAT crowd-cover: a mobile address is currently shared by a crowd of legitimate users, so platforms can’t punish it cheaply. a residential address is one household, easy to flag in isolation. pool mechanics make it worse, the residential exit you got this hour has someone else’s last hour baked in.

“my provider says unlimited accounts per proxy, so it’s fine.” what a proxy seller permits and what a platform tolerates are unrelated facts. the platform sees N accounts with correlated behaviour on one IP and applies the clustering logic from earlier, no matter what your invoice says. small fixed cells per port, or 1:1, remains the survivable pattern.

three worked examples

theory compresses well into examples. three composites from real setups (details shuffled, patterns real):

the SG social agency. twelve TikTok-and-Telegram client accounts, previously run through one residential pool subscription, hitting login challenges weekly and two accounts lost in a quarter. rebuilt as: ten dedicated mobile ports (one per major client account, the two smallest clients pair on shared ports), each account’s anti-detect profile pinned to its port, SOCKS5 creds in the profile config, rotation only after a client-visible incident, never on schedule. login challenges went to roughly zero because nothing about the network ever changes; each session looks like the same phone on the same carrier indefinitely. monthly proxy spend went up, total cost went down, account replacement and warm-up labour had been the real expense.

the bot developer. runs a notification bot (Bot API, sends only) and three Telethon userbot sessions doing group management for communities. the notification bot stayed on the VPS direct, nothing scores outbound bot-API pushes harshly. the three userbot sessions each got a SOCKS5 mobile port, configured in the Telethon proxy tuple, sessions created on their ports from day one. the part that surprised him: the PeerFlood errors that had throttled invite flows on the VPS IP largely stopped at identical request rates. same code, same behaviour, different network reputation, different headroom.

the censored-country reader. non-technical, just wants news channels and family chats in a country where Telegram is blocked. setup: subscribed to two big proxy-list channels, taps the newest ee-link when the current one dies, tolerates the sponsored channel pin. monthly cost zero. we’d add only one thing to what she’s already doing: two-step verification, because the one realistic way her setup goes wrong isn’t the proxies at all, it’s an SMS-interception account takeover, and a cloud password closes it.

same app, three unrecognizably different network strategies, and each one correct for its owner. that’s the actual thesis of this guide.

glossary

quick reference for terms this guide and proxy vendors throw around:

• MTProto: Telegram’s own client-server protocol; also (confusingly) the name of the proxy type that speaks it.
• MTProto proxy / MTProxy: a relay carrying only Telegram traffic, configured with a secret, built for censorship circumvention.
• secret: the 16-byte value (32 hex chars, sometimes base64) that configures an MTProto proxy connection; its prefix (none/dd/ee) indicates obfuscation mode.
• fakeTLS / ee-secret: MTProto obfuscation mode that disguises proxy traffic as a TLS 1.3 session to an innocent domain.
• DPI (deep packet inspection): firewall technology that classifies traffic by content and shape rather than just addresses; what fakeTLS is designed to defeat.
• SOCKS5: general-purpose TCP proxy protocol (RFC 1928) with optional username/password auth (RFC 1929); one of Telegram’s two supported proxy types.
• sponsored channel: the channel an MTProto proxy operator may pin to the top of connected users’ chat lists; the monetization of free proxies.
• ASN: autonomous system number, the network-level identity of an IP’s owner; the fastest way to tell datacenter from carrier IPs.
• CGNAT (carrier-grade NAT): how mobile carriers put hundreds of users behind one public IP; the structural reason mobile IPs carry high trust.
• dedicated port: a proxy endpoint (IP + port + credentials) assigned to exactly one customer; opposite of a shared pool.
• sticky session: keeping one IP for the duration of your work rather than rotating; default-correct for account management.
• rotation: changing the exit IP, ideally on demand from the same carrier pool; default-correct for scraping.
• PeerFlood: the Telegram error signalling behaviour-based rate limiting on an account, the practical ceiling automation hits; IP reputation determines how much slack precedes it.
• session / authorization key: the credential a logged-in Telegram client holds; lives on the device, not bound to an IP.
• userbot: automation driving a normal user account through MTProto client libraries (Telethon, Pyrogram, GramJS), as opposed to the official Bot API.

FAQ

can I use both at once? not within one Telegram client, the app uses one active proxy at a time. you can save several and switch. (some people run Telegram-behind-MTProto for censorship and a separate automation stack on SOCKS5, that’s two clients, perfectly fine.)

does Telegram throttle proxied connections? no. slowness through a proxy is the proxy.

can a proxy steal my Telegram account? no, neither type can. account compromise needs your login code or session keys, both of which stay end-to-end with Telegram. the proxy hop never holds them.

why does my MTProto proxy show a different sponsored channel this week? the operator changed it. it’s their slot, they can.

is MTProto more secure than SOCKS5 because the secret looks fancier? no. the secret is obfuscation, for beating DPI, not extra encryption of your content. content security is identical under both: it’s MTProto-the-protocol end to end with Telegram, regardless of the pipe.

HTTP proxy in Telegram Desktop, where does that fit? it’s there, it works, it has no advantage over SOCKS5 for Telegram and fewer features (no UDP, relevant if you ever proxy calls). use SOCKS5 unless something in your network forces HTTP.

do mobile proxies work for Telegram in censored countries? as the IP layer, beautifully, a carrier IP is the most normal thing Telegram ever sees. but raw SOCKS5 doesn’t hide protocol shape from a national DPI box, so in hard-censorship environments pair it with a tunnel that does (VPN or shadowsocks) rather than relying on SOCKS5 alone.

what does a dedicated mobile SOCKS5 port cost? ours start at $40/mo for one port on the plans page, with a 24-hour free trial that provisions a real port, log a session in through it and watch how it behaves before you pay anything.

is there a quality difference between MTProto proxies, or are they all the same? real differences: secret type (ee beats dd beats plain, per the formats section), load (fresh and obscure beats popular and listed), location (near you and near a Telegram DC beats neither), and operator (known beats anonymous). a community-run ee-secret proxy on a quiet box is a different product from link #14 on today’s mega-list, even though both are “free MTProto”. the variance among free proxies is honestly bigger than the variance among paid SOCKS5 providers.

Telegram Desktop has an HTTP proxy option my provider gave me creds for, is that worse than SOCKS5? for plain Telegram messaging, functionally equivalent, both just carry the TCP stream. SOCKS5 is the better habit anyway: mobile apps don’t support HTTP at all (so your config doesn’t transfer to your phone), and SOCKS5 handles UDP, which matters if you ever enable proxy-for-calls. if the same port speaks both, as ours do, point Desktop at SOCKS5 too and keep one mental model.

will Telegram Premium or my existing subscriptions behave differently through a proxy? no. payments, premium features, channel subscriptions, all of it is account-level and protocol-level, the network path doesn’t enter into it. the one caveat: app-store payments follow your store region, which has nothing to do with your proxy and everything to do with your Apple/Google account.

my proxy is in country X, will my account “become” an X account? accounts don’t have a network nationality, your number’s country code and your usage shape matter more. what does follow the IP: content geo-restrictions where Telegram applies them, and the localization some bots and services infer from your apparent location. an SG IP makes you look like an SG user to those, which is sometimes precisely the point.

can I share my dedicated SOCKS5 port with a friend? technically trivially, operationally it defeats the purpose. the value of a dedicated port is that its history is yours alone; the moment two people’s behaviour mixes on it you’ve rebuilt a tiny shared proxy. ports are cheap relative to accounts, give the freind their own. (and yes, providers can usually see multi-device patterns, most dedicated plans, ours included, are priced and policed per port, not per human.)

do I need different proxies for Telegram and TikTok/Instagram/WhatsApp if I manage all of them? the IP layer transfers: a clean dedicated mobile IP is the right base for any platform that scores networks, and one port can back one identity across several platforms. what doesn’t transfer is the per-app config (WhatsApp’s proxy support, for instance, is its own thing and far more limited). we wrote up the TikTok-specific version of this playbook separately.

how do I know if my current proxy is why my account is struggling? quick differential: check the exit IP’s ASN and abuse-db status (audit section above); if it’s datacenter or pre-flagged, that’s your likely answer. then take one affected account, move it to a known-clean dedicated IP, change nothing else for two weeks, and compare challenge/limit frequency. one variable at a time, like any debugging.

what happens to my sessions if my proxy provider disappears overnight? nothing fatal. sessions live on your devices, not on the proxy. you lose the network path, reconnect through anything else, and carry on, with the caveat from the sessions section that a pile of simultaneous fresh-IP reconnects on young accounts is mildly spendy, reputation-wise. it’s a good argument for providers that look durable, and a better one for not building on free servers.

the bottom line, restated one last time: MTProto answers “I can’t reach Telegram”, SOCKS5 answers “my accounts need to live somewhere clean”. figure out which sentence is yours and the protocol picks itself.