Вход в Telegram по QR-коду: как он устроен

Как войти в телеграмм по QR-коду с телефона на компьютер

Со стороны человека всё занимает секунд десять: открыть Telegram на компьютере или в вебе, выбрать вход по коду, навести на экран камеру телефона, подтвердить. Ни номера, ни кода из SMS.

Внутри работают три метода и один апдейт. Разложу по шагам, потому что дальше почти все неочевидные вещи вытекают именно из порядка этих шагов.

1. Приложение, которое хочет войти, вызывает auth.exportLoginToken и передаёт свои api_id и api_hash. В ответ приходит auth.loginToken: двоичный токен и время, когда он протухнет.
2. Токен кодируется в base64url и вкладывается в ссылку tg://login?token=. Её и рисуют квадратиками — сам QR-код никакой криптографии не несёт, это просто способ показать ссылку камере.
3. Уже авторизованное приложение достаёт токен из ссылки, декодирует обратно в байты и вызывает auth.acceptLoginToken. Метод возвращает объект authorization — карточку той сессии, которую вы только что открыли.
4. Первому приложению прилетает апдейт updateLoginToken. Это сигнал повторить auth.exportLoginToken — и на второй раз вместо токена приходит auth.loginTokenSuccess. Всё, вход состоялся.
5. Если два приложения смотрят в разные дата-центры, вместо успеха возвращается auth.loginTokenMigrateTo с номером нужного DC. Тогда приложение идёт в указанный дата-центр и вызывает там auth.importLoginToken — и уже он отдаёт loginTokenSuccess.

Отдельно про шаг с камерой: сканирует не тот, кто входит, а тот, кто уже внутри. Эту асимметрию стоит держать в голове до конца статьи — на ней держится и удобство, и вся опасность механики.

Почему QR-код обновляется каждые полминуты

Срок жизни приезжает вместе с токеном, в поле expires. Документация описывает его осторожно — «обычно 30 секунд», и это единственная цифра, которую Telegram публикует. Когда срок вышел, приложение обязано запросить новый токен и перерисовать картинку; на просроченный код сервер отвечает AUTH_TOKEN_EXPIRED.

Смысл короткого окна простой. Пока код на экране, любой, кто его сфотографировал, может зайти в аккаунт вместо вас. Через полминуты снимок превращается в мусор: срок вышел, код мёртв. Никаких запретов, всё решают часы.

Кто имеет право принять QR-логин

Здесь машиночитаемые файлы Telegram говорят яснее, чем текст страницы. В конфиге лежит список из 40 методов, которые разрешено звать без авторизации. auth.exportLoginToken в нём есть с подписью «сгенерировать токен для входа по QR-коду». auth.importLoginToken тоже есть. А auth.acceptLoginToken — нет.

Справочник ошибок подтверждает то же самое со своей стороны: в его перечне unauthed_allowed лежат ровно два метода из трёх. И все три при этом помечены как user_only — из 656 методов, недоступных ботам. То есть токеном для входа по QR не может воспользоваться никакая автоматизация с токеном из BotFather; это механика живого аккаунта, и только его.

Почему одним аккаунтом нельзя войти дважды

У auth.exportLoginToken есть третий параметр, про который почти нигде не пишут: except_ids, вектор идентификаторов. Описание в справочнике методов дословное — «список уже вошедших пользователей, чтобы не войти дважды одним и тем же».

Приложение, рисующее QR, само сообщает серверу, какие аккаунты на этом устройстве уже открыты. Если отсканировать код тем аккаунтом, который тут и так есть, вход не продублируется. Для тех, кто держит на одном устройстве несколько профилей, деталь практическая — и она объясняет, почему QR иногда «не срабатывает» без всякой ошибки. Про сами лимиты на количество профилей есть отдельный разбор: два аккаунта Telegram на одном телефоне и мультиаккаунтинг без банов.

Там же, в параметрах, живёт ещё одна знакомая нашему читателю ошибка — API_ID_PUBLISHED_FLOOD, «этот API ID где-то опубликовали, пользоваться им больше нельзя». Она прилетает на самый первый шаг, до всякого QR. Что бывает с аккаунтами, работающими на разошедшихся по интернету ключах, разбирали в статье за что Telegram банит.

Что отвечает сервер, когда код не сработал

Ошибок ровно пять, и они разложены по методам неравномерно — это видно только в машиночитаемом справочнике, слой 227.

Мелочь, на которую я наткнулся при сверке: обзорная страница QR-логина перечисляет ошибку под именем AUTH_TOKEN_INVALID1, а машиночитаемый файл знает её как AUTH_TOKEN_INVALIDX. Расхождение на один символ, но если вы разбираете ответы сервера по строке имени — сломается именно на этом. Такие вещи ловятся только сверкой двух форматов одной и той же документации.

Почему через QR-код уводят аккаунты

Схема обмана бытовая, без всякой техники: человека просят «отсканировать код» — под видом входа в сервис, подтверждения розыгрыша, помощи знакомому. Дальше всё честно работает по документации. Ваш телефон вызывает auth.acceptLoginToken, и на устройстве того, кто показал код, открывается полноценная сессия вашего аккаунта.

