Moving your MTProto proxy to a new IP without losing users
Why the IP changes in the first place
Nobody moves a working proxy for fun. The usual triggers are a hosting provider reclaiming or reassigning the address, an ISP or national firewall adding your IP to a blocklist after enough flagged connections, a datacenter migration, or you deciding to switch providers for cost or reliability reasons. Whatever the cause, the problem is the same: you have a population of users whose Telegram clients are already configured to dial a specific address, and that address is about to stop working.
The severity of that problem depends entirely on one decision you made when you first set the proxy up: did you distribute a raw IP address, or a hostname.
What actually breaks when you move
An MTProto proxy connection is defined by three things: a server value, a port, and a secret. Telegram clients build the tg://proxy?server=...&port=...&secret=... link (or the t.me/proxy?... equivalent) from those three fields, and the client dials whatever string sits in the server field.
If that field is a literal IP address, the link is permanently tied to that address. The moment you shut down the proxy on the old IP, every link you’ve ever published stops connecting. It doesn’t matter that the secret is still valid or that the proxy itself is running fine on the new box. The client has no way to know the service moved, because nothing told it to look anywhere else.
If that field is a hostname you control, the client resolves it through the OS resolver each time it connects. Point the DNS A record at the new IP, and every previously distributed link starts working against the new server without you touching the link text, the secret, or anything the user has saved.
This is the entire difference between a clean migration and a support headache.
Use a hostname, not a raw IP, from the start
If you’re setting up a proxy today, don’t paste the server’s public IP into the connection link. Register or reuse a subdomain, point an A record at the box, and use that hostname in every link you generate. It costs nothing extra and it’s the single decision that makes every future migration a non-event instead of a mass outage.
This matters more for MTProto proxies than for most services because the whole point of the protocol is to look like ordinary traffic to a firewall that’s trying to fingerprint and block it. Servers that host these proxies get burned and blocked more often than typical infrastructure, so you should assume you’ll need to move at some point and build for it up front.
If you inherited a proxy that’s already running on a bare IP, the migration is still doable, it’s just not silent. More on that below.
The migration sequence
Assuming you built the proxy on a hostname, the actual move is straightforward:
1. Bring the proxy up on the new server first, with the same secret. MTProto proxy daemons (the official MTProxy binary or a third-party implementation like mtg) don’t care which box they run on. As long as the secret string matches what you already handed out, a client reconnecting to the new IP authenticates exactly like it did against the old one. There’s no secret rotation involved unless you specifically want one.
2. Lower the DNS TTL before you touch anything. If your A record currently has a long TTL, cut it to something short, a few minutes, at least a day ahead of the cutover. Resolvers and ISPs cache DNS answers for the duration of the TTL, so a long TTL means a long tail of clients still resolving to the old IP after you’ve already flipped the record.
3. Verify the new proxy is actually reachable on the port you’re advertising before you touch DNS. Test it with a second device on a different network, not just from inside the same datacenter, since intra-network routing can mask a firewall rule you forgot to open.
4. Flip the A record to the new IP.
5. Keep the old server running for a window after the flip. This is the part people skip. Even with a short TTL, some resolvers, some VPN or corporate networks, and some Telegram clients that haven’t reconnected since before the change will still show up at the old IP for a while. Leaving the old proxy alive for a day or two catches that tail without dropping anyone.
6. Watch connection counts on both boxes before you decommission the old one. MTProxy exposes a stats endpoint you can poll for active connection counts; third-party implementations usually have something equivalent. When the old server’s count has dropped to zero, or close enough that you’re comfortable, take it down.
Handling links that already went out with a bare IP
If your existing links have the raw IP baked in, you don’t get the quiet DNS-flip version of this. You have two honest options.
The first is to accept the break and communicate it. Post the new t.me/proxy?... link wherever you originally shared the old one: pinned channel message, bot welcome text, website. Anyone who re-adds the proxy from that fresh link is fine. Anyone who saved the old link and doesn’t come back to get the new one drops off. This is workable if your audience checks the channel regularly, less workable if the proxy is meant to keep working invisibly in the background.
The second is to run both the old and new proxy in parallel indefinitely, or as close to indefinitely as your old hosting arrangement allows, while you migrate new users onto a hostname-based link going forward. This buys time but doesn’t solve the underlying problem, it just delays the day you finally have to cut the old IP loose.
Either way, this is the point where it’s worth fixing the setup properly: put a hostname in front of the new server now, even if the old links stay IP-based, so the next migration doesn’t repeat this.
Watching the cutover
Don’t treat the DNS flip as the finish line. The failure mode to watch for isn’t total silence, it’s a slow trickle of users who never come back. Compare active connection counts on the new server against what the old server was carrying before the move. If the new number settles noticeably below the old one and stays there after a few days, something didn’t propagate, whether that’s a DNS resolver caching longer than expected, a client with a hardcoded IP somewhere in its config, or a link that got shared as an IP outside your control (screenshots, third-party proxy list sites, forwarded messages).
It’s also worth checking that the new server handles the same secret format your users are on. If the old proxy used a plain secret and the new one is set up with ObfuscatedTLS (the ee-prefixed secret that disguises the handshake as regular TLS), that’s a different secret string, not just a different address, and it needs its own link.
Where this fits into managed hosting
This is exactly the kind of detail that’s easy to get wrong once and expensive to get wrong twice, which is why we set proxies up behind a hostname by default for anyone we host at telegramvault.org. It means an IP change, whether it’s forced by a blocklist or just a provider swap, is a DNS record update instead of an announcement to every user telling them to reconnect.
If you’re running your own MTProto proxy and want a second pair of eyes on the setup before your next migration, or you’d rather have someone else own the uptime and the DNS hygiene, take a look at what we do.