Безопасность # Dormant-then-burst: главный бан-паттерн на X в 2026 Автор · 10 июля 2026 · 10 мин чтения Тишина — и вдруг лавина действий. Именно эта схема — несколько дней «мёртвого» аккаунта, затем резкий всплеск реплаев, follow или постов — чаще всего стоит за потерей автоматизированных аккаунтов на X в 2026. Примерно семь из десяти suspend и жёстких обрезаний видимости после того, как оператор снова подключает paused slot, выглядят так. Лекарство не «никогда не ставить на паузу». Лекарство — протокол аккуратного возврата: никогда не разгоняться быстрее примерно 3× среднего за последние 7 дней.  *Плоская линия → резкий пик — сигнатура, которую anti-abuse скорит жёстче всего* ## Как выглядит 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](https://helperx.app/ru/blog/x-shadow-ban-triggers-recovery)). | Фаза | Длительность | Объём | Модули | | 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-автоматизации](https://helperx.app/ru/blog/reply-automation-safety) и [чеклист прогрева](https://helperx.app/ru/blog/x-account-warm-up-checklist). ## Правило 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](https://helperx.app/ru/blog/safe-unfollow-x-limits)). Правило 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](https://helperx.app/ru/blog/multi-account-x-isolation), не только кривых объёма. Шире по multi-slot process: [гайд Safety multi-account ops](https://helperx.app/ru/guides/x-safety-multi-account-ops) и [проверка shadowban](https://helperx.app/ru/tools/shadowban-check), когда 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 дней. Обновлено: 2026-07-10.