Лимит частоты запросов, очереди и антиспам для форм и ботов
Лимит частоты запросов, очереди и антиспам - три слоя защиты, без которых формы и Telegram/Discord-боты быстро превращаются в канал для спама, флуда и DoS. Одна капча не спасает: нужна связка ограничений по частоте, асинхронной обработки и фильтров по содержимому и репутации. Ниже - как собрать рабочую схему для сайта и ботов без лишней сложности.
- Лимит частоты запросов - сколько запросов разрешено за окно времени с одного IP, аккаунта или токена
- Очередь - буфер между приёмом заявки и тяжёлой работой (письмо, CRM, LLM, вебхук)
- Антиспам - honeypot, капча, эвристики, блоклисты и проверка содержимого
- Правило - сначала режете частоту и асинхронно обрабатываете, потом усложняете фильтры
- Цель - сохранить заявки живых людей и не уронить сервис под ботнетом
- Зачем бизнесу - меньше спама в CRM и почте, ниже счета за SMS/LLM/API, отдел продаж видит только реальные заявки
Почему формы и боты атакуют в первую очередь
Публичный эндпоинт - это вход без логина. Спам-боты ищут /contact, /api/lead, вебхук бота и шлют тысячи сообщений: фишинг, SEO-спам, подстановку учётных данных, перебор промокодов. Без лимитов растут счета за email/SMS/LLM, засоряется CRM, а легитимные заявки тонут в шуме.
Типичные симптомы:
- Резкий рост POST на форму при нулевых конверсиях в продажах
- Одинаковые тексты с разных IP или наоборот - уникальный мусор с одного диапазона
- Очередь писем или вебхуков упирается в лимиты провайдера
- Бот в мессенджере отвечает дольше обычного или падает по таймауту
Лимит частоты запросов: что ограничивать и как
Ограничение частоты запросов отвечает на вопрос: «сколько раз за N секунд можно трогать этот эндпоинт». Важно выбрать ключ ограничения.
| Ключ | Когда уместен | Риск |
|---|---|---|
| IP | Анонимные формы, вебхук без auth | NAT и корпоративные сети режут «хороших» |
| User / chat_id | Авторизованные API и боты | Не защищает до логина |
| API-токен / session | Партнёрские интеграции | Украденный токен = весь лимит злоумышленника |
| Цифровой отпечаток + IP | Жёсткий антиабьюз форм | Сложнее внедрить и объяснить пользователю |
Практичные окна:
- Форма заявки: 3-5 успешных отправок с IP за 10 минут, плюс жёсткий лимит на неуспешные (валидация, CAPTCHA fail)
- Логин / OTP: отдельно и строже - иначе брутфорс
- Бот-команды: 1 тяжёлый ответ (генерация, поиск) на пользователя в несколько секунд; лёгкие команды - мягче
- Глобальный потолок на процесс или воркер - защита от всплеска, даже если ключи разные
Ответ при превышении: HTTP 429 с Retry-After, в боте - короткое сообщение «подождите N секунд», без раскрытия внутренних порогов. Логируйте срабатывания: по ним видно, где лимит слишком мягкий или слишком жёсткий.
Очереди: зачем отделять приём от обработки
Форма не должна синхронно писать в CRM, генерировать PDF и звонить во внешний API. Очередь (Redis, RabbitMQ, SQS, Celery, BullMQ) принимает задачу сразу после валидации и отдаёт клиенту быстрый ответ: «заявка принята».
Что даёт очередь:
- Сглаживание пиков - спам или рекламный всплеск не роняет веб-процессы
- Повтор при сбоях - повторная попытка с паузой между повторами вместо потери заявки
- Приоритеты - оплаченные заказы выше, чем «скачать PDF»
- Изоляция - воркеры с LLM/почтой масштабируются отдельно от фронта
Схема для формы:
- Проверка CSRF / origin, honeypot, базовая валидация полей
- Rate limit
- Запись заявки в БД со статусом
queued - Push в очередь
- HTTP 200/202 пользователю
- Воркер: антиспам-скоринг → CRM / email / уведомление
Для ботов то же самое: апдейт от Telegram приняли быстро, тяжёлый ответ (RAG, картинка, парсинг) - в очередь. Иначе длинный опрос / вебхук начнёт копить задержки.
Антиспам: слои, а не одна галочка
Один reCAPTCHA не закрывает тему. Собирайте оборонительную глубину.
1. Дешёвые фильтры на входе
- Honeypot-поле (скрытое для людей, заполняемое ботами)
- Минимальное время заполнения формы (слишком быстро = бот)
- Проверка
Referer/Originи CSRF-токена - Ограничение размера тела запроса и числа вложений
2. Капча и challenge
Включайте challenge по сигналу, а не всегда: после N попыток, при подозрительном IP, при высокой оценке. Постоянная капча бьёт по конверсии; точечная - почти нет.
3. Контент и репутация
- Блоклисты доменов/URL в тексте заявки
- Детект повторяющихся шаблонов и спама, независимого от языка
- Проверка email (MX, disposable-домены)
- Для ботов: фильтр ссылок, стоп-слова, лимит медиа
4. Поведенческие сигналы
История: сколько заявок с этого устройства закончились покупкой или осмысленным диалогом. Новый IP с десятком «купить SEO» за минуту - в карантин или ручную модерацию, а не сразу в CRM менеджера.
Как связать три слоя в одну схему
Рекомендуемый порядок для продакшена:
- Валидация и дешёвый антиспам (honeypot, размер, CSRF)
- Лимит частоты запросов по IP + по идентификатору пользователя/чата
- Быстрый ответ клиенту / мессенджеру
- Очередь с лимитом параллельных задач на воркер
- Тяжёлый антиспам и интеграции в воркере (скоринг, CRM, email)
- Алерты при всплеске 429 и росте rejected jobs
Так вы не тратите CPU и деньги провайдеров на запросы, которые уже должны были отсечься лимитом.
Чек-лист внедрения
- [ ] У формы и бота разные лимиты под разный риск
- [ ] Есть глобальный предохранитель на исходящие email/SMS/LLM
- [ ] 429 и сообщения бота понятны человеку, но не подсказывают, как обойти
- [ ] Очередь имеет DLQ («мёртвые» сообщения) и мониторинг длины
- [ ] Подозрительные заявки уходят в карантин, а не удаляются молча
- [ ] Логи лимита частоты запросов и оценки спама можно разбирать по IP/хэшу, эндпоинту и оценке без доступа к персональным данным целиком (ФИО, email, телефон, текст заявки)
- [ ] Нагрузочный тест: что происходит при 100 RPS на
/contact
Когда усложнять рано
Не каждому проекту нужна вся связка сразу:
- Статический сайт без форм и ботов - защищать нечего, лимиты не нужны
- До 10-20 заявок в день и без внешних API/LLM - хватит капчи и лимита на уровне хостинга/CDN (Cloudflare, Nginx); отдельная очередь пока не окупает разработку
- Ранний MVP - сначала проверьте, что продукт нужен рынку, антиспам и очередь добавляйте по мере роста трафика и первых атак
- Уже есть managed-защита (Cloudflare, WAF, форма со встроенным антиспамом) - сначала используйте её лимиты и фильтры, не дублируйте инфраструктуру с нуля
Если трафик и число интеграций растут - возвращайтесь к полной схеме выше.
Итог
Лимит частоты запросов режет частоту, очередь защищает бэкенд и бюджеты интеграций, антиспам отделяет мусор от лидов. Работают они только вместе: лимит без очереди всё равно роняет синхронные обработчики, очередь без фильтров разносит спам по CRM, фильтры без лимита дорожают под DDoS.
Если нужно спроектировать защиту форм и ботов под ваш стек (лимиты, очередь, карантин, мониторинг) - свяжитесь со мной. Ориентиры по сопровождению и доработкам - на странице прайса.
Часто задаваемые вопросы
Чем лимит частоты запросов отличается от антиспама?
Лимит частоты запросов считает попытки, антиспам оценивает содержимое и поведение. Лимит остановит флуд даже «чистыми» запросами; антиспам поймает редкий, но токсичный спам, который укладывается в лимит.
Нужна ли очередь, если заявок мало?
Да, если есть внешние API, почта или LLM. Даже при малом трафике синхронный таймаут CRM ломает UX формы. Очередь дешёва в простое и спасает в пике.
Капча обязательна на каждой форме?
Нет. Лучше показывать challenge по риску: после серии ошибок, с плохой репутации IP или при аномальном скоре. Так вы меньше мешаете людям и всё ещё режете ботов.
Что ставить в боте: лимит на chat_id или на IP?
Оба. chat_id защищает от флуда одним пользователем; IP/токен вебхука - от подделки апдейтов и сканирования. Для групп лимиты обычно жёстче, чем в личке.
Куда девать заявки, которые похожи на спам?
В карантин с ручным разбором или отложенной доставкой, а не в корзину без следа. Иначе потеряете редкий легитимный лид и не увидите, как меняются паттерны атак.
Термины в статье
CRM — Customer Relationship Management — управление взаимоотношениями с клиентами
SMS — Short Message Service — короткие текстовые сообщения на телефон
LLM — Large Language Model — большая языковая модель
эндпоинт — endpoint — точка API / конкретный URL API (endpoint)
вебхук — webhook — HTTP-уведомление при наступлении события
воркеры — workers — фоновые процессы, которые обрабатывают задачи из очереди
rate limit — cap on how many requests are allowed per time window — лимит числа запросов за единицу времени
CSRF — Cross-Site Request Forgery — подделка межсайтовых запросов от имени пользователя
CDN — Content Delivery Network — сеть доставки контента
MVP — Minimum Viable Product — минимально жизнеспособный продукт
бэкенд — backend — серверная логика, API и слой данных (backend)
DDoS — Distributed Denial of Service — распределённая атака отказа в обслуживании
таймаут — timeout — предельное время ожидания (timeout)
паттерны — reusable solution patterns for common design problems — повторно используемые приёмы для типовых задач проектирования