What telegram does when two devices use the same session

Two different things get called “using the same session”

People ask us this a lot, and almost every time they’re describing one of two very different situations. The first is normal: you’re logged into Telegram Desktop, your phone, and Telegram Web at the same time, and everything works fine. The second is the one that causes real problems: the exact same session credentials (one auth key, one session file) get run from two places at once, usually because someone copied a .session file to a second machine, or restarted an automation script without stopping the old process first.

Telegram’s client apps are built to support the first case. They are not built to support the second, and the protocol has specific behavior for detecting and shutting it down.

How a session actually gets created

When you log into Telegram, whether through the phone number and code flow or a QR scan, the client and Telegram’s servers run a Diffie-Hellman key exchange. The result is an authorization key, usually called the auth key, that’s unique to that login. Every device or app that logs in separately generates its own auth key through its own exchange. That’s why Settings > Devices shows a list: each entry is a distinct auth key with its own session ID, and Telegram’s servers are happy to keep dozens of them alive for one account at the same time.

That auth key is what a session file actually stores. Tools built on MTProto, things like Telethon, Pyrogram, or GramJS, save it to disk (as a SQLite file, a string session, or similar) so the client doesn’t have to redo the login flow every time it starts. The file is portable. You can move it to another machine, load it into another script, and it will authenticate immediately, no phone number or code needed. That portability is exactly what causes the problem, because nothing stops you from loading that same file in two places at once.

What happens when one auth key runs in two places

An auth key carries state beyond just “this account is authenticated.” It tracks a message sequence number and a server salt that both sides use to keep MTProto’s encrypted transport in sync. That state assumes a single active connection. When two separate processes open connections using the identical auth key, they’re both trying to advance the same sequence counter and both expect the salt to match what they last saw. The two connections step on each other. You’ll see symptoms like updates arriving out of order, messages getting missed on one side, or connections dropping and reconnecting for no obvious reason.

If the two processes are also reading and writing the same local session file, whether that’s the SQLite session Telethon uses or a saved state file some other library keeps, you get a second problem on top of the protocol one: file locking. SQLite doesn’t handle two processes writing to the same file well in this context, and it’s common to see “database is locked” errors when two instances try to persist state to the same session file at the same time.

But the more important part happens on Telegram’s side, not yours.

AUTH_KEY_DUPLICATED and why it exists

Telegram’s servers watch for an auth key being used from more than one IP address in overlapping windows. When that happens, the server can conclude the key has been duplicated, either through legitimate reuse like this or through the key being stolen, and it responds with an error code MTProto libraries surface as AUTH_KEY_DUPLICATED. This isn’t a bug in Telethon or Pyrogram, it’s the server telling the client the key is no longer trusted as belonging to one client. The practical effect is that the key gets invalidated and the affected session has to log in again from scratch, which for automation means going through the phone/code flow again, not just restarting the process.

This exists for a good reason. From the server’s point of view, it has no way to distinguish “the operator copied their own session file to a second box by mistake” from “someone stole this session file and is now running it from a different network.” Both look identical: the same auth key, suddenly active from two IPs. Treating it as a possible compromise and forcing re-authentication is the conservative, correct call, even though it’s annoying when the cause was innocent.

Where this actually shows up

In our experience running Telegram hosting, this almost never comes from a user logging into their phone and laptop at the same time, that’s the multi-device case and it’s fine. It comes from operational habits:

Migrating a bot or userbot from one server to another and starting the new instance before stopping the old one, so both are alive on the same session for a few minutes.
Restoring a session file from a backup onto a fresh box for testing, while the original is still running in production.
Running the same automation script twice by accident, once manually and once through a scheduler, both pointed at the same session file.
Sharing a session file between a local dev environment and a hosted instance to “check something quickly” without shutting the hosted one down first.

Every one of these puts two live connections on one auth key, even briefly, and briefly is often enough to trigger a duplicate flag.

How to avoid it

The rule is simple even if the habits around it aren’t: one session, one running process, at all times. If you’re migrating hosting, stop the old process, confirm it’s actually stopped (not just the script exiting, but the connection torn down), and only then start the new one on the same session file. If you need to test something against a live account, either duplicate the login as a genuinely new session (its own auth key, its own device entry) rather than copying the file, or accept the downtime while the original instance is paused.

This matters more, not less, if you’re running Telegram through proxies, since that’s most of what we manage. A proxy changes the IP the connection appears to come from, but it doesn’t change which auth key is being used. If you route the same session through two different proxy endpoints at once, thinking of it as “two different connections” because the exit IPs differ, Telegram’s server-side check doesn’t care about the proxy layer at all. It’s still one auth key active from two places, and it gets treated the same way.

If it already happened

If you’ve hit AUTH_KEY_DUPLICATED or found a session logged out with no clear cause, the fix is to re-authenticate that session cleanly: generate a new session file through a fresh login, and retire the old file rather than trying to keep reusing it. Don’t just restart the same script and hope the same auth key still works, it usually won’t. And going forward, treat session files the way you’d treat any other credential you wouldn’t want copied around loosely: one authoritative copy, one place it runs, and a clean handoff any time it needs to move.

If you’re setting up Telegram hosting or proxy infrastructure and want to get the session handling right from the start, take a look at what we run.

Get new guides and videos first — join the Telegram channel.