Ограничение запросов и скорости в Nginx

Логотип Nginx

Nginx поддерживает ограничение количества запросов (limit_req), одновременных соединений (limit_conn) и скорость передачи (limit_rate). Настройте зоны limit_req_zone и limit_conn_zone, примените директивы в нужных location/серверах, и комбинируйте двухступенчатое ограничение (burst + delay) для гибкости. Для серьёзной защиты используйте CDN или балансировщик нагрузки перед веб‑сервером.

Быстрые ссылки

Как включить ограничение запросов в Nginx
Двухступенчатое ограничение
Ограничение пропускной способности (bandwidth)

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

Важно: rate limiting не всегда спасёт при массовых всплесках трафика. Если сервер под угрозой, используйте фронтовый CDN для всего сайта или как минимум настройте HAProxy/балансировщик для распределения нагрузки.

Как включить ограничение запросов в Nginx

Сначала нужно объявить «зону» для ограничения. Можно создать несколько зон и назначать их на разные location. Добавьте строку в контекст http или server:

limit_req_zone $binary_remote_addr zone=foo:10m rate=5r/s;

Объяснение одной строкой: limit_req_zone создаёт зону, использующую IP клиента ($binary_remote_addr) как идентификатор, резервирует память (zone=foo:10m) и задаёт скорость (rate=5r/s).

Пояснения и локализация терминов:

$binary_remote_addr — IP клиента в бинарном виде. Если вы за обратным прокси, используйте корректный заголовок реального IP (см. раздел о обратных прокси ниже).
zone=foo:10m — имя зоны и объём памяти (10 мегабайт).
rate=5r/s — разрешено 5 запросов в секунду (альтернативно 30r/m — 30 запросов в минуту).

Примечание по объёму памяти: 10m обычно достаточно для большого количества записей (в исходном описании упоминается примерно 160000 записей), но точная потребность зависит от вашей нагрузки.

После объявления зоны примените её в нужных блоках location или server:

location /api/ {
    limit_req zone=foo burst=10 nodelay;
    # обработка запросов
}

Ключевые параметры:

limit_req zone=... — связывает location с зоной.
burst — позволяет клиенту сделать дополнительный «всплеск» запросов сверх нормы.
nodelay — убирает внутреннюю очередь задержки, пропуская burst‑запросы мгновенно.

Как это работает: очередь «тикaет» каждые 100 мс. Без nodelay некоторые запросы могут задерживаться по очереди, что делает сайт медленнее для пользователя. С nodelay burst‑запросы проходят сразу, затем последующие ограничиваются установленной скоростью.

Пример сценария: если rate=5r/s и burst=10 с nodelay, то 10 запросов сразу пройдут, следующие запросы будут пущены со скоростью 5 в секунду. Если клиент отправит 6 дополнительных запросов, 5 пройдут, а 6‑й будет отклонён (429).

Двухступенчатое ограничение

Иногда нужно, чтобы первые N запросов шли без задержки, а дальше — с небольшой паузой. Для этого задают delay на limit_req:

limit_req zone=ip burst=10 delay=5;

В этом примере первые 5 запросов проходят мгновенно. Остальные попадают в очередь с ограничением скорости, и когда очередь заполнится, применяется обычный rate.

Когда использовать: полезно для API с короткими всплесками активности от легитимных пользователей — например, сохранение формы, где первые несколько действий должны быть быстрыми.

Ограничение пропускной способности (bandwidth)

Ограничение числа запросов не ограничивает объём скачиваемых данных. Для управления скоростью передачи используйте limit_rate и limit_rate_after:

limit_rate 100k;
limit_rate_after 1m;

Эта конфигурация ограничит скорость до 100 КБит/с (или обычно 100k — в Nginx единицы: байты/с и суффиксы k/K/M) после того, как соединение передало 1 мегабайт.

Учтите: limit_rate действует на каждое соединение. Пользователь может открыть несколько соединений и обойти ограничение. Чтобы ограничить соединения, используйте limit_conn_zone и limit_conn:

limit_conn_zone $binary_remote_address zone=bar:10m;
limit_req_zone $binary_remote_addr zone=foo:10m rate=5r/s;

server {
    limit_conn bar 5;

    location /static/ {
        limit_conn bar 1;
        limit_rate 100k;
        limit_rate_after 1m;
    }
}

