П/ВИН
автоматизацияPythonAPITelegramDevOps

Social Media Automation: архитектура и защита аккаунтов

·9 мин чтения
Social Media Automation: архитектура и защита аккаунтов

Несколько месяцев назад я начал проект, который в голове казался простым: «автоматизируй постинг в соцсети, отправляй сообщения, управляй аккаунтами». В реальности это оказалось одной из самых насыщенных исследовательских и инженерных задач за последнее время. В этой статье расскажу, как мы шли от исследования рынка до конкретной реализации антибан-защиты — с кодом, архитектурными решениями и честными выводами.

Контекст: зачем вообще автоматизировать соцсети

Задача звучала так: нужна система, которая управляет массой аккаунтов в Telegram (и потенциально Instagram/TikTok), автоматически публикует контент, отправляет сообщения по определённым триггерам и не банится. Особое требование — масштабируемость. Не 5 аккаунтов, а десятки и сотни.

Первым делом мы провели полное исследование рынка: что существует, что работает в 2026 году, какие библиотеки живые, какие протоколы детектируются платформами.

Исследование стека: 10 параллельных агентов

Для исследования я запустил 10 параллельных агентов, каждый из которых отвечал за своё направление:

| Агент | Направление | |-------|------------| | 1 | instagrapi — статус, форки, альтернативы | | 2 | TikTok автоматизация и DM-боты | | 3 | Массовая публикация Reels/Shorts на 20-30 аккаунтов | | 4 | Антидетект-браузеры: AdsPower, GoLogin, Dolphin Anty | | 5 | MQTT и Instagram realtime без официального API | | 6 | Comment-to-DM open-source решения | | 7 | Account farm management | | 8 | Прокси и резидентные IP | | 9 | Fingerprint spoofing | | 10 | Telegram массовые рассылки |

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

Что нашли по Instagram

Для Instagram Private API в 2026 году живы два основных инструмента:

  • instagrapi (6k+ stars) — Python-библиотека, активно обновляется. Поддерживает комментарии, DM, загрузку Reels, управление подписчиками. Авторы активно толкают собственный SaaS HikerAPI, но open-source ядро работает.
  • aiograpi — асинхронная обёртка над instagrapi для высоконагруженных сценариев.

Для антидетект-браузеров ситуация такая: GoLogin и AdsPower остаются лидерами, Dolphin Anty активно развивается и дешевле. Все три поддерживают API для автоматизации.

Что нашли по Telegram

Для Telegram основной стек — Telethon и Pyrogram. Оба работают с MTProto напрямую, что даёт полный контроль над аккаунтом. Для оркестрации множества аккаунтов лучше Pyrogram — у него удобнее API для параллельной работы.

Архитектура системы

После исследования стало ясно: нужна многоуровневая система. Вот что вошло в финальную архитектуру:

┌─────────────────────────────────────┐
│         Orchestrator Service        │
│  (Python + PostgreSQL + asyncio)    │
└──────────────┬──────────────────────┘
               │
       ┌───────┴────────┐
       ▼                ▼
┌─────────────┐  ┌─────────────┐
│ Account Pool │  │  Sender     │
│ Management  │  │  Module     │
└─────────────┘  └─────────────┘
       │                │
       ▼                ▼
┌─────────────┐  ┌─────────────┐
│  Lolz Market │  │  Channels   │
│  Integration │  │  DB         │
└─────────────┘  └─────────────┘

Ключевые компоненты:

  • Account Pool — управление пулом аккаунтов, выбор подходящего для задачи
  • Sender — отправка сообщений с имитацией человеческого поведения
  • PostgreSQL — хранение состояния аккаунтов, каналов, задач
  • Orchestrator — координация всего пайплайна

Проблема: аккаунты банятся

Самая болезненная часть проекта — это борьба с банами. После изучения материалов (в том числе блога GramGPT о заморозке Telegram-аккаунтов) стала ясна цепочка ошибок, которые мы изначально допускали.

Типичные ошибки, приводящие к бану

Ошибка 1: Неправильный порядок setup аккаунта

Мы делали так:

verify → profile/avatar/bio → 2FA → username → warmup → activate

Правильно делать так:

verify → отлёжка 24-48ч → warmup 2-4 дня → profile/avatar/bio → activate

