PEER_FLOOD при инвайте и рассылке: отличие от FloodWait и что менять

`PEER_FLOOD` — одна из самых дорогих ошибок на сетке, потому что её привыкли трактовать как «ну, флуд, подождём». Подождали минуту, повторили инвайт, получили ту же строку, крутанули прокси, повторили ещё. Через вечер номер либо окончательно бесполезен для холодных касаний, либо уезжает в спамблок или заморозку. Разница с `FLOOD_WAIT_X` здесь не косметическая: у одного отказа есть секунды ожидания, у второго — суждение платформы о том, что аккаунт слишком активно лезет к новым пирам.

Telegram не публикует таблицу «после скольких инвайтов будет PEER_FLOOD». Для оператора это снова измеряемый класс отказа, а не цифра из чата. Как устроены классы лимитов в целом — в материале про лимиты инвайта в 2026. Ниже — только PEER_FLOOD и что менять в трёх рычагах: пейсинг, аккаунты, база.

Что обычно имеют в виду под PEER_FLOOD

В клиентских библиотеках и логах софта `PeerFlood` / `PEER_FLOOD` связывают с ограничением на действия относительно *новых* пользователей: написать незнакомцу, добавить незнакомца в группу, иногда — массово тащить в контакты. Смысл публичный и практический: антиспам решил, что паттерн похож на спам по пирам, а не что «вы превысили 17 запросов в секунду к методу Y».

Следствие для коммерческого сценария: старые диалоги и взаимные контакты могут ещё жить, а холодный инвайт/ЛС — нет. Номер «онлайн», в чатах читает, в задаче даёт нули. Это не успех healthcheck.

PEER_FLOOD не обязан прийти с таймером. Если софт рисует его в одной колонке с FloodWait и ставит sleep 30 — это ошибка продукта или вашего SOP. Sleep не адресует причину.

Связь со Spam FAQ прямая по духу, даже если имя ошибки в FAQ не процитировано: жалобы и сообщения незнакомым ограничивают возможность продолжать то же самое. `@SpamBot` имеет смысл проверить, но не как кнопку «сбросить счётчик инвайта», а как диагностику, не ушёл ли номер уже в классический лимит.

Чем FloodWait отличается, и почему ретрай копируют зря

FloodWait (`FLOOD_WAIT_X`). Платформа говорит: подожди X секунд и не повторяй метод раньше. Это rate limit конкретного действия. После паузы вызов может пройти. Стратегия: ждать не меньше X, снизить частоту, не параллелить тот же метод на той же сессии. Если FloodWait сыпется часто — вы всё ещё в зоне пейсинга, не в зоне приговора.

PEER_FLOOD. Нет обещания, что через X секунд холодный пир снова доступен. Повтор того же инвайта — подтверждение паттерна. Правильная реакция: стоп холодных касаний с этого аккаунта, разбор, пауза сценария, возможно апелляция через Spam Info Bot, если клиент уже показывает спам-ограничение. Неправильная: уменьшить delay с 20 до 15, «чтобы успеть план».

Смешение в голове оператора выглядит так: «оба про флуд, значит оба лечатся ожиданием». Лечатся по-разному. FloodWait — ожиданием метода. PEER_FLOOD — сменой режима аккаунта (с холодного outreach на покой / тёплые диалоги) и сменой входов задачи.

Рядом может стоять freeze: если вместо PEER_FLOOD уже `FROZEN_METHOD_INVALID`, читайте разбор 420 и не применяйте этот текст. Escalation идёт в одну сторону. Игнорировать PEER_FLOOD — один из путей туда.

Где ошибка всплывает: инвайт, ЛС, контакты

Один и тот же код может закрыть разные ветки воронки.

Прямой инвайт в группу. Самый частый боевой лог. Аккаунт добавляет холодных. После серии успехов/отказов Telegram перестаёт пускать новые добавления с этим номером. Соседний номер на том же чате ещё может работать — тогда это лимит аккаунта, не смерть сообщества. Если падают все — смотрите чат и базу, не только PEER_FLOOD.

Инвайт через админку. Права не иммунитет. Админ с правом add members всё равно касается холодных пиров. PEER_FLOOD на админке означает: слот занят бесполезной для набора учёткой. Снимите её из пула добавления, не держите «вдруг отойдёт к ночной смене». Слоты админов конечны.

Рассылка в ЛС. Холодные диалоги, одинаковый текст, ссылки, отсутствие ответа — классический корм для ограничений на новые пиры. PEER_FLOOD здесь часто приходит раньше, чем на аккуратном инвайте в подготовленный чат. Смешивать на одном номере ночную рассылку и утренний инвайт — способ не понять, какая ветка его убила.

Добавление в контакты как «смягчение». Это всё ещё массовое действие по пирам. Если вы перенесли нагрузку из invite в add-contact с той же скоростью и той же простынёй, вы поменяли метод, не паттерн. Не удивляйтесь тому же классу отказа.

Отказы цели (`USER_PRIVACY_RESTRICTED`, не взаимный контакт, уже в чате) — не PEER_FLOOD. Их надо отделять в логе, иначе вы лечите пейсингом брак парса.

Что менять в пейсинге — и чего не менять

Пейсинг — первый рычаг, потому что его дешево крутить. Но крутить нужно плотность и параллелизм, а не священное число секунд.

Снимите с аккаунта вторую и третью задачу. Два «безопасных» интервала на одной сессии складываются в небезопасный. Инвайт + рассылка + автоджойн в источники — частая невидимая сумма.

Снизьте параллелизм внутри задачи: меньше одновременных касаний с одного номера. Случайный delay 3–7 секунд при пачке в десять потоков не является медленным сценарием. Смотрите фактические действия в минуту по логу, не поле «задержка» в форме.

