Rate-limit Facebook в 2026: реальная инженерия детектирования

Любой, кто запускал программы для постинга в Facebook больше пары недель, знает неприятную правду: механизм rate-limit Facebook в 2026 году - это не одна стена, а сеть из трёх накладывающихся друг на друга границ: на аккаунт, на час и на группу. Проблема в том, что ни одна из этих границ публично не задокументирована. Facebook не выпустит API, который скажет: «ты дошёл до 121 поста, подожди». Вместо этого появляется визуальный диалог с туманным сообщением об ошибке, когда вы пересекаете порог.

В этой статье я разберу механизм rate-limit, каким он выглядит в 2026 году, покажу как структурно устроен диалог в DOM, и почему структурное детектирование в 50 раз надёжнее текстового. Если вы пишете свой инструмент автоматизации Facebook - или клиент BuzzPost, которому интересна техническая сторона - это для вас.

Сколько постов реально можно публиковать в день?

Вот цифры, которые мы видим после трёх лет непрерывных измерений на сотнях аккаунтов в секторе недвижимости Израиля:

Два важных момента про эту таблицу. Во-первых, цифры зависят от аккаунта. 8-летний аккаунт с богатой органической активностью (реальные друзья, лайки, комментарии, шаринги) выдержит 150 постов в день без проблем. Свежий аккаунт двух недель от роду - 40 уже потолок. Во-вторых, Facebook измеряет не только темп - он измеряет темп + сходство контента + сходство тайминга в комплексе.

Это не просто обработка текста - а обработка многомерного vector. Например, если пост #1 опубликован в 03:14 и содержит слова «квартира в аренду Кирьят-Моцкин», а пост #2 опубликован в 03:14:08 и содержит «квартира в аренду Кирьят-Моцкин 3 комнаты», Facebook определит, что это семантические близнецы. Даже если вы изменили одно слово. Единственный способ обойти - настоящая рандомизация структуры предложений, порядка абзацев, целенаправленных опечаток - но и этого недостаточно, если темп не меняется.

Почему ночные часы (00:00-07:00) - это золото

Наш анализ на датасете больше миллиона постов показывает: между 00:00 и 07:00 по израильскому времени процент успешных публикаций составляет ~94%, против ~71% в часы 09:00-22:00. Причина: в эти часы нагрузка автоматических проверок Facebook ниже, число человеческих жалоб на группы ниже, а алгоритм поиска спама опирается больше на грубые поведенческие сигналы и меньше на тонкий анализ каждого поста.

Дополнительно, большинство групп по израильской недвижимости «просыпаются» около 06:00 - люди, начинающие день, проверяют ленту. Пост, опубликованный в 04:30, всё ещё находится в верху ленты в 07:00 и получает всю органическую видимость, тогда как пост в 08:00 быстро вытесняется новыми.

Что именно происходит ночью в командном центре Facebook?

Facebook задействует несколько слоёв детектирования: (1) real-time ML модель, смотрящая на vector действий, (2) batch модель, обновляющаяся каждый час и держащая более длинную историю, (3) жалобы пользователей, обрабатываемые в основном человеческими reviewer'ами в рабочие часы. В европейско-американскую ночь человеческие команды меньше, а real-time модели работают с чуть более лояльным threshold, потому что каждая минута ложной блокировки стоит много в производительности рекомендательных движков. Это не официальная документация - это вывод из измеренного поведения.

Один конкретный час, который стоит упомянуть: 04:00-05:00. Это окно, когда большинство хранилищ данных Facebook запускают tasks обслуживания и data warehousing. В результате модели, обрабатывающие детектирование спама в реальном времени, работают на чуть более старых caches и менее быстро помечают новый аккаунт. Если вы должны выбрать один час ночи - выберите 04:30.

Структура диалога rate-limit в DOM

Здесь начинается техническая часть. Когда Facebook решает, что вы пересекли порог - он не блокирует запрос на уровне network. Запрос проходит, сервер принимает, и Facebook выбирает показать модальный диалог поверх экрана с сообщением об ошибке вместо открытия поста в группе. Вопрос: как распознать этот диалог автоматически?

Подход 1 (плохой): сопоставление текста