Проблема в том, что изменение профиля сразу после покупки — это первый триггер заморозки. Аккаунт только зарегистрирован на новом IP, и тут же меняется аватар, имя, bio. Это идеальная сигнатура бота.

Ошибка 2: Несоответствие гео аккаунта и IP

Аккаунт куплен с российским номером телефона, а подключается через европейский прокси без прогрева. Telegram это видит и повышает уровень подозрения.

Ошибка 3: Мгновенная отправка сообщений

Бот отправляет сообщения без задержки — нет паузы между нажатием и отправкой, нет имитации набора текста.

Решение: план антибан-улучшений

Мы разработали план из 4 задач и реализовали их через TDD:

Task 1: Geo-Match Validation

Первым делом добавили валидацию соответствия гео аккаунта и прокси:

# account_pool.py
def validate_geo_match(account: Account, proxy: Proxy) -> GeoMatchResult:
    """
    Проверяет соответствие страны аккаунта и страны прокси.
    Возвращает результат с уровнем риска.
    """
    account_country = account.phone_country_code
    proxy_country = proxy.country_code
    
    if account_country == proxy_country:
        return GeoMatchResult(match=True, risk_level='low')
    
    # Допустимые соседние страны (меньший риск)
    ALLOWED_NEIGHBORS = {
        'RU': ['BY', 'KZ', 'UA'],
        'UA': ['RU', 'PL', 'RO'],
        # ...
    }
    
    if proxy_country in ALLOWED_NEIGHBORS.get(account_country, []):
        return GeoMatchResult(match=False, risk_level='medium', 
                              warning='Neighboring country proxy')
    
    return GeoMatchResult(match=False, risk_level='high',
                          warning='Geo mismatch detected')

Если риск высокий — предупреждение логируется и аккаунт не берётся в работу.

Task 2: IP Settle Delay (12 часов)

После смены IP аккаунт должен «отлежаться» минимум 12 часов перед активными действиями:

# account_setup.py
def should_start_setup(account: Account) -> tuple[bool, str]:
    """
    Проверяет, прошло ли достаточно времени после последней смены IP.
    Минимум 12 часов.
    """
    IP_SETTLE_HOURS = 12
    
    if account.last_ip_change is None:
        return True, 'No IP change recorded'
    
    elapsed = datetime.utcnow() - account.last_ip_change
    hours_elapsed = elapsed.total_seconds() / 3600
    
    if hours_elapsed < IP_SETTLE_HOURS:
        remaining = IP_SETTLE_HOURS - hours_elapsed
        return False, f'Wait {remaining:.1f}h more (IP settle)'
    
    return True, 'IP settled'

Task 3: Typing Simulation

Имитация набора текста перед отправкой — один из самых эффективных антибан-приёмов:

# sender.py
import asyncio
import random
 
