Set Up Your Own MTProto Proxy on a VPS (2026 Guide)
Set Up Your Own MTProto Proxy on a VPS (2026 Guide)
This is a working tutorial. By the end you will have a real MTProto proxy running on an Ubuntu VPS, listening on port 443, with a fake-TLS secret and a tg:// link you can hand to your phone. We run telegram infrastructure for a living, so the second half is the honest part: why this exact setup gets flagged by Telegram faster than people expect, and what we do differently on managed hosting.
If you want the background on what this protocol even is before you start, we wrote what is MTProto proxy explained and what is the MTProto protocol explained. This guide assumes you just want to build one.
what you will end up with
A single Ubuntu server running one container. That container speaks Telegram’s MTProto proxy protocol and disguises the traffic as ordinary HTTPS using fake-TLS (the ee secret format). To anything watching the wire, it looks like a normal TLS handshake to a website you pick. Your Telegram client connects through it, and your real connection to Telegram’s data centers is hidden behind your VPS IP.
What this gets you: a circumvention proxy. If your network blocks Telegram, routing through a server in a country that does not block it restores access. That is the legitimate use, and it works.
What this does not get you: a clean, trusted IP for running accounts. A proxy changes where your traffic appears to originate. It does not change what kind of IP that origin is, and that distinction is the whole story. More on that below.
before you start
You need three things.
1. A VPS you control. Any provider with Ubuntu 22.04 or 24.04 and a public IPv4 address works. One vCPU and 1 GB of RAM is plenty; MTProto proxying is cheap. Pick a region where Telegram is not blocked, because the proxy can only be as reachable as the server behind it.
2. Root or sudo access. Everything here runs as root or via sudo. If your provider gives you a non-root user, prefix the commands accordingly.
3. A domain to imitate. Fake-TLS works by pretending to be a real HTTPS site. You pick a well-known domain whose TLS fingerprint your proxy will mimic during the handshake. Common choices are large CDNs or popular sites. You do not own this domain and you do not need to; you are borrowing its public TLS appearance so your handshake blends in.
That is it. No Telegram account is required to run the proxy itself, though you obviously need one to test it.
the step-by-step
We use MTG, the most maintained MTProto proxy implementation, shipped as a docker image. Doing it by hand with the official mtproto-proxy is possible but MTG handles fake-TLS, secret generation, and sane defaults without you compiling anything.
1. Update the box and install Docker.
sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
docker --version
If docker --version prints a version string, the engine is running.
2. Generate the fake-TLS secret.
The secret encodes two things: the random key the client uses, and the domain your proxy will imitate. MTG generates both in one command. Replace the domain with the site you chose in the previous section.
docker run --rm nineseconds/mtg:2 generate-secret --hex www.cloudflare.com
This prints a long hex string starting with ee. The ee prefix is what marks it as fake-TLS (the older dd prefix is plain secure mode and is more detectable, so do not use it in 2026). Copy that whole string somewhere safe. We will call it YOUR_SECRET below.
3. Run the proxy on port 443.
Port 443 matters. It is the HTTPS port, so a proxy living there looks exactly like a web server to anyone scanning your IP. Running MTProto on some odd high port is a giveaway.
docker run -d \
--name mtg \
--restart unless-stopped \
-p 443:3128 \
nineseconds/mtg:2 \
simple-run -n 1.1.1.1 0.0.0.0:3128 YOUR_SECRET
That maps the container’s internal port 3128 to your server’s public port 443. The -n 1.1.1.1 sets the DNS resolver the proxy uses. Swap YOUR_SECRET for the real ee... string from step 2.
Check it came up:
docker logs mtg
docker ps
You want to see the container listed as up, and the logs reporting it is listening with no fatal errors.
4. Open the firewall.
Most Ubuntu images ship with ufw available but inactive, or with a provider firewall in front. Allow SSH first (so you do not lock yourself out), then 443, then enable.
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status verbose
If your provider has its own cloud firewall in their dashboard, open 443/tcp there too, or none of this is reachable.
5. Build the connection link.
The link Telegram understands has three parts: server IP, port, and secret. The format is:
tg://proxy?server=YOUR_SERVER_IP&port=443&secret=YOUR_SECRET
MTG can print this for you, which avoids typos:
docker run --rm nineseconds/mtg:2 access \
--domain YOUR_SERVER_IP --port 443 --secret YOUR_SECRET
That outputs the tg:// URL and an https://t.me/proxy?... web link that does the same thing. Either one, tapped on a phone with Telegram installed, prompts to connect.
6. Test it.
On your phone, open the tg://proxy?... link. Telegram asks if you want to use the proxy. Accept, then go to Settings, Data and Storage, Proxy Settings. A working proxy shows a green connected status and a ping in milliseconds. Send yourself a message. If it goes through and the proxy shows connected, you are done building.
Before you trust it, confirm it is not leaking your real IP or DNS. We walk through that check in how to test if your Telegram proxy is leaking. Do this step; a proxy that quietly falls back to your real connection is worse than no proxy because you think you are covered.
what can go wrong
Container exits immediately. Run docker logs mtg. The usual cause is a malformed secret (you pasted only part of the ee string) or the domain in the secret not resolving. Regenerate the secret and try again.
Connects but no messages. Almost always the firewall. Re-check ufw status and your provider’s cloud firewall. Port 443 must be open inbound from anywhere.
Works for a day, then stops. This is the important failure, and it is not a bug. Telegram, ISPs, and DPI systems actively scan and blocklist proxy IPs. A datacenter IP running a service on 443 that does not behave like a real website over time gets fingerprinted. When that happens the proxy is dead and you spin up a new VPS, which gets flagged again. This treadmill is the real cost of self-hosting, and it is why the next section exists.
Port 443 already in use. If you run a web server on the same box, 443 is taken. Move the proxy to its own server. Do not share the IP; mixing a real site and a proxy on one address makes both look stranger, not safer.
why one VPS IP gets flagged
Here is the part most tutorials skip. The proxy you just built works at the protocol level. The problem is the IP it runs on.
Every IP address belongs to an Autonomous System, identified by an ASN. Datacenter ASNs (the ones VPS providers use) are well known and publicly mapped. Telegram knows which ASNs are hosting providers and which belong to real mobile carriers. Traffic that originates from a datacenter ASN is treated with far more suspicion than traffic from a residential or mobile carrier ASN, because automated abuse overwhelmingly comes from cheap datacenter servers. We explain this in detail in what is ASN and why it matters for Telegram IP.
So your fake-TLS handshake can be flawless and your proxy can still get your account rate-limited or flagged, because the IP underneath announces “datacenter” to anyone who looks up its ASN. Fake-TLS hides the contents of your traffic. It does nothing to hide where the traffic comes from at the network-ownership level.
This matters most if you are not just unblocking Telegram but actually running an account through the proxy. A single shared or datacenter IP carrying account traffic is exactly the pattern Telegram’s anti-abuse systems are tuned to catch. If your goal is account stability rather than censorship circumvention, a self-hosted VPS proxy is the wrong tool. We compare the approaches directly in MTProto vs SOCKS5 vs cloud phone for Telegram, and we put numbers on the difference in what is a mobile IP and why Telegram cares.
There is a second, quieter issue: carrier-grade NAT. Real mobile users share a carrier IP with thousands of other phones, which makes a mobile IP genuinely hard to single out. A datacenter IP serves one customer. That difference in how the IP is used, not just who owns it, is covered in carrier-grade NAT and Telegram.
how this looks on managed hosting
We are a Singapore business that runs managed Telegram hosting, so I will be specific about what we do instead of waving at it.
The proxy protocol is the easy part; we run the same kind of MTProto and SOCKS5 plumbing you just built. The difference is everything underneath. Our IPs are real mobile IPs on Singapore carriers (SingTel, M1, StarHub, Vivifi), not datacenter addresses. When Telegram looks up the ASN behind your session, it sees a mobile carrier, because it is one. That is the whole reason the Singapore mobile IP advantage for Telegram exists, and why a dedicated mobile IP behaves differently from a VPS.
We also run accounts on a fleet of real Samsung devices in the cloud, not bare client processes on a server, so the device fingerprint is a genuine phone too. And we use a BYO-number model: you bring your own phone number, you receive your own OTP, and you own the account end to end. We never hold your number and we do not sell accounts. If you want the head-to-head, we wrote TelegramVault vs a self-hosted MTProto proxy, TelegramVault vs MTProto proxies from GitHub, and TelegramVault vs a VPS with Telegram CLI.
To be fair to the DIY path: if your only goal is to unblock Telegram on a censored network, the VPS proxy above is genuinely fine and free. Build it. The managed route is for people whose accounts need to survive Telegram’s spam and ban systems over months, which is a different problem than getting through a firewall once. If you want the why behind the bans, why Telegram bans accounts and how Telegram’s spam algorithm actually works are the honest writeups. The home-versus-hosted tradeoff is in self-hosting Telegram at home vs managed hosting, and the number-ownership model in BYO-number Telegram hosting explained.
You can also read the protocol straight from the source: core.telegram.org MTProto docs. And our sister infrastructure for general mobile-IP needs lives at singaporemobileproxy.com and cloudf.one.
final word
Setting up an MTProto proxy on a VPS is a one-evening job and the tutorial above is the real thing, commands and all. It will get you through a block. What it will not do is give you a trusted IP, because the IP is a datacenter IP no matter how good your fake-TLS is, and Telegram knows the difference at the ASN level.
If you are circumventing censorship, you now have what you need. If you are trying to run accounts that stay alive, the proxy is the wrong layer to solve it at. That is the gap we built our business to fill: real Singapore mobile IPs, real cloud devices, your own number, no accounts sold. If that is the problem you actually have, start at our home page and use code TGYT. Either way, build the proxy first; you will understand exactly what managed hosting is replacing.