После FloodWait не возвращайтесь к прежней частоте. После PEER_FLOOD не возвращайтесь к частоте вообще, пока не закончите разбор. Это разные ветки.

Не ищите «официальную» паузу 60–180 секунд как защиту. Любая фиксированная решётка на всей ферме сама по себе паттерн. Важнее: мало холодных касаний, паузы между пачками, дневной потолок *ваш по замеру*, ночной покой, отсутствие ретраев на отказ пира.

Не лечите PEER_FLOOD ускорением «пока не закрыли». Это инвертированная логика.

Что менять в аккаунтах и инфраструктуре

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

Если PEER_FLOOD накрыл пачку с одним ASN/одной подсеткой/одним отпечатком устройства — это инфра. Датацентровые прокси, одинаковый device_model, одновременный старт ста сессий выглядят как ферма даже при «честной» задержке. Чинить инфру нужно до того, как вы вините базу. Но замена IP *после* PEER_FLOOD не снимает флаг с аккаунта. Сначала стоп, потом разбор, потом другой номер в линии, а не тот же номер с новым адресом.

Дубль session (два процесса, телефон + софт без учёта) даёт отдельные ошибки, но и ускоряет смерть: вы не контролируете суммарную плотность. Перед боевым инвайтом одна активная рабочая сессия на стратегию.

Не тащите из карантина номер, который вчера словил PEER_FLOOD, в «другой чат, там лимиты другие». Лимит на пиры сидит на аккаунте. Другой чат спасёт, только если вы путали антиспам сообщества с PEER_FLOOD. Это проверяется просто: соседние здоровые номера тот же чат ещё едят или нет.

Админку с больного номера снимайте. Пустой слот лучше, чем вечный fail в отчёте.

Что менять в базе и оффере

PEER_FLOOD чаще прилетает там, где люди жалуются и не понимают, зачем их трогают. Это не «Telegram не любит инвайт», это статистика репортов и игнора.

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

Свежесть и активность. Мёртвые id, переставшие писать полгода назад, не делают инвайт безопаснее: они либо не добавляются, либо добавляются и сразу выходят.

Приватность. Высокая доля privacy — это не PEER_FLOOD, но она провоцирует оператора «дожать объём», и он дожимает частоту по тем, кого ещё можно трогать. Фильтруйте раньше, не ускоряйте позже.

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

Не гоните одну простыню повторно тем, кого уже не удалось добавить вчера. Повтор по отказавшимся пирам — плотный паттерн.

Стоп-условия в задаче, без которых SOP бесполезен

Запишите явно:

·         первый PEER_FLOOD на аккаунте → стоп холодных действий на нём, алерт, не ретрай;

·         второй PEER_FLOOD за короткое окно на разных целях → вывод из пула инвайта/рассылки;

·         доля PEER_FLOOD по задаче выше вашего внутреннего порога → стоп всей волны, не «докатим оставшуюся базу»;

·         FloodWait копить отдельно, не суммировать с PEER_FLOOD в одном fail%;

·         privacy/mutual считать браком базы;

·         freeze — другой регламент, не этот.

Пороги процентов вы ставите сами по тестам. Не публикуйте их как лимиты Telegram. Главное — чтобы софт умел остановиться. Облачный кабинет удобен, когда ночная задача не молотит простыню до утра. Имеет смысл гонять инвайт и рассылку в контуре Metagram: кредиты на тест классификации отказов, стоп аккаунта руками, логи не на чужом VPS под кроватью. Обойти PEER_FLOOD софт не может — он может не усугубить его.

Как тестировать, не дожидаясь пачки трупов

Узкий прогон: 2–3 номера одного класса, маленькая чистая база, один чат, одна ветка (либо инвайт, либо ЛС). Смотрите, на каком фактическом объёме холодных касаний появляется FloodWait, и отдельно — появляется ли PEER_FLOOD. Это ваш потолок класса, с датой.

Не тестируйте на боевом чате клиента внутри фермы, если чат уже на грани антиспама. Иначе вы смешаете отлёт сообщества и лимит пиров.

После PEER_FLOOD не используйте этот же номер как измеритель «а если ещё чуть-чуть». Измеритель сломан. Берите соседний того же класса.

Ведите журнал: класс номера, ветка (инвайт/ЛС), плотность, объём до отказа, тип отказа. Через месяц это ценнее любой статьи, включая эту.

Связка с чатом, freeze и учётом голов

Операторы иногда видят PEER_FLOOD и решают «надо больше аккаунтов в этот же чат быстрее». Если чат уже собирает выходы, вы ускоряете смерть сообщества и оставшейся сетки. Сначала качество остатка, потом объём. Текст про отлёт чатов здесь не лирическое отступление, а соседний контур риска.

Если после серии PEER_FLOOD пошли freeze — не обсуждайте пейсинг, пока не выключили генератор. Апелляции пачкой шаблонных сообщений не заменяют остановку.

В отчёте «заинвайтили N» без колонки отказов по классам врёт всегда. N без PEER_FLOOD%, выходов и живых аккаунтов к утру — не результат, а расход.

Коротко

PEER_FLOOD — ограничение на холодные пиры, не таймер метода. FloodWait ждут и замедляются. PEER_FLOOD — стопают холодный сценарий на аккаунте и меняют плотность, пул и базу, а не ретраят. Прокси после факта не лечит. Чужие «N в сутки» не лечат. Лечит наблюдаемость классов ошибок и готовность не добить план ценой сетки.

Читать рядом: лимиты 2026, заморозка, FROZEN_METHOD_INVALID, отлёт чатов. Поставить задачу и стоп-условия в облаке: Metagram.