Настройка 429 Too Many Requests: защита сайта от запросов

Ошибка 429 Too Many Requests — это не просто “сервер устал”. На деле это один из самых полезных ответов, если его нормально настроить: он помогает отрезать ботов, защитить формы, снизить нагрузку на PHP 8.1–8.3 и не дать одному клиенту или кривому скрипту положить сайт в пике трафика.

У меня на практике 429 чаще всего всплывает на WordPress, Bitrix и Laravel-проектах, где всё работает “вроде бы нормально”, пока не начинается активность: парсеры, подбор паролей, агрессивные API-запросы, спам через формы, тесты с внешних сервисов. И вот тут уже однозначно стоит не просто “включить лимит”, а понять, где именно его ставить: в nginx, в Laravel middleware, на уровне CDN, в firewall или прямо в приложении.

Что такое 429 Too Many Requests и зачем он вообще нужен

HTTP-статус 429 Too Many Requests означает, что клиент превысил допустимое число запросов за заданный промежуток времени. Грубо говоря, сайт говорит: “Стоп, ты слишком часто дёргаешь этот ресурс, притормози”. Это не ошибка в классическом смысле, как 500, и не проблема маршрутизации, как 404. Это осознанный механизм защиты.

Я обычно объясняю клиентам так: если у вас магазин на Bitrix или WordPress и один IP за 10 секунд делает 300 запросов к /wp-login.php, это уже не “энтузиаст”, а атака или кривой бот. Если API вашего Laravel-сервиса получает 1000 запросов в минуту с одного токена — надо ставить лимит. Если поисковый робот или скрипт конкурента молотит каталог, 429 помогает остановить избыточную активность без полного блокирования доступа.

И тут важный момент: 429 — это не замена всем мерам безопасности. Это один слой. Хорошо работает в связке с firewall, защитой от ботов и нормальной системой логирования. Иначе получится как поставить замок на дверь, но оставить окно открытым.

Где ставить ограничение запросов: nginx, приложение, CDN или firewall

Самая частая ошибка — пытаться решить всё только одним способом. Честно говоря, это плохая идея. На одном сайте я видел nginx-limit, Cloudflare rule и ещё Laravel middleware одновременно, но с кривыми настройками. В итоге честные пользователи ловили 429 уже после 3–4 кликов по каталогу.

Я обычно делю защиту на уровни. Первый уровень — CDN и edge-защита, если она есть. Второй — веб-сервер: nginx или Apache. Третий — приложение: WordPress, Bitrix, Laravel. Четвёртый — БД и внутренние механизмы, если запросы бьют по тяжёлым операциям. Такой подход удобнее сопровождать и проще отлаживать.

Если у вас проект на WordPress с обычным трафиком, часто хватает nginx + плагин для защиты логина + ограничения на уровне Cloudflare. Для Bitrix я чаще использую nginx и продуманный кеш, а внутри — аккуратную защиту форм и авторизации. Для Laravel rate limiting встроен почти из коробки, и этим надо пользоваться, а не изобретать велосипед.

И ещё момент. Если у вас высокий трафик, сначала смотрите не на “количество запросов вообще”, а на тип запросов: логин, поиск, фильтры, API, корзина, формы, webhooks. Именно там обычно и сидит нагрузка.

Настройка 429 в nginx: рабочие примеры

На моей практике nginx — это самый предсказуемый способ ограничить частоту запросов. Он быстрый, стабильный и не требует лезть в код CMS. Если сервер на Linux, PHP-FPM 8.1/8.2/8.3 и nginx 1.22+ — это вообще стандартный сценарий.

Обычно я начинаю с двух директив: limit_req_zone и limit_req. Первая создаёт зону хранения статистики, вторая применяет лимит к конкретному location или server. Самое удобное — ограничивать именно чувствительные точки: логин, формы, API, поиск.

http {
    limit_req_zone $binary_remote_addr zone=login_zone:10m rate=5r/m;

    server {
        listen 443 ssl http2;
        server_name example.com;

        location = /wp-login.php {
            limit_req zone=login_zone burst=3 nodelay;
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        }

        location = /bitrix/admin/ {
            limit_req zone=login_zone burst=5 nodelay;
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        }

        location /api/ {
            limit_req zone=login_zone burst=20 nodelay;
            proxy_pass http://backend;
        }
    }
}

Если лимит превышен, nginx по умолчанию отдаёт 503, но это не всегда то, что нужно. Для 429 нужен отдельный код возврата. На новых версиях nginx это можно настроить через limit_req_status 429;. Я почти всегда включаю именно его, потому что это понятнее и для логов, и для аналитики, и для разработчиков.

