Когда в логе инвайта или рассылки появляется `FROZEN_METHOD_INVALID`, смена часто делает худшее из возможного: ретраит тот же метод, перелогинивает сессию, меняет прокси и гонит аккаунт дальше по базе. Для FloodWait это ещё можно пережить. Для freeze — нет. Код 420 в этом контексте не «подожди и повтори». Это сообщение платформы: текущий аккаунт заморожен и указанное действие ему выполнять нельзя.
Ниже — только то, что следует из публичных описаний Telegram и из практики ведения задачи в софте. Внутреннюю кухню антиспама мы додумывать не будем. Для оператора достаточно правильно классифицировать ошибку, остановить вред и пройти официальный контур апелляции.
Смежные темы: заморозка аккаунта как состояние, PEER_FLOOD, лимиты инвайта в 2026. Если параллельно сыпется сообщество, а не только номер, смотрите почему отлетают чаты.
Что публично означает FROZEN_METHOD_INVALID
В документации API Telegram прямо сказано: замороженные аккаунты находятся в режиме read-only, и вызов многих методов даёт одну из ошибок:
· `FROZEN_METHOD_INVALID` (420) — указанный метод замороженным аккаунтам использовать нельзя совсем;
· `FROZEN_PARTICIPANT_MISSING` (400) — даже если метод для freeze в принципе доступен, к указанному пиру замороженный аккаунт доступа не имеет.
Формулировка простая: не «лимит на инвайт исчерпан до завтра», а «аккаунт в состоянии freeze, это действие запрещено». Код 420 здесь соседствует в справочниках ошибок с flood-семейством, поэтому его легко принять за таймер. Не принимайте. У FloodWait есть секунды ожидания. У FROZEN_METHOD_INVALID секунд до «можно снова инвайтить» нет.
Telegram отдельно пишет, что freeze применяется за серьёзные нарушения ToS и что замороженный аккаунт удалят спустя время, *если апелляция не подана и не принята*. Это ключевой операторский факт: молчание и продолжение автоматики работают против номера.
Какие поля связаны с апелляцией и чего мы не выдумываем
По публичному описанию, получив `FROZEN_METHOD_INVALID`, клиент должен запросить конфигурацию приложения и смотреть поля:
· `freeze_since_date` — когда аккаунт заморозили (unix-время; 0 / не задано — нет);
· `freeze_until_date` — до какого момента аккаунт будет удалён, если апелляция не принята;
· `freeze_appeal_url` — URL, по которому пользователь может подать апелляцию.
В TDLib то же состояние приходит обновлением freeze: флаг «заморожен», дата заморозки, дата удаления, ссылка на апелляцию. Это не секрет фермы, это официальный клиентский контракт.
Что из этого следует для софта:
· если кабинет умеет показать freeze-поля — сохраните их в карточке аккаунта и в логе задачи;
· если не умеет — не эмулируйте «внутренний API». Откройте официальный клиент тем же номером и пройдите то, что показывает Telegram;
· `freeze_appeal_url` — не «секретный обход», а штатный адрес апелляции. Его не надо искать на форумах.
Чего не следует выдумывать: точный список методов, которые ещё «можно» на freeze; скрытые флаги антиспама; гарантированные часы до разморозки; «если вызвать help.getAppConfig N раз, freeze спадёт». Оператор работает с фактом: метод отклонён, аккаунт в read-only, есть официальный URL/бот для апелляции.
Чем freeze отличается от соседних отказов в том же логе
FloodWait. Таймер на метод. После ожидания тот же вызов может пройти. Аккаунт не переведён в read-only. Ретрай после паузы — нормальная стратегия, если вы снизили плотность.
PEER_FLOOD. Ограничение на массовые касания новых пиров. Коммерческий инвайт часто встаёт, но это ещё не описание freeze в API. Путать их опасно: PEER_FLOOD иногда пытаются «вылечить» паузой в работе (без гарантий), freeze — только апелляцией и ожиданием решения. Подробнее — отдельный текст про PEER_FLOOD.
Спамблок / лимит по Spam FAQ. Классическая схема: жалобы, модерация, временное ограничение на сообщения незнакомым, при этом контактные и входящие диалоги могут жить. Интерфейс часто идёт через `@SpamBot`. Это пересекается с freeze по каналу апелляции, но не тождественно. Freeze в документации — отдельное состояние read-only с риском удаления. Не обещайте смене, что «это обычный спамблок на пару дней», если вы видите именно FROZEN_METHOD_INVALID. Различие состояний — в материале про заморозку аккаунта.
Бан номера / USER_DEACTIVATED / PHONE_NUMBER_BANNED. Другой конец спектра. Freeze ещё предполагает окно апелляции до удаления. Если номер уже в терминальном бане, карточка задачи должна быть закрыта иначе. Не смешивайте статусы в одном столбце «умер».
Spam Info Bot и freeze_appeal: что делать руками, не ботом инвайта
Публичная практика, которую подтверждают и клиентская документация, и Spam FAQ: апелляция идёт от *самого* затронутого аккаунта, через интерфейс Telegram — экран заморозки, `freeze_appeal_url` или Spam Info Bot (`@SpamBot`).
Операторский порядок:
1. Остановить все задачи на этом session. Не инвайт, не рассылка, не парсинг «на том же номере», не массовые join.
2. Не плодить новые сессии. На freeze официально описаны ограничения вроде невозможности нормально добавить устройство / перелогиниться как на живом аккаунте. Насильный перелогин через софт — лишний сигнал, не лечение.
3. Открыть официальный клиент (часто достаточно того, где сессия уже есть). Прочитать текст заморозки. Если есть кнопка апелляции — идти по ней.
4. Если дан `freeze_appeal_url` — открыть его. Если клиент уводит в капчу, используйте внешний браузер устройства, а не встроенный webview, который у части пользователей зацикливает проверку. Это не хак, это доведение штатной проверки до конца.
5. Если модалки нет, начать диалог с Spam Info Bot: `/start` и дальше по вопросам. Писать по делу, без шаблона «я не спамер копипаста». Один проход лучше десяти одинаковых.
6. Дождаться подтверждения, что апелляция принята в работу. Если бот молчит или сбрасывает — процедура не завершена, её повторяют аккуратно, а не с десяти аккаунтов сразу одной простынёй.
Не делегируйте апелляцию «сервису восстановления» с просьбой отдать код. Для оператора номер после этого часто теряется дважды: и freeze, и сессия.
Сроки ответа Telegram не публикует как SLA. Не ставьте в отчёт заказчику внутри фермы «разморозят через N часов». Ставьте статус: апелляция подана / не подана / отказано / аккаунт снова выполняет методы.
Что должна сделать задача в софте в ту же минуту
Правило смены: `FROZEN_METHOD_INVALID` = критический стоп аккаунта, не fail-ретрай.
Минимальное поведение хорошего контура:
· пометить аккаунт статусом freeze и снять с пула инвайта, рассылки, вступлений;
· не перекладывать его очередь на тот же session «через 5 минут»;
· сохранить сырую строку ошибки, время, метод, чат/цель, если цель была;
· если софт видит freeze-поля — сохранить даты и appeal URL;
· алерт оператору, а не тихий skip в общем fail-rate;
· соседние аккаунты той же задачи *не* обязаны останавливаться автоматически, но если freeze пошёл пачкой на одной проксе/одной базе/одном чате — остановите волну и разберите причину, иначе вы докупите ту же судьбу.
Плохое поведение, которое надо явно запретить в SOP:
· ретрай метода;
· «прогрев» замороженного номера сообщениями;
· перевод на другой чат «проверим, может тут пройдёт»;
· смена IP как лечение freeze;
· параллельный запуск второй сессии «вдруг эта залипшая».
Облачный кабинет здесь полезен тем, что стоп можно дать с телефона, не ища, какой VPS крутит скрипт. Имеет смысл держать инвайт в контуре вроде Metagram, где задача и статусы аккаунтов видны без десктопного комбайна. Софт не разморозит Telegram — он должен перестать бить в закрытую дверь.
Как читать лог, чтобы не спутать 420 с «просто 420 flood»
В справочниках ошибок 420 — семейство flood. Рядом живут `FLOOD_WAIT_X`, премиум-ожидания, slowmode. Человек, который фильтрует только цифру 420, смешает таймер и freeze.
Фильтруйте по *имени* ошибки: `FROZEN_METHOD_INVALID`, не по HTTP-подобному коду. В отчёте смены пишите имя. Если софт показывает только «error 420» — это дефект наблюдаемости, его надо чинить в первую очередь, иначе регламент невыполним.
Если рядом всплыл `FROZEN_PARTICIPANT_MISSING`, не трактуйте как «цель плохая, скипаем и идём дальше тем же номером». Это подтверждение freeze-режима на пирах. Номер всё равно выводится.
Что проверить по сетке, когда freeze не единичный
Один freeze на старом грязном номере — рабочий расход. Пачка за вечер — системный сбой сценария.
Смотрите:
· не ушла ли плотность выше того, что вы сами замерили на классе номеров (см. лимиты 2026);
· не смешали ли инвайт и холодную рассылку на одной сессии;
· не полетела ли база с высокой жалобностью (нерелевант, другой язык, явный спам-оффер в первом касании);
· не отлетает ли чат: тогда freeze админов — следствие, а не причина, и чинить надо сообщество;
· нет ли дублей session, датацентровых ASN на «живых» номерах, ночных скачков гео;
· не гоняется ли один и тот же текст/шаблон, который легко репортят.
Цель разбора — остановить генератор freeze, а не написать в чат команды «Telegram сходит с ума». Платформа отвечает на паттерн. Паттерн — ваша задача, база, чат, инфраструктура.
Можно ли возвращать номер в инвайт после апелляции
Только после того, как *методы снова выполняются*, а не после того, как «вроде бот что-то ответил». Проверка узкая: официальный клиент позволяет обычные действия; контрольный вызов безопасного метода в софте проходит; freeze-поля нулевые.
Даже тогда номер не возвращают в тот же агрессивный сценарий. Карантин, отдельный пул, малый объём, чистая база. Freeze — это уже серьёзный флаг в истории. Повторный заход в ту же мясорубку часто заканчивается терминально.
Если апелляцию отклонили или аккаунт исчез — не дергайте соседние сессии того же номера. Карточку закрывают, слот админки в рабочих чатах снимают, чтобы не держать мёртвые права.
Что писать в статусе задачи, чтобы отчёт не врал
Вместо «аккаунт отлетел» фиксируйте:
· ошибка: FROZEN_METHOD_INVALID;
· задача остановлена на аккаунте: да/нет (должно быть да);
· апелляция: не начата / URL открыт / Spam Info Bot / отправлена / отказ / аккаунт удалён;
· freeze_until_date: известно / неизвестно (без пересчёта в «осталось часов», если сами поле не видели);
· гипотеза причины: база / плотность / чат / инфра / неизвестно;
· влияние на соседние номера: изолировано / пачка.
Это позволяет на утреннем разборе не спорить о мифологии, а смотреть факты. Тот же словарь должен жить в классификации лимитов.
Коротко для смены
`FROZEN_METHOD_INVALID` — метод закрыт, потому что аккаунт заморожен. Это не FloodWait. Ретраи запрещены. Апелляция — только официальный контур: экран freeze, `freeze_appeal_url`, Spam Info Bot. Сроки не обещаем. Задача снимает номер из пула и эскалирует оператору. Лечение инвайтом, прокси и второй сессией не существует.
Проверить, как ваш софт показывает этот код, удобнее на тестовой задаче в облаке, чем на боевой ферме без логов. Контур запуска — Metagram.
Как не размазать freeze по всей смене
Самая частая организационная ошибка — один человек видит 420 в логе, другой в это время перезапускает ту же задачу «потому что прогресс встал». Пока апелляция пишется, второй процесс уже наделал новых вызовов. SOP должен содержать имя ответственного за стоп и запрет на «просто перезапусти воркер».
Второй контур — шаблоны апелляций в общем чате команды. Их узнают. Пишите своими словами, коротко: что аккаунт используется для работы с сообществами, какие действия были, почему считаете ограничение ошибочным, если так считаете. Не прикладывайте логи инвайта посторонним людям. Не обещайте модератору, что «это не спам, это маркетинг».
Третий контур — учёт слотов. Freeze-админ в десяти чатах не помогает ни одному из них. Владелец снимает права, фиксирует это в таблице, чтобы утром не гадать, почему инвайт через админку не с кем делать.
Если после стопа соседние номера живы, не останавливайте весь мир. Если за час freeze поймали несколько сессий одного класса — останавливайте класс, не «ещё пачку взамен». Покупка новых номеров в ту же схему только масштабирует расход.
Перенесите сценарий в Metagram
Парсинг аудитории, инвайтинг, рассылки, планировщик и управление Telegram-аккаунтами — в одном облачном кабинете.
Начать бесплатно