def calc_typing_delay(text: str) -> float:
    """
    Рассчитывает задержку имитации набора.
    Базовая скорость: 40-80 слов/мин с случайными вариациями.
    """
    words = len(text.split())
    chars = len(text)
    
    # Средняя скорость печати человека: 200 символов/мин
    base_speed = random.uniform(150, 280)  # символов в минуту
    base_delay = (chars / base_speed) * 60
    
    # Добавляем случайные паузы ("думает")
    think_pauses = random.randint(0, max(1, words // 5))
    pause_time = think_pauses * random.uniform(0.5, 2.0)
    
    return min(base_delay + pause_time, 8.0)  # максимум 8 секунд
 
async def _simulate_typing(self, client, chat_id: int, text: str):
    """Отправляет typing action и ждёт рассчитанное время."""
    delay = calc_typing_delay(text)
    async with client.action(chat_id, 'typing'):
        await asyncio.sleep(delay)

Этот метод интегрировали во все методы отправки: send_text, send_photo, send_voice, send_album.

Task 4: Channel-Per-Account Limit

Ограничение на количество каналов на один аккаунт (максимум 20). Выше — повышенный риск:

# pg_database.py
async def count_account_channels(account_id: int) -> int:
    """Считает активные каналы для аккаунта."""
    async with get_connection() as conn:
        result = await conn.fetchval(
            'SELECT COUNT(*) FROM channels WHERE account_id = $1 AND active = true',
            account_id
        )
        return result or 0
 
# sender.py — в _select_account()
async def _select_account(self, step: SendStep) -> Account | None:
    MAX_CHANNELS_PER_ACCOUNT = 20
    
    candidates = await self.pool.get_available_accounts()
    
    for account in candidates:
        channel_count = await count_account_channels(account.id)
        if channel_count >= MAX_CHANNELS_PER_ACCOUNT:
            logger.warning(
                f'Account {account.id} at channel limit: {channel_count}'
            )
            continue
        return account
    
    return None

Результаты: что получили после реализации

После внедрения всех четырёх задач:

  • 12 новых тестов — все зелёные (TDD подход сработал)
  • Сервис tg-army-orchestrator запустился без ошибок
  • Все настройки (IP_SETTLE_HOURS, MAX_CHANNELS) вынесены в БД и изменяются без деплоя
  • Geo-match предупреждения начали работать на этапе выбора аккаунта

Общая картина изменений по файлам:

| Файл | Что изменилось | |------|----------------| | account_pool.py | Geo-match валидация | | account_setup.py | IP settle delay, проверка порядка setup | | lolz_market.py | Предупреждения при покупке с гео-мисматчем | | sender.py | Typing simulation, channel limit | | pg_database.py | Счётчик каналов на аккаунт |

Параллельный трек: VPN для обхода блокировок

В ходе работы над проектом возник смежный вопрос — сам инфраструктурный доступ. Beget VPN (который использовался для тестирования) перестал работать с апреля 2026 из-за блокировок РКН. WireGuard и OpenVPN теперь 100% детектируются ТСПУ (Deep Packet Inspection оборудование на каждом провайдере).

Для инфраструктуры проекта это важно: если сервис работает с российскими аккаунтами, сам трафик управления тоже не должен выглядеть подозрительно.

Что работает в 2026 году:

  • VLESS + Reality + XTLS-Vision — маскируется под легитимный HTTPS трафик
  • Shadowsocks с плагином obfs4 — обфускация трафика
  • Обёртки через CDN (Cloudflare Workers) — трафик неотличим от легального CDN

При масштабировании до 1000 пользователей архитектура меняется кардинально: вместо одного VPS с 3X-UI нужен Marzban с MySQL, multi-node поддержкой и Telegram-ботом для управления пользователями.

Выводы и уроки

Урок первый: исследование — не трата времени, а экономия денег. Мы потратили несколько дней на исследование стека перед тем, как написать первую строку продуктового кода. Это позволило избежать ловушки «написал, потом переписал» — например, сразу стало ясно, что 3X-UI не потянет 1000 пользователей и нужен Marzban. Без исследования мы бы узнали об этом уже после деплоя.

Урок второй: TDD в задачах антибан-защиты работает особенно хорошо. Тесты для geo-match, IP settle, typing simulation — это не просто проверка кода. Это спецификация поведения, которая позволяет быстро проверить «а что будет, если...». Когда правила бана меняются (а они меняются постоянно), тесты помогают быстро понять, какие части системы нужно обновить.

Урок третий: антибан — это не одна фича, это система. Каждая отдельная защита (geo-match, задержка IP, имитация набора, лимит каналов) работает слабо в одиночку. Система начинает работать как единое целое, когда все компоненты связаны и каждый дополняет другой. Порядок setup аккаунта, правильное гео, задержки, лимиты — всё это звенья одной цепи.

Урок четвёртый: настройки должны быть в БД, а не в коде. IP_SETTLE_HOURS, MAX_CHANNELS_PER_ACCOUNT — эти параметры нужно менять быстро, в ответ на изменения поведения платформы. Если они захардкожены, каждое изменение требует деплоя. Вынос в таблицу settings позволяет менять поведение системы без перезапуска.

Урок пятый: параллельные агенты — хороший инструмент для исследований, но с оговорками. Идея запустить 10 агентов параллельно красивая, но в нашем окружении большинство из них не имели доступа к WebSearch. Зато это заставило сделать исследование самостоятельно — и результат оказался точнее, потому что можно было итеративно уточнять запросы.

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

Полезные ссылки

Паша Вин
Паша Вин

AI-инженер, предприниматель, маркетолог. Основатель feberra.com и x10seo.ru. 13 лет в перфоманс-маркетинге, 3 года в системной интеграции AI в бизнес.

Читайте также

Social Media Automation: архитектура и анти-бан система

CRM-мессенджер для Twenty CRM: чат внутри CRM

Anti-ban улучшения Telegram: geo-match, typing, лимиты