Интуитивный подход - искать текст: if "вы не можете публиковать" in page_text:. Проблема? Facebook меняет формулировку каждые 2-4 месяца. В 2024 году мы видели 14 различных вариантов на английском, 8 на иврите. На русском (для русскоязычных пользователей):

• "Сейчас вы не можете публиковать. Попробуйте позже."
• "Не удалось опубликовать в этой группе."
• "По соображениям безопасности публикация временно заблокирована."
• "Обнаружена необычная активность в вашем аккаунте."
• "Превышен дневной лимит публикаций."
• "Это действие сейчас недоступно."
• "Невозможно опубликовать этот контент в этом месте."
• "Защитная система выявила необычный паттерн."

Текстовое детектирование ломается каждый раз, когда Facebook обновляет формулировку. Если ваша программа опирался на «не удалось опубликовать», в один день он начнёт думать, что все посты прошли, и опубликует 200 постов, которые на самом деле были заблокированы, что приведёт к каскадному ухудшению аккаунта.

Хуже: переводы Facebook на русский проходят ротацию в A/B testing. Два разных пользователя, в один момент, в одной версии приложения - могут получить разные формулировки. Программа, опирающийся на сопоставление текста, держится только для конкретного среза, в котором вы тестировали.

Подход 2 (хороший): структурное детектирование

Наш подход в BuzzPost опирается на структуру кнопок внутри диалога, а не на текст. Состояние успешного поста отличается от состояния ошибки по 3 структурным критериям:

Структурный код выглядит примерно так (без раскрытия всех наших селекторов, но идея ясна):

def detect_post_outcome(driver, timeout=20):
    # Структурный детектор - не зависит от формулировки
    end = time.time() + timeout
    while time.time() < end:
        dialogs = driver.find_elements(By.CSS_SELECTOR, '[role="dialog"]')
        if not dialogs:
            return "success"
        for d in dialogs:
            buttons = d.find_elements(By.CSS_SELECTOR, '[role="button"]')
            if len(buttons) == 1:
                # Только кнопка закрытия -> ограничение группы
                return "group_restricted"
            send_btn = find_primary_button(buttons)
            if send_btn and send_btn.get_attribute("aria-disabled") == "true":
                if not has_spinner(d):
                    return "rate_limit"
        time.sleep(0.5)
    return "timeout"

Обратите внимание: код не читает ни одного слова текста. Он проверяет только role="dialog", role="button" и aria-disabled. Это структурные элементы системы доступности Facebook (Accessibility) - они в 100 раз стабильнее, чем тексты. Facebook не откажется от ARIA, потому что это требование закона в Европе и США.

Почему ARIA так стабильна?

В США Facebook подчиняется Americans with Disabilities Act (ADA) и class action искам по доступности для слепых. В EU есть European Accessibility Act, вступивший в силу в июне 2025. Результат: Facebook обязан поддерживать role="dialog", aria-label, aria-disabled, aria-busy на каждом взаимодействии. Изменение ARIA = нарушение закона. Изменение текста = ничего. Поэтому программа, опирающийся на ARIA, работает годами без обслуживания, а программа, опирающийся на текст, ломается каждый квартал.

Ключевой инсайт: Этот подход спасал нас 14 раз за последние четыре года. Каждый раз, когда Facebook менял текст сообщения об ошибке, все программы, опирающиеся на сопоставление текста, падают - а наш продолжает работать без изменения кода даже.

Три категории блокировки - и разное обращение с каждой

1. Soft rate-limit (временная блокировка аккаунта)

Самый частый. Аккаунт «остывает» от 30 минут до 24 часов. Правильное обращение: немедленная остановка, никаких попыток. Каждая дополнительная попытка в этот период добавляет «чёрных очков» аккаунту. Программа должна войти в режим cooldown и вернуться минимум через 3-6 часов. В BuzzPost это полностью автоматизировано: с момента детектирования структурного rate-limit система показывает алерт на панели и останавливает конкретную ветку до того, как пользователь попросит возобновить.

Частая ошибка: думать «если следующая попытка провалится, попробую ещё раз». Facebook видит этот темп и помечает аккаунт как «automation suspected». 5-10 повторных попыток за 10 минут равны escalation с soft на hard ban.

2. Group restriction (конкретная группа отказывает)

