Активные сессии Telegram: кто ещё сидит в аккаунте

Что показывает список активных сессий

Список приходит методом account.getAuthorizations, каждая строка — это конструктор authorization. В интерфейсе он живёт в разделе «Устройства», и клиент показывает оттуда далеко не всё. Полный состав полей такой:

Самое интересное — не поля, а флаги. Их шесть, и два из них читаются как сигнализация.

• official_app — сессия открыта официальным приложением. Нет флага, значит заходили чем-то другим: сторонним клиентом, библиотекой, скриптом.
• password_pending — код ввели, а облачный пароль ещё нет. Переписку такая сессия не видит.
• current — та сессия, из которой вы сейчас смотрите список.
• unconfirmed — новый вход, который вы ещё не подтвердили. Про эту механику и про семидневное окно подтверждения — в разборе того, что отвечает сервер при входе.
• encrypted_requests_disabled и call_requests_disabled — примет ли эта сессия секретные чаты и звонки.

Как понять, что в аккаунт зашли не вы

Порядок простой, и он не требует ничего, кроме внимательного чтения списка.

1. Смотрите date_created, а не только «был в сети». Дата входа — это момент, когда сессию завели. Если она старше вашего последнего входа на этом устройстве, устройство не ваше.
2. Сверяйте страну и регион. Они считаются по IP последнего подключения, так что «Москва» на аккаунте, которым вы пользуетесь из Алматы, — это не глюк отображения.
3. Проверяйте флаг официального приложения. Строка без него у человека, который в жизни не ставил ничего, кроме приложения из магазина, объясняется одним способом.
4. Отдельно ищите строку с password_pending. Она значит, что попытка входа была, код дошёл, а пароль остановил.

Про страну есть оговорка, которую честно стоит проговорить: Telegram пишет, что страна и регион определяются по IP, и всё. Через какую базу и с какой точностью — не публикуется. Мобильный оператор или провайдер вполне могут дать соседний регион. Ориентир — расхождение в масштабе страны, а не города.

Почему чужую сессию не выкинуть сразу

Дальше начинается место, где люди в панике жмут кнопку и получают невнятную ошибку. Вот что за ней стоит.

Завершение одной сессии — account.resetAuthorization с её хэшем. Завершение всех, кроме текущей, — auth.resetAuthorizations. Оба метода отвечают ошибкой 406 FRESH_RESET_AUTHORISATION_FORBIDDEN с дословной формулировкой: нельзя разлогинить другие сессии, если с момента входа в текущую прошло менее 24 часов.

И это правило шире, чем кажется. В справочнике ошибок тот же код закреплён за четырьмя методами сразу:

• account.resetAuthorization — завершить одну сессию;
• auth.resetAuthorizations — завершить все;
• account.setAuthorizationTTL — настроить автовыход;
• account.initPasskeyRegistration — завести passkey.

То есть человек, который только что вошёл в аккаунт с нового устройства, первые сутки не может ни вычистить чужие входы, ни включить автоочистку, ни привязать passkey. Логика понятная: иначе угонщик заходил бы и мгновенно выбрасывал хозяина. Но для того, кто как раз хозяин и есть, это выглядит как поломка — и лечится только ожиданием.

Рядом живёт похожая, но другая пара ошибок — SESSION_TOO_FRESH и PASSWORD_TOO_FRESH. Они тоже про 24 часа, но про другое: про передачу прав создателя канала и вывод дохода. Их разбор — в статье про удаление и сброс аккаунта. Путать не стоит: свежая сессия мешает отдать канал, а свежий вход мешает выгнать чужих.

Что делает автовыход по сроку

У сессий есть срок жизни в днях. Текущее значение приходит вместе со списком — поле authorization_ttl_days лежит прямо в ответе account.getAuthorizations, рядом с массивом сессий. Меняется оно методом account.setAuthorizationTTL. Сессия, в которую столько дней не заходили, завершается сама.

Значения по умолчанию в открытом конфиге нет — я специально прогнал по нему поиск, ключа authorization_ttl_days там не встречается вовсе, он приходит только ответом метода. Допустимый диапазон тоже не опубликован: на неподходящее число сервер отвечает TTL_DAYS_INVALID. Забавная деталь — эта ошибка закреплена за двумя методами, и второй из них account.setAccountTTL, срок самоуничтожения самого аккаунта. Две совершенно разные протухалки живут на одном коде ошибки.

