Rate limit, очереди и антиспам для форм и ботов

Rate limit, очереди и антиспам - три слоя защиты, без которых формы и Telegram/Discord-боты быстро превращаются в канал для спама, флуда и DoS. Один CAPTCHA не спасает: нужна связка ограничений по частоте, асинхронной обработки и фильтров по содержимому и репутации. Ниже - как собрать рабочую схему для сайта и ботов без лишней сложности.

• Rate limit - сколько запросов разрешено за окно времени с одного IP, аккаунта или токена
• Очередь - буфер между приёмом заявки и тяжёлой работой (письмо, CRM, LLM, webhook)
• Антиспам - honeypot, CAPTCHA, эвристики, блоклисты и проверка содержимого
• Правило - сначала режете частоту и асинхронно обрабатываете, потом усложняете фильтры
• Цель - сохранить заявки живых людей и не уронить сервис под ботнетом

Почему формы и боты атакуют в первую очередь

Публичный endpoint - это вход без логина. Спам-боты ищут /contact, /api/lead, webhook бота и шлют тысячи сообщений: фишинг, SEO-спам, credential stuffing, перебор промокодов. Без лимитов растут счета за email/SMS/LLM, засоряется CRM, а легитимные заявки тонут в шуме.

Типичные симптомы:

1. Резкий рост POST на форму при нулевых конверсиях в продажах
2. Одинаковые тексты с разных IP или наоборот - уникальный мусор с одного диапазона
3. Очередь писем или webhook'ов упирается в лимиты провайдера
4. Бот в мессенджере отвечает дольше обычного или падает по таймауту

Rate limit: что ограничивать и как

Rate limiting отвечает на вопрос: «сколько раз за N секунд можно трогать этот endpoint». Важно выбрать ключ ограничения.

Практичные окна:

• Форма заявки: 3-5 успешных отправок с IP за 10 минут, плюс жёсткий лимит на неуспешные (валидация, CAPTCHA fail)
• Логин / OTP: отдельно и строже - иначе брутфорс
• Бот-команды: 1 тяжёлый ответ (генерация, поиск) на пользователя в несколько секунд; лёгкие команды - мягче
• Глобальный потолок на процесс или воркер - защита от всплеска, даже если ключи разные

Ответ при превышении: HTTP 429 с Retry-After, в боте - короткое сообщение «подождите N секунд», без раскрытия внутренних порогов. Логируйте срабатывания: по ним видно, где лимит слишком мягкий или слишком жёсткий.

Очереди: зачем отделять приём от обработки

Форма не должна синхронно писать в CRM, генерировать PDF и звонить во внешний API. Очередь (Redis, RabbitMQ, SQS, Celery, BullMQ) принимает задачу сразу после валидации и отдаёт клиенту быстрый ответ: «заявка принята».

Что даёт очередь:

• Сглаживание пиков - спам или рекламный всплеск не роняет веб-процессы
• Повтор при сбоях - retry с backoff вместо потери заявки
• Приоритеты - оплаченные заказы выше, чем «скачать PDF»
• Изоляция - воркеры с LLM/почтой масштабируются отдельно от фронта

Схема для формы:

1. Проверка CSRF / origin, honeypot, базовая валидация полей
2. Rate limit
3. Запись заявки в БД со статусом queued
4. Push в очередь
5. HTTP 200/202 пользователю
6. Воркер: антиспам-скоринг → CRM / email / уведомление

Для ботов то же самое: апдейт от Telegram приняли быстро, тяжёлый ответ (RAG, картинка, парсинг) - в очередь. Иначе long polling / webhook начнёт копить задержки.

Антиспам: слои, а не одна галочка

Один reCAPTCHA не закрывает тему. Собирайте оборонительную глубину.

1. Дешёвые фильтры на входе

• Honeypot-поле (скрытое для людей, заполняемое ботами)
• Минимальное время заполнения формы (слишком быстро = бот)
• Проверка Referer / Origin и CSRF-токена
• Ограничение размера тела запроса и числа вложений