Останавливает это ровно одна вещь — облачный пароль. У сессии есть флаг password_pending со скупым описанием: «сессия всё ещё ждёт пароль двухфакторной проверки». Код отсканирован, сессия в списке устройств уже висит, а переписки в ней нет. Любопытно, что на самой странице QR-логина двухфакторная проверка не упоминается вообще — сигнал спрятан в конструкторе authorization, и найти его можно, только если знаешь, что искать.

Второй рубеж — уведомление о новом входе. Все остальные сессии получают апдейт updateNewAuthorization, и если у новой сессии стоит флаг unconfirmed, клиент показывает вопрос «это вы?». Ответ «нет» вызывает account.resetAuthorization и выбрасывает гостя. Молчание тоже ответ: через authorization_autoconfirm_period сессия подтвердится сама — точное значение и что оно означает для покупателя аккаунта, разбирали в статье про то, что отвечает сервер при входе.

А что вообще видно про чужую сессию — модель устройства, платформу, api_id, страну и регион по IP — расписано в разборе активных сессий и списка устройств. Там же остальные флаги: official_app, current, encrypted_requests_disabled.

«Сделать QR-код на телеграм-канал» — это про другое

В поиске эти два запроса стоят рядом и означают противоположные вещи. QR канала — это картинка обычной ссылки t.me, её можно раздавать хоть на визитках. QR входа — одноразовый ключ от аккаунта.

В документации по ссылкам разница видна на глаз. Почти у каждого типа ссылок описаны два синтаксиса, tg:// и t.me. У раздела «QR code login links» вариант с t.me отсутствует: только tg://login?token=. Значит, веб-ссылка на вход по токену протоколом не предусмотрена — и всё, что приходит в чат под видом «ссылки для входа» на домене вида t.me, к этому механизму отношения не имеет.

Ещё одна забавная неровность там же: в таблице параметров этой ссылки единственный параметр назван server, хотя в самом синтаксисе он записан как token. Опечатка живёт в документации до сих пор — снято 31 августа 2026 года.

Чего в документации нет

1. Точного срока жизни токена. «Обычно 30 секунд» — так написано на обзорной странице; жёсткой константы за этой фразой нет. Ключа в конфиге под неё нет: среди 228 описанных ключей config.json QR касаются ровно два, и оба про интерфейс.
2. Лимитов на количество попыток. Сколько раз подряд можно перевыпустить токен и когда прилетит ограничение — не опубликовано.
3. Поведения при сканировании из сессии, которая сама ещё ждёт пароль. Может ли сессия с флагом password_pending подтвердить чужой вход, документация не описывает. Своего эксперимента мы не ставили, догадку подставлять не буду.
4. Списка клиентов, где QR-вход включён. Значения qr_login_code и qr_login_camera приходят с сервера, но по какому правилу они раздаются — нигде не сказано.
5. Раздела в пользовательском FAQ. На telegram.org/faq слово QR не встречается ни разу — проверено 31 августа 2026 года. Обычному пользователю Telegram про эту механику не рассказывает.

Что делать прямо сейчас

1. Не сканируйте коды по чужой просьбе. Сканирование — это не «подтвердить», а «выдать сессию». Обратной кнопки в момент сканирования нет, только отзыв постфактум.
2. Поставьте облачный пароль. Он оставляет чужую сессию в password_pending и не пускает её к переписке. Рядом полезен вход по passkey — другой способ обойтись без кода на номер.
3. Получили аккаунт — сразу откройте список устройств. Чужая сессия в нём заметна по стране и модели устройства. Как мы проверяем аккаунты до выдачи, описано в отдельной статье.
4. Нужна вторая сессия под софт — не гоняйте QR через мессенджеры. Ровно ту же пару методов использует дубликатор сессий: одна авторизованная сессия порождает вторую, на другой паре устройства, без камеры и без пересылки картинок. Форматы и их различия — в разборе tdata против session + json.
5. Пишете свой клиент — держите свои ключи. Чужой api_id отвалится с API_ID_PUBLISHED_FLOOD на первом же вызове экспорта токена, до всякого QR.

Практический вывод для тех, кто работает с Telegram на потоке: сессия — это и есть актив. Парсер аудитории работает от лица живого пользователя, не от бота, поэтому сохранность входа тут — прямое условие работы. Аккаунты по странам и типам лежат в каталоге и проверяются в момент выдачи, разводить их по адресам — резидентными и мобильными прокси: страна и регион сессии считаются по IP и видны в списке устройств. Дальше — сбор участников чата, активных писавших и комментаторов канала, а искать сами площадки помогает глобальный поиск чатов.

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

Порядок вызовов, срок жизни токена, ссылка tg://login?token=, поведение при несовпадении дата-центров и список ошибок — со страницы core.telegram.org/api/qr-login. Описание параметра except_ids и ошибки первого шага — со страницы метода auth.exportLoginToken. Списки методов, доступных без авторизации, и ключи qr_login_code и qr_login_camera — из машиночитаемого config.json (слой 225, 228 описанных ключей). Привязка ошибок к методам, перечни user_only и unauthed_allowed — из справочника ошибок (слой 227). Флаг password_pending, подтверждение нового входа и authorization_autoconfirm_period — со страницы /api/auth. Синтаксис ссылки и отсутствие варианта на t.me — из справочника ссылок. Слой 108 «Login with QR code» — из списка изменений схемы. Всё снято и сверено 31 августа 2026 года.