Аккаунт в порядке, но группа X не позволяет вам в ней публиковать. Причины: админ группы пожаловался, внутренний алгоритм группы (чатбот админа) блокирует, или группа требует апрува админа на каждый пост. Обращение: счётчик неудач. После 5 подряд неудач на одну группу - добавить в blacklist и двигаться дальше. Не пробовать снова в ближайших циклах.

Причина 5, а не 1: иногда пост проваливается из-за временного сбоя коннективности или медленной загрузки самого Facebook. Одна ошибка не доказывает ничего. 5 подряд ошибок, однако, - это сильный signal.

3. Hard ban (бан аккаунта)

Аккаунт требует подтверждения личности (документ) или забанен на 30 дней / навсегда. Здесь программа ничего не может - нужно вмешательство человека. Важно: когда программа детектирует hard ban, он должен полностью остановиться, сохранить скрин + DOM и отправить алерт. Попытка повторного входа без обработки подтверждения только приведёт к перманентной блокировке. Смотрите почему аккаунты банятся для подробностей.

4. Checkpoint challenge («мягкое» подтверждение личности)

Четвёртая категория, не попадающая в сводную таблицу, но требующая обработки: Facebook иногда показывает challenge - SMS-код, email, или подтверждение фото. Программа не может пройти это автоматически (и не должен - это пересекает границу ToS). Он должен распознать iframe captcha или требование SMS, остановиться, и обратиться к владельцу.

Как это интегрировано в реальную систему

В операционной системе BuzzPost структурный детектор rate-limit подаётся в pipeline из 5 этапов:

1. Детектирование: детектор возвращает "rate_limit" после поста.
2. Сохранение доказательств: скрин + DOM сохраняются в _rl_evidence/YYYYMMDD_HHMMSS.png и .txt. Эти доказательства используются позже для апелляции, если аккаунт заблокирован.
3. Алерт в Telegram: служебная программа шлёт сообщение владельцу: «VDS #3 - аккаунт X пойман в rate-limit, входит в cooldown».
4. POST на панель: сервер управления получает POST с {"server_id": 3, "type": "rate_limit", "timestamp": ...} и сохраняет в DB.
5. UI: на панели управления появляется красная плашка на конкретном сервере, автоматически очищается, когда следующий пост проходит.

Это конвейер, который позволяет 150+ аккаунтам работать без человеческой руки, а в момент проблемы - вы знаете за 30 секунд. Если хотите купить эту инфраструктуру, а не строить - смотрите тарифы.

Практические правила

Если строите своё - вот короткий чек-лист:

• Темп: никогда не превышать 6 постов в час на аккаунт. Между постами - сэндвич 8-22 секунд с рандомизацией.
• Распределение: распределить активность по 4-5 окнам времени за 24 часа, не концентрировать в одном burst.
• Вариация: каждый пост с разным текстом по структуре (не только словам), каждый пост с разным фото, каждый пост с другими hashtags.
• Прогрев: новый аккаунт - 3 недели сёрфинга и лайков перед первым автоматическим постом.
• Структурный детектор: не опирайтесь на текст. Только на структуру ARIA.
• Журнал: каждый пост сохранён с временем, группой, результатом. Без этого вы слепы.
• Сетевая изоляция между аккаунтами: каждый аккаунт на своём VDS с отдельным IP.

Итог

rate-limit в 2026 - это не одно число, а трёхмерная сеть границ. Долгосрочный успех требует: (а) работы в правильные часы (ночь Израиля), (б) стабильного структурного детектирования, не ломающегося с каждым обновлением UI, (в) трёх разных категорий реакции на три категории блокировок, (г) агрессивного и пассивного cooldown, (д) сохранения доказательств для апелляции, если аккаунт всё же забанили. BuzzPost обрабатывает всё это автоматически - каждый клиент получает выделенный VDS, отдельный профиль Chrome, и структурный мониторинг rate-limit, обкатанный на миллионе постов. Если вы хотите начать постить недвижимость в группы Facebook и не потерять аккаунт через неделю - купите первый план за 249₪/мес, один сервер, весь мониторинг внутри.

Для дальнейшего чтения смотрите наш блог и связанные статьи: возможности системы, антидетекция, cookies и сессии.