Защита от ботов в Nginx: пять ошибок настройки

Лимит в Nginx способен отрезать часть автоматического трафика, но одна неудачная настройка может заодно заблокировать покупателей за общим IP или оставить сайт открытым для ботов, меняющих адреса. Разберём типичные ошибки в rate limiting для Nginx OSS 1.24.x: что именно проверять, как выбирать порог и где защита перестаёт работать. Числа ниже — стартовые значения для теста, не готовые универсальные лимиты.

Ошибка 1. Считать User-Agent доказательством

Строка User-Agent — текст, который клиент отправляет сам. Скрипту несложно представиться браузером, а реальный робот может использовать необычную строку. Поэтому блокировка по словам вроде bot или crawler не подтверждает, кто пришёл на сайт.

Если вы закрываете конкретную тяжёлую страницу от известных нежелательных клиентов, фильтр по User-Agent может быть одним слоем защиты. Но не используйте его как единственную проверку доступа или как основание считать запрос безопасным. Для подтверждения поискового робота нужны проверки, специфичные для этого робота; правила зависят от его документации.

Ошибка 2. Включить лимит и забыть про burst

Директива limit_req ограничивает частоту запросов по ключу. Часто ключом становится адрес клиента, а состояние лимитера хранится в общей зоне памяти, созданной через limit_req_zone. Запросы сверх заданной скорости Nginx задерживает или отклоняет — в зависимости от параметров.

Если поставить низкий лимит без запаса на короткие всплески, сайт может отвечать 503 даже при обычном поведении посетителя: браузер параллельно загружает страницу, изображения и скрипты. Параметр burst позволяет принять временный всплеск сверх средней скорости. С nodelay запросы в пределах этого запаса проходят без ожидания, но сам запас не исчезает: если клиенты продолжают превышать скорость, лишние запросы отклоняются.

Для Nginx OSS 1.24.x директиву зоны размещают в контексте http, а лимит применяют в нужном server или location:

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

    server {
        location /api/ {
            limit_req zone=per_ip burst=20 nodelay;
            limit_req_status 429;
        }
    }
}

Это пример синтаксиса, а не рекомендация выставлять именно пять запросов в секунду и запас в двадцать. Для API с долгими операциями и для статических файлов нужны разные правила. Статус 429 удобен для обозначения ограничения частоты; отдельно проверьте, что приложение и мониторинг его правильно обрабатывают.

Ошибка 3. Считать общий IP адресом одного человека

Один IP может принадлежать офису, мобильному оператору или прокси, за которым сидят сотни пользователей. Лимит на каждый IP тогда складывает их запросы в одну корзину. Результат — случайные отказы для обычных посетителей, особенно заметные на страницах входа, поиске и API.

Обратная проблема возникает за балансировщиком или CDN: Nginx видит адрес промежуточного сервера и применяет лимит ко всему потоку как к одному клиенту. Адрес из заголовка X-Forwarded-For нельзя просто считать достоверным: клиент может подставить его сам, если инфраструктура не настроена правильно. Модуль Real IP должен доверять только известным адресам прокси; точную конфигурацию выбирают по схеме сети и документации вашей версии Nginx.

Ошибка 4. Ограничивать весь сайт одним правилом

Главная страница, каталог, авторизация и API расходуют разные ресурсы. Одинаковый лимит для всех путей создаёт две неприятности: дешёвые запросы могут занимать доступный запас, а чувствительный endpoint останется слишком щедро открытым.

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

Ошибка 5. Не проверить поведение и логи

Настройка может синтаксически пройти проверку, но работать не там, где вы ожидали: например, из-за наследования директив в конфигурации. Перед перезагрузкой проверьте конфигурацию командой nginx -t. Затем тестируйте конкретный endpoint с нескольких адресов и смотрите, какие ответы получает обычный клиент при типичной нагрузке.

Для диагностики включите уровень логирования ограниченных запросов через limit_req_log_level и сопоставляйте записи Nginx с кодами ответов и метриками приложения. Не объявляйте блокировку успешной только потому, что в логах появились отказы: проверьте, что запросы действительно не доходят до дорогой операции и что доля отказов для людей не выросла.

Хороший лимит защищает конкретный ресурс от измеренного избытка запросов. Если вы не знаете, какой путь перегружен и сколько запросов выдерживает приложение, лимит превращается в угадывание.

Когда какой подход выбирать

• Простой общий сайт: начните с ограниченного правила на тяжёлые маршруты, а не на весь сервер. Сравните частоту запросов с обычным трафиком.
• Сайт за CDN или балансировщиком: сначала настройте корректное определение адреса клиента и перечень доверенных прокси. Иначе лимитер может считать всех одним посетителем.
• API для разных клиентов: IP-лимита может не хватить. Сопоставляйте его с ограничениями на уровне приложения, где доступны учётная запись или ключ клиента.

Слово «бот» не обозначает один тип нагрузки. Вредный скрипт может распределять запросы по адресам, а легитимный робот — обращаться к сайту чаще, чем выдерживает база. Разделяйте защиту от всплеска, управление доступом и проверку личности клиента.

Где подход ломается

Много адресов. Лимит по IP теряет эффективность, если источник распределяет запросы по множеству адресов. Общие адреса. Один агрессивный клиент способен исчерпать лимит, общий для пользователей за NAT. Несколько серверов. Локальная зона памяти Nginx не становится общей базой между независимыми узлами: каждый сервер ведёт своё состояние. Длинные операции. Ограничение частоты запросов не задаёт допустимое время выполнения и не решает проблему медленного обработчика.

Rate limiting — ограничение частоты запросов за заданный промежуток или по заданной скорости. В Nginx это механизм контроля потока, а не проверка того, человек перед вами или программа.

Что проверить дальше

Снимите базовые метрики до изменения: запросы по маршрутам, коды 429 и 503, задержку ответа и нагрузку на приложение. Затем включайте лимит на одном маршруте, наблюдайте за отказами и корректируйте скорость и burst по реальному распределению запросов. Если трафик проходит через прокси, отдельно проверьте адрес клиента и список доверенных узлов. Для распределённой защиты или распознавания сложных атак одного Nginx rate limiting может быть недостаточно.