Ещё одна настройка по конкретной сессии — account.changeAuthorizationSettings. Ей же подтверждают новый вход, ей же отключают приём секретных чатов и звонков в отдельно взятой сессии. Хэш перепутали — приедет HASH_INVALID.

Веб-сессии — второй список, про который забывают

Когда вы входите на сторонний сайт кнопкой «Log in with Telegram», создаётся не обычная сессия, а веб-авторизация. Живёт она отдельно, и чистка списка устройств её не касается.

Состав полей другой, и по нему видно назначение:

• bot_id — бот, через которого сайт вас пустил;
• domain — домен сайта;
• browser и platform — браузер и платформа;
• ip и region — адрес и регион. Страны здесь нет вообще, в отличие от обычной сессии.

Завершается такая авторизация методом account.resetWebAuthorization — своим, не тем, которым выкидывают устройства. Так что если вы год назад залогинились Telegram-ом на форуме, в списке устройств вы этого не увидите никогда.

Если доступ уже потерян

Здесь я не буду ничего изобретать: у Telegram есть официальный порядок действий, и он зависит от того, остался ли у вас хоть один вход.

Telegram открыт на другом устройстве. Включить двухэтапную проверку — тогда одного номера для входа станет мало. Завершить сессию потерянного устройства. Попросить оператора заблокировать старую SIM и выпустить новую с тем же номером.

Открытых устройств не осталось. Первым делом оператор: блокировка SIM и новая карта с тем же номером. Дальше вход по коду на восстановленный номер.

Обратите внимание, что в обоих сценариях центральная роль у номера, а не у поддержки. В телеграмме аккаунт держится на номере, и всё восстановление крутится вокруг него. Способа «написать в Telegram, чтобы вернули аккаунт» в документации нет — как нет и способа снять через поддержку забытый облачный пароль.

Что из этого следует, если аккаунт вы купили

Для тех, кто работает с покупными аккаунтами, всё описанное превращается в несколько сухих правил. Они скучные, но экономят и деньги, и нервы.

1. Закладывайте сутки. Вошли в аккаунт — первые 24 часа вы не почистите чужие сессии, не поставите автовыход и не заведёте passkey. Аккаунт «на сегодня к вечеру» так не работает.
2. Пароль ставьте сразу. Он не ждёт никаких суток и сразу обрубает вход по одному коду. Всё остальное — потом.
3. Смотрите на дату последней активности. date_active честно показывает, живой аккаунт или лежит на складе месяцами. Как читаются другие признаки возраста и траста, разобрано в типах аккаунтов.
4. Помните про api_id. Он виден в списке сессий. Поэтому индивидуальный идентификатор приложения у каждого аккаунта — не блажь, и лежит он в json-сайдкаре рядом с файлом сессии; чем именно отличаются форматы TDATA и session+json, разобрано отдельно.
5. Не смешивайте роли. Один аккаунт — одна задача, свой прокси, своя связка. Про это — разбор мультиаккаунтинга.

У нас каждый аккаунт проверяется вживую в момент выдачи: коннект через прокси, проверка ограничений, ответ служебного бота. Это снимает вопрос «а он вообще живой», но не снимает вопрос «а кто в нём ещё сидит» — на него отвечает только список сессий, и смотреть его надо своими глазами, сразу после входа. Держать аккаунты стабильно онлайн помогают резидентные прокси, а под связки на 4G — мобильные.

И последнее, уже про сбор. Сессии — это про вашу сторону. Чужую активность в чатах они не показывают: там работают участники чата, активные писавшие и комментаторы канала. Три разных среза одной аудитории, и расхождение между ними обычно говорит больше, чем каждый по отдельности.

Частые вопросы

Состав полей сессии — из описания конструктора authorization, правило 24 часов и список методов, за которыми закреплена ошибка, — из страницы метода и машиночитаемого справочника ошибок, порядок действий при потере доступа — из FAQ Telegram. Всё сверено 19 августа 2026 года. В телеграмме такие вещи меняются без анонса, так что если читаете это сильно позже — перепроверьте по первоисточнику.