http {
    limit_req_zone $binary_remote_addr zone=api_zone:20m rate=10r/s;
    limit_req_status 429;

    server {
        location /api/ {
            limit_req zone=api_zone burst=50 nodelay;
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

Но тут есть нюанс. Если поставить слишком жёсткий лимит по IP, можно наказать целый офис за NAT или мобильный сегмент оператора. Особенно это заметно на интернет-магазинах и корпоративных порталах. Поэтому я обычно смотрю логи и тестирую нагрузку вручную: 10–20 запросов в секунду для API иногда нормально, а для формы входа — уже перебор.

Если у вас нет доступа к конфигу nginx, можно частично решить задачу через Apache и .htaccess, но это уже не лучший вариант по производительности. Для небольших WordPress-проектов с shared-хостингом — терпимо. Для проекта на 50 000+ страниц и живым трафиком — забудьте про это, нужен nginx или CDN.

429 в Laravel, WordPress и Bitrix: где логика уже есть, а где её приходится дописывать

Laravel здесь особенно удобен. В нём rate limiting встроен через middleware и класс RateLimiter. Для бизнес-проекта на Laravel 10/11 я обычно настраиваю лимиты на login, password reset, search, API endpoints и webhooks. Это быстро, прозрачно и не требует костылей.

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('login', function (Request $request) {
    return [
        Limit::perMinute(5)->by($request->ip()),
        Limit::perMinute(20)->by($request->input('email')),
    ];
});

Такой подход хорош тем, что можно лимитировать не только по IP, но и по email, токену, user id, session id. И это уже гораздо умнее. На одном клиентском проекте я видел классическую атаку на логин: один IP был за прокси, но email-итерации шли по списку. Лимит по IP не спасал, а лимит по email сразу обрубил шум.

В WordPress история другая. Там сам движок 429 не раздаёт по умолчанию, и приходится подключать либо веб-сервер, либо плагины безопасности. Я часто ставлю что-то из серии Wordfence, iThemes Security или Cloudflare WAF, но без фанатизма. Плагин — это не магия. Он может помочь, но если у вас wp-login.php открыта всем и без ограничений, проблемы всё равно будут.

Для Bitrix я обычно смотрю на вход в админку, AJAX-эндпоинты, поиск и тяжёлые фильтры каталога. Сам по себе Битрикс умеет жить с высокой нагрузкой, но если поверх него навешаны дорогие SQL-запросы, а кеш не настроен, rate limiting помогает хотя бы не дать нагрузке расти линейно. Кстати, если вы уже читали статью про Битрикс или WordPress, то знаете: у каждой CMS свои слабые места, и универсального рецепта нет.

429 и защита от ботов: почему один rate limiting не спасает

Боты сегодня умеют обходить примитивные ограничения. Меняют IP, крутят user-agent, держат паузы, используют headless-браузеры. Поэтому 429 — это хороший фильтр, но не конечная защита. Я бы сказал так: это первая линия обороны, а не крепостная стена.

На одном интернет-магазине у нас была проблема: боты массово забивали форму обратной связи и каталог запросами по фильтрам. Ставим ограничение на IP — часть шума исчезает, но не всё. Подключаем защиту форм, антиспам-логику, нормальный CAPTCHA-слой и WAF — и уже получаем адекватную картину. В итоге нагрузка на PHP-FPM упала примерно с 80–90% до 20–30% в пиковые часы.

Если у вас есть публичный API, обязательно лимитируйте не только по IP, но и по токену. Иначе один клиент с прокси-сетью сможет съесть весь пул запросов. Это особенно актуально для SaaS, интеграций CRM и webhooks. У меня был случай, когда один внешний сервис отправлял webhook каждые 2–3 секунды, а потом ушёл в петлю. Без 429 мы бы просто выжгли очередь задач.

И ещё. Для защиты от ботов хорошо работают дополнительные сигналы: поведенческие правила, JavaScript challenge, ограничение по странам, проверка на пустые/подозрительные поля формы. В связке с 429 это даёт уже вменяемую оборону, а не декоративную.

Логи, мониторинг и отладка: как не задушить живых пользователей

Самая неприятная ситуация — когда 429 вроде бы включили, а потом поддержка начинает получать жалобы: “не могу войти”, “корзина не открывается”, “форма не отправляется”. Поэтому я всегда прошу смотреть логи. Без логов rate limiting превращается в угадайку.

На nginx я обычно проверяю access/error логи, отдельно смотрю частоту 429 по URI, IP, user-agent и времени. Если есть Elasticsearch или хотя бы нормальная ротация логов, жизнь становится проще. А если ещё настроен мониторинг сайта, то можно быстро увидеть всплеск ошибок и понять, это реальная атака или слишком жёсткий лимит.

По опыту, полезно вести отдельный список “разрешённых” клиентов: внутренние сервисы, CRM, мобильные приложения, платежные шлюзы. Иначе вы сами себе отрежете интеграции. Особенно это важно, если у вас есть API-интеграции на сайте или внешние webhooks.

SELECT 
    request_uri,
    status,
    COUNT(*) AS cnt
FROM access_log
WHERE status = 429
  AND created_at > NOW() - INTERVAL 1 DAY
GROUP BY request_uri, status
ORDER BY cnt DESC;

Такой запрос помогает понять, что именно упирается в лимит. Если в топе /wp-login.php или /bitrix/admin/ — всё логично. Если в топе главная страница или каталог, значит, вы слишком агрессивно сжали лимиты или у вас есть проблема на стороне фронта: слишком частые AJAX-запросы, автоподгрузка, бесконечный поиск.

Я обычно ещё проверяю, не вызывает ли 429 цепочку вторичных проблем. Например, если в админке WordPress ограничить запросы слишком жёстко, то автосохранение постов начнёт сбоить. В Bitrix может начать “сыпаться” AJAX корзины. В Laravel могут ломаться очереди, если лимит поставить на endpoint, который дергается слишком часто внутренними задачами. Тут без тестов никак.

Как подобрать правильные лимиты: цифры, которые работают на практике

Вот здесь начинается реальная работа, а не теория. Универсального значения нет. Но есть типовые стартовые точки, с которых я обычно начинаю настройку. Для формы логина — 5 запросов в минуту с одного IP. Для password reset — 3–5 запросов в минуту. Для API — от 10 до 60 запросов в секунду, в зависимости от задачи. Для поиска по каталогу — 30–60 запросов в минуту, если это публичная функция.

Если сайт маленький, трафика мало и нет агрессивных интеграций, можно сделать лимиты мягче. Если это интернет-магазин, который в пик держит 3–5 тысяч посетителей в сутки, я обычно сначала смотрю на поведение реальных пользователей. И только потом режу. Иначе легко получить конфликт между безопасностью и UX.

Был случай у клиента на WordPress 6.6 с WooCommerce: поставили слишком жёсткий лимит на все AJAX-запросы. В итоге форма корзины на мобильных устройствах стала срабатывать через раз, а PageSpeed при этом вообще не виноват. Пришлось разделить лимиты по путям, убрать защиту с публичных динамических endpoints и оставить 429 только на авторизацию и API. После этого всё встало на свои места.

Если говорить совсем практично, я обычно проверяю следующие признаки, что лимит выбран нормально:

• легитимные пользователи не видят 429 при обычной работе;
• боты и скрипты быстро упираются в ограничение;
• в логах нет массовых ложных срабатываний;
• нагрузка на PHP-FPM и MySQL 8.0 падает в пиковые часы;
• админка и интеграции продолжают работать без сбоев.

Типичные ошибки при настройке 429 и как их не допустить

Самая частая ошибка — ограничивать только по IP. Это сработает против примитивных ботов, но легко обходится через прокси, мобильные сети и распределённые источники. Вторая ошибка — ставить слишком маленький burst. Тогда даже нормальный пользователь ловит блокировку, потому что сделал 2–3 клика подряд.

Третья ошибка — не учитывать внутренние запросы сайта. У одного клиента на Laravel мы поставили лимит на весь /api/, а потом удивлялись, почему мобильное приложение периодически отваливается. Оказалось, что приложение при открытии экрана делает сразу 7 запросов: профиль, уведомления, список заказов, избранное, баннеры, акции и настройки. Формально это “слишком много”, а по факту — обычная работа интерфейса.

Четвёртая ошибка — не логировать срабатывания. Когда 429 включён, но вы не видите статистику, отладка превращается в мучение. Пятая — ставить ограничения на страницы, которые уже защищены другим слоем, и тем самым создавать лишний шум. Например, если у вас есть CDN с WAF, потом nginx, потом ещё плагин на WordPress, можно перегрузить систему правилами так, что искать источник проблемы станет очень трудно.

Если хотите сделать всё аккуратно, я обычно советую идти по шагам: сначала определить критические точки, потом включить мягкий лимит, затем собрать логи 2–3 дня, после этого ужесточить параметры. И да, на тестовом стенде это проверять обязательно. Особенно если у вас продакшен на PHP 8.3, а staging ещё на PHP 8.1 — поведение может немного отличаться.

Как 429 вписывается в комплексную защиту сайта

429 — это часть общей архитектуры, а не отдельная кнопка “защитить сайт”. Я всегда смотрю на неё вместе с обновлениями, SSL, заголовками безопасности, 2FA, антиспамом, мониторингом и резервным копированием. Если вы не делаете базовую защиту сайта от взлома, rate limiting поможет только частично.

Очень полезно сочетать 429 с нормальной архитектурой инфраструктуры: CDN, обратный прокси, кеширование, Redis, разгрузка тяжёлых запросов. Если сайт уже еле живёт, одними лимитами проблему не закрыть. Тут нужен и технический аудит, и доработка кода, и иногда перенос на более подходящий хостинг. Если хотите, на webfull.ru я обычно делаю такие задачи в рамках доработки сайта или поддержки Bitrix, а для WordPress — через поддержку WordPress.

И ещё один практический момент. Если у вас на сайте уже есть HTTPS и HSTS, заголовки безопасности и продуманный failover, то 429 становится логичным звеном цепочки. Без этого он выглядит как случайная заплатка. А с этим — как нормальная инженерная мера.

На деле 429 Too Many Requests — это один из тех инструментов, который либо реально помогает, либо начинает мешать, если настроен наугад. Я обычно рекомендую не бояться его, но и не включать “на весь сайт одним махом”. Начните с чувствительных точек, посмотрите логи, проверьте влияние на UX и только потом ужесточайте правила. Тогда защита будет работать тихо, без сюрпризов и без лишних жалоб от пользователей.