Идея: глобально разрешаем несколько соединений на IP (например, 5), но для загрузок /static/ ограничиваем по одному соединению и таргетируем скорость.

Практические советы по развертыванию

Логирование: отслеживайте 429‑ые ответы (Too Many Requests). Они показывают, когда вы ограничиваете реальных пользователей.
Тестирование: прогоняйте нагрузочные тесты, чтобы убедиться, что лимиты не мешают легитимному трафику.
Заголовки реального IP: если вы за CDN/обратным прокси, настройте real_ip_header и set_real_ip_from или используйте переменные типа $http_x_forwarded_for, чтобы лимиты применялись к реальным клиентам.
Модуль realip: убедитесь, что ngx_http_realip_module включён, если вы обрабатываете X-Forwarded‑For.

Когда ограничение не сработает или даст ложные срабатывания

За CDN/балансировщиком без передачи реального IP — все запросы будут от IP прокси и лимит применится некорректно.
Атаки с большого пула распределённых IP (botnet) — IP‑ориентированные лимиты мало помогут.
Клиент открывает много параллельных соединений — limit_rate на одно соединение не позволит ограничить суммарную скорость без limit_conn.

Альтернативные подходы

Фронтовый CDN (Cloudflare, Fastly) для блокировки и фильтрации на уровне сети.
Балансировщик нагрузки (HAProxy) для распределения и rate limiting на уровне TCP/сессии.
WAF (ModSecurity, коммерческие решения) для сложных правил и сигнатур.
Fail2ban для блокировки подозрительных IP на уровне хоста.

Чек‑лист по ролям

Администратор:

Создать и протестировать зоны limit_req_zone и limit_conn_zone.
Включить логирование 429 и мониторинг.
Настроить корректную обработку реального IP от прокси.

DevOps:

Добавить конфигурацию в систему конфигов (Ansible/Helm) и прогнать тесты.
Настроить алерты при росте количества 429.

Разработчик API:

Проверить, что клиент корректно обрабатывает 429 и делает бэк‑офф.
Документировать лимиты для интеграторов.

Примеры конфигураций — шпаргалка

Простая зона и location:

limit_req_zone $binary_remote_addr zone=foo:10m rate=5r/s;

server {
    location /api/ {
        limit_req zone=foo burst=10 nodelay;
        proxy_pass http://backend;
    }
}

Двухступенчатое ограничение:

limit_req_zone $binary_remote_addr zone=ip:10m rate=10r/s;

location /submit/ {
    limit_req zone=ip burst=20 delay=10;
}

Ограничение соединений + скорость:

limit_conn_zone $binary_remote_address zone=bar:10m;

server {
    limit_conn bar 10;

    location /downloads/ {
        limit_conn bar 1;
        limit_rate 100k;
        limit_rate_after 1m;
    }
}

Критерии приёмки

429 ответы логируются и видны в метриках.
Пиковые легитимные сценарии пользователей не приводят к неожиданным 429.
При нагрузке лимиты защищают backend от деградации.

Безопасность и мониторинг

Разрешайте фиксированный набор доверенных прокси через set_real_ip_from.
Мониторьте рост количества 429 и аномалии в IP‑географии.
Регулярно анализируйте логи: массовые 429 от множества IP могут указывать на DDoS.

Факт‑бокс

Пример из конфигурации: zone=foo:10m — 10 мегабайт оперативной памяти для хранения состояния зоны. В практике это покрывает очень большое число клиентов; точные потребности зависят от нагрузки.

Когда стоит сразу ставить CDN или балансировщик

Если ожидаются большие всплески трафика.
Если вы не контролируете исходный IP (за внешним прокси).
Если нужны глобальные правила блокировки и кеширования.

Важно

Rate limiting — один из инструментов защиты и контроля. Он эффективен в паре с кешированием, CDN, WAF и мониторингом. Продумывайте UX: возвращайте понятные ответы клиентам и документируйте лимиты.

Краткое резюме

Ограничение запросов в Nginx реализуется через зоны limit_req_zone и директиву limit_req. Для контроля скорости передач используйте limit_rate, а для контроля соединений — limit_conn_zone и limit_conn. Тестируйте и мониторьте, применяйте CDN/балансировку для дополнительной защиты.