2. CAPTCHA и challenge

Включайте challenge по сигналу, а не всегда: после N попыток, при подозрительном IP, при высоком score. Постоянная CAPTCHA бьёт по конверсии; точечная - почти нет.

3. Контент и репутация

• Блоклисты доменов/URL в тексте заявки
• Детект повторяющихся шаблонов и language-agnostic спама
• Проверка email (MX, disposable-домены)
• Для ботов: фильтр ссылок, стоп-слова, лимит медиа

4. Поведенческие сигналы

История: сколько заявок с этого устройства закончились покупкой или осмысленным диалогом. Новый IP с десятком «купить seo» за минуту - в карантин или ручную модерацию, а не сразу в CRM менеджера.

Как связать три слоя в одну схему

Рекомендуемый порядок для продакшена:

1. Валидация и дешёвый антиспам (honeypot, размер, CSRF)
2. Rate limit по IP + по идентификатору пользователя/чата
3. Быстрый ответ клиенту / мессенджеру
4. Очередь с лимитом concurrent jobs на воркер
5. Тяжёлый антиспам и интеграции в воркере (скоринг, CRM, email)
6. Алерты при всплеске 429 и росте rejected jobs

Так вы не тратите CPU и деньги провайдеров на запросы, которые уже должны были отсечься лимитом.

Чек-лист внедрения

• [ ] У формы и бота разные лимиты под разный риск
• [ ] Есть глобальный circuit breaker на исходящие email/SMS/LLM
• [ ] 429 и сообщения бота понятны человеку, но не подсказывают, как обойти
• [ ] Очередь имеет DLQ (dead letter) и мониторинг длины
• [ ] Подозрительные заявки уходят в карантин, а не удаляются молча
• [ ] Логи rate limit и spam-score доступны без доступа к ПДн целиком
• [ ] Нагрузочный тест: что происходит при 100 RPS на /contact

Итог

Rate limit режет частоту, очередь защищает бэкенд и бюджеты интеграций, антиспам отделяет мусор от лидов. Работают они только вместе: лимит без очереди всё равно роняет синхронные хендлеры, очередь без фильтров разносит спам по CRM, фильтры без лимита дорожают под DDoS.

Если нужно спроектировать защиту форм и ботов под ваш стек (лимиты, очередь, карантин, мониторинг) - свяжитесь со мной. Ориентиры по сопровождению и доработкам - на странице прайса.

Часто задаваемые вопросы

Чем rate limit отличается от антиспама?

Rate limit считает попытки, антиспам оценивает содержимое и поведение. Лимит остановит флуд даже «чистыми» запросами; антиспам поймает редкий, но токсичный спам, который укладывается в лимит.

Нужна ли очередь, если заявок мало?

Да, если есть внешние API, почта или LLM. Даже при малом трафике синхронный таймаут CRM ломает UX формы. Очередь дешёва в простое и спасает в пике.

CAPTCHA обязательна на каждой форме?

Нет. Лучше показывать challenge по риску: после серии ошибок, с плохой репутации IP или при аномальном скоре. Так вы меньше мешаете людям и всё ещё режете ботов.

Что ставить в боте: лимит на chat_id или на IP?

Оба. chat_id защищает от флуда одним пользователем; IP/токен webhook - от подделки апдейтов и сканирования. Для групп лимиты обычно жёстче, чем в личке.

Куда девать заявки, которые похожи на спам?

В карантин с ручным разбором или отложенной доставкой, а не в корзину без следа. Иначе потеряете редкий легитимный лид и не увидите, как меняются паттерны атак.

Термины в статье

webhook — HTTP callback when an event happens — HTTP-уведомление при наступлении события

LLM — Large Language Model — большая языковая модель

CRM — Customer Relationship Management — управление взаимоотношениями с клиентами

DDoS — Distributed Denial of Service — распределённая атака отказа в обслуживании