Dormant-then-burst: главный бан-паттерн на X в 2026
RU
Тишина — и вдруг лавина действий. Именно эта схема — несколько дней «мёртвого» аккаунта, затем резкий всплеск реплаев, follow или постов — чаще всего стоит за потерей автоматизированных аккаунтов на X в 2026. Примерно семь из десяти suspend и жёстких обрезаний видимости после того, как оператор снова подключает paused slot, выглядят так. Лекарство не «никогда не ставить на паузу». Лекарство — протокол аккуратного возврата: никогда не разгоняться быстрее примерно 3× среднего за последние 7 дней.
Как выглядит dormant-then-burst
Здоровый аккаунт X даёт неровный, но непрерывный сигнал: лайки, несколько реплаев, иногда пост, follow — размазанные по рабочим часам много дней подряд. Dormant-then-burst — обратная форма:
- Фаза «dormant»: ноль или почти ноль write-действий 3–14+ дней (модуль на паузе, proxy лёг, token истёк, оператор в отпуске, «потом починим»).
- Фаза «burst»: через часы после reconnect аккаунт прыгает на «нормальный» или даже «догоняющий» объём — 80 реплаев, массовый UnFollow, Welcome DM, Top Repost — будто тишины не было.
Вам это кажется восстановлением. Моделям ranking и anti-abuse — угоном или свежезапущенным скриптом: длинный тихий базовый уровень, потом механическая плотность, которой не бывает у живого человека после отпуска.
Это не классический провал прогрева (новый аккаунт слишком горячий слишком рано) и не просто спам-шаблоны. Можно иметь хороший текст, residential proxy и разумные daily caps — и всё равно поймать удар, если форма активности во времени = тишина → поток.
Почему система за это наказывает
X оценивает не только абсолютный объём. Он смотрит на изменение относительно недавней истории. Скользящие средние по replies, follows, unfollows и DM задают личный базовый уровень. Резкие скачки вверх относительно этого уровня повышают риск — даже если абсолютные цифры были бы нормальны для более активного аккаунта.
После нескольких дней «сна» среднее за 7 дней падает почти к нулю. Рестарт на caps прошлого месяца математически — многократный скачок. То же семейство сигнала, что «резкий разгон активности» в материалах про shadow ban recovery — только триггер не амбиция роста, а отсутствие активности.
Правило оператора: не возвращайтесь выше ~3× среднего за последние 7 дней по любому крупному write-действию (replies, posts, follows, unfollows, DMs). После полной паузы среднее низкое — значит day-one caps тоже. Гарантии «бана не будет» нет; так вы лишь снижаете очевидные anomaly scores.
Плотность всплеска в коротком календарном окне усугубляет: 40 реплаев за два часа после двух тихих недель хуже, чем те же 40, размазанные по полному work-time с рандомизированными задержками.
Где операторы сами создают паттерн
В multi-account ops паттерн почти всегда из процесса, а не из злого умысла:
- Падение proxy: residential endpoint умер; модули «включены», но падают; оператор меняет proxy и оставляет все caps как до аварии.
- Мышление «догоним»: после длинной паузы caps вверх «чтобы наверстать дни» — худший возможный ответ.
- Re-auth токена: сессия восстановлена после challenge; все модули сразу (Reply Search + List + Welcome DM + UnFollow).
- Выходные «заморозка», понедельник «потоп»: намеренные off-days, а понедельник настроен как полный день вместо мягкого рестарта.
- Общие playbook: caps зрелого аккаунта на slot, который неделю молчал, «потому что Standard позволяет 100». Потолки плана — не цели и не учитывают dormancy.
Если slots больше горсти — логируйте длину паузы по каждому аккаунту. 48 часов и 14 дней требуют разных day-one caps при одинаковом плане.
Протокол возврата после паузы
Используйте, когда slot фактически молчит 48+ часов (failed jobs, намеренная пауза или почти ноль успешных действий). Если аккаунт уже под фильтром видимости — комбинируйте с более длинным cool-down (см. восстановление после shadow ban).
| Фаза | Длительность | Объём | Модули |
|---|---|---|---|
| Day 0 (по желанию) | 12–24 ч | Только вручную: скролл, 5–10 лайков, 1–2 живых реплая | Вся автоматизация off |
| Day 1 | Первый live-день | ~20% прежнего steady-state cap (или 3× среднего за 7 дней, если ниже) | Один модуль (обычно Reply Search) |
| Days 2–3 | 48 ч | ~40–50% прежнего steady-state | По-прежнему один основной модуль |
| Days 4–5 | 48 ч | ~70% прежнего steady-state | Второй модуль — только если метрики чистые |
| Day 6–7+ | Далее | К прежним caps, если success rate и engagement держатся | Стек модулей постепенно, не в один час |
Детали Day 1
- Cap реплаев ~20% последнего здорового дневного уровня. Шли 50/день — стартуйте около 10, не 50.
- Work-time узкие (6–8 часов локального дня аккаунта). Без 24/7 «догоним».
- Широкие рандомизированные delays (напр. 8–18 минут). Без фиксированных коротких интервалов.
- Welcome DM, агрессивный UnFollow и высокочастотный Top Repost — off, пока reply-метрики не нормальны несколько дней.
- Не включайте «все модули, чтобы протестить proxy». Тест — сначала действие с наименьшим риском.
Если паузу вызвали rate limits или challenges
Это мягкое событие доверия, не отпуск. Предпочтительно Day 0 только вручную, затем Day 1 = min(20% прежнего cap, 3× среднего за 7 дней). Смотрите audit log на повторные challenges — это сигнал стоп, не «жми harder». Пара к протоколу: безопасность reply-автоматизации и чеклист прогрева.
Правило 3× от среднего за 7 дней
По каждому важному типу действия примерно:
safe_day_cap ≈ min(plan_ceiling, prior_steady_cap, 3 × avg_daily_successful_actions_last_7_days)
Примеры:
- Среднее 5 успешных replies/день за неделю (в основном сбои или пауза) → day-one automated replies около 15 max, не 100.
- Среднее 40 replies/день с однодневным провалом → 3× = 120, но план и прежний steady-state всё равно режут; берите минимум из трёх ограничений.
- Unfollows: 0 десять дней — не открывайте UnFollow на 80/день. Маленький reverse-order batch в безопасном дневном диапазоне (см. безопасные лимиты unfollow).
Правило 3× — потолок ускорения, не цель роста. После возврата к непрерывности предпочитайте +15–30% в неделю — та же медленная кривая, что в multi-account safety practice.
Профилактика, пока аккаунты живы
- Лучше низкая непрерывная нагрузка, чем героическое «догоняние». Два пропущенных дня дешевле всплеска, который зовёт фильтры видимости.
- Алерт на дни без успешных действий. Slot 24–48 ч без successful writes — разбирать proxy/token, пока тишина не растянулась на неделю.
- Разносите обслуживание. Не re-auth и full-throttle двадцать slots в один понедельник утром с одними и теми же session habits.
- Документируйте прежние steady-state caps на slot. Процентам возврата нужен известный «100%» базовый уровень.
- Отделяйте риск идентичности от риска объёма. Shared IP и «грязные» browser profiles дают потери, похожие на ban, но это сбои изоляции — зона multi-account isolation, не только кривых объёма.
Шире по multi-slot process: гайд Safety multi-account ops и проверка shadowban, когда reach схлопнулся после плохого рестарта.
Как настройки HelperX снижают риск
HelperX не обещает и не может обещать «ban-proof» конфигурацию. Он даёт controls, без которых легко нарисовать самые тупые dormant-burst формы:
- Server-side caps — client glitch не уходит за потолки плана (Free Reply Search 30/день; Standard $20/slot; Pro $50; Unlim $90 с более высокими ceilings по модулям).
- Work-time windows — «догоняние» не бежит всю ночь в мёртвые локальные часы.
- Рандомизированные delays — рестарт не превращается в метрономный всплеск.
- Residential proxy на каждый slot — «снова online» ≠ «прыгнули на datacenter ASN».
- Изоляция модулей на slot — Day 1 только Reply Search, не весь стек сразу.
После нескольких тёмных дней: вручную опустите daily caps slot’а, один модуль, шире delays, потом поднимайтесь по таблице возврата. Молодые аккаунты — дисциплина прогрева; зрелые — safety defaults из гайда по reply-автоматизации.
Итог: главный бан-паттерн в operator traffic 2026 — не «использовали автоматизацию». Это «выглядел мёртвым, потом как скрипт». Будьте непрерывны, когда можете; когда нет — Day 1 ~20% и никогда jump > ~3× среднего за 7 дней.