How to set up your own MTProto proxy for Telegram
Your own MTProto proxy is a process on your VPS that Telegram clients connect to, and that then proxies their traffic to the messenger’s data centers. It is not hard to run: you need the server itself with a public IP, an open port, and a generated secret. Then you give users a tg://proxy link, and they connect with one tap.
The main difference from public proxies from Telegram channels is stability and control. Nobody except you burns the IP with mass traffic, nobody will turn off the proxy “because they got tired of paying for the VPS,” and you decide yourself whether to give access to other people.
Below: what you need to prepare, which parameters really matter, and how long one MTProxy on one IP lives on average.
In brief
- You need: a VPS with a public IP, an open port (443 is better), and 1 GB of RAM is more than enough.
- You can run it from the official
TelegramMessenger/MTProxyrepository or via Docker. - The secret is 32 bytes; in fake-TLS format it has the ee prefix and an encoded camouflage domain.
- Client link:
tg://proxy?server=<ip>&port=<port>&secret=<hex>. - Port 443 works everywhere HTTPS is not cut off — that is almost any network.
- One IP lives from weeks to months if you do not expose the link in public channels.
What you need to run it
The proxy itself is not demanding, but there are several important requirements for the server.
VPS and network
The cheapest VPS (1 CPU, 1 GB RAM) from any provider outside Russia will do. The key requirements are a public external IP without NAT and the ability to open the required port. Use unlimited or generous traffic: 1 active Telegram user = tens of gigabytes per month, especially if they watch videos and media-heavy channels.
Port
Technically, any free TCP port works. In practice, 443 is better: operators almost never cut off outgoing HTTPS completely, and MTProxy with fake-TLS will mimic it very well. If 443 is occupied by something else, such as nginx, run it on 8443 or another non-standard port.
MTProxy server
The canonical option is to build and run the server code from the github.com/TelegramMessenger/MTProxy repository. It is also available as an official Docker image: hub.docker.com/r/telegrammessenger/proxy — it starts with one command and is convenient for updates.
Secret
This is a 32-byte key that is the same on the server and the client. The server generates it at startup; there is a utility and there are ready-made scripts. The modern format is fake-TLS: the ee prefix + the key itself + an encoded domain name, for example www.google.com. The proxy will camouflage the handshake as this domain.
What matters during setup
| Parameter | Recommendation | Why |
|---|---|---|
| Port | 443 (or 8443) | Not cut off by operators, looks like HTTPS |
| Secret mode | Fake-TLS (ee prefix) | TLS camouflage, harder for DPI to detect |
| Camouflage domain | Popular site (cloudflare.com, googlevideo.com) | The less exotic the domain, the less suspicion |
| Promo channel | Optional, in TAG=... | Telegram shows a pinned channel to proxy owners |
| Connection limit | Depends on RAM and bandwidth | Without limits, the VPS can be brought down |
| Logs | Minimum, without IP addresses | No reason to store sensitive user data |
How to check right now
After starting MTProxy, the first thing to check is whether it is reachable from different operators. Sometimes a VPS in a popular subnet, for example at DigitalOcean, is already in someone’s filter, and the proxy simply does not respond from Russia, even though everything is OK locally for you.
Freedom Checker can check the availability of IP addresses and services from probes in different Russian regions and operators. Run your VPS through it — and it will be immediately clear where it is reachable and where it is not.
Failure or blocking?
A failure is when MTProxy itself does not respond: the process crashed, disk space ran out, or the server rebooted. Symptom: the proxy does not work for you or for a test user in any country. The fix is to restart the service.
Blocking is when the server is alive and responds from outside, but does not respond from a specific network. Symptom: your proxy is reachable externally, but a client in Russia is stuck on Connecting. Most often this is being cut by IP/subnet at the operator. You need to change not the proxy settings, but the IP — take a new VPS in a less “hot” subnet.
What to watch for
- Do not publish the link in large open channels — the IP will be mass-blocked within days.
- Share only the tg://proxy link; the raw secret is not needed.
- Set up a cron job to back up the config and automatically restart the service if it crashes.
- Monitor VPS traffic — the provider may disconnect you for exceeding the limit.
- Change the port/camouflage domain if the proxy suddenly stops working for some users.
- Do not use VPSs in subnets that are already widely associated with MTProxy.
- No logs with client IP addresses — this is both about privacy and about your security.
Conclusion
Your own MTProxy on a VPS is a resilient alternative to public proxies from open channels. It costs almost nothing, can be set up in half an hour, and lives as long as you are willing not to “expose” it in public lists.
Once you configure it, check that the proxy responds from the operators and regions you are running it for. Without such a check, it is easy to end up with “it works for me, but not for the user.”