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

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

В этом руководстве вы настроите ограничение частоты запросов в Nginx, безопасно проверите его работу и включите защиту на сервере Ubuntu.

Как работает ограничение частоты запросов в Nginx?

Nginx использует модуль limit_req для отслеживания входящих запросов, обычно по IP-адресу клиента.

Например, можно установить средний лимит в пять запросов в секунду, разрешив при этом кратковременные всплески трафика. Запросы, превышающие допустимый размер всплеска, будут отклоняться.

Это помогает предотвратить перегрузку приложения чрезмерным числом запросов.

Примечание: Ограничение частоты запросов помогает ослабить некоторые HTTP-флуд-атаки на уровне L7. Оно не может остановить масштабные сетевые DDoS-атаки, которые перегружают ваше подключение.

Предварительные требования

Вам понадобятся сервер Ubuntu с установленным Nginx, доступ по SSH с правами sudo и существующий сайт или приложение.

Перед внесением изменений создайте резервную копию текущей конфигурации сайта.

Шаг 1. Определите зону ограничения частоты запросов

Подключитесь к серверу по SSH.

Если Nginx установлен на Ubuntu стандартным способом, создайте новый файл конфигурации:

sudo nano /etc/nginx/conf.d/rate-limit.conf

Добавьте:

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

Эта конфигурация отслеживает запросы по IP-адресу клиента, выделяет 10 МБ для данных отслеживания и устанавливает средний лимит в пять запросов в секунду для каждого IP-адреса.

Директива limit_req_zone должна находиться в контексте http Nginx. В стандартной конфигурации Ubuntu файлы из conf.d подключаются именно там.

Сохраните файл.

Шаг 2. Включите ограничение частоты запросов для сайта

Откройте существующий файл конфигурации сайта в Nginx:

sudo nano /etc/nginx/sites-available/app.example.com

Замените имя файла на имя вашего файла конфигурации.

Для HTTP-приложения, работающего на порту 3000, защищённая конечная точка API может выглядеть так:

location /api/ {
    limit_req zone=perip burst=10 nodelay;
    limit_req_status 429;
    limit_req_dry_run on;

    proxy_pass http://127.0.0.1:3000;
}

Вот что делают основные директивы:

• limit_req: применяет ранее заданный лимит.
• burst=10: допускает кратковременное превышение лимита.
• nodelay: немедленно обрабатывает запросы в пределах допустимого всплеска.
• limit_req_status 429: возвращает код HTTP 429 при отклонении запросов.
• limit_req_dry_run on: регистрирует запросы сверх лимита, не блокируя их.

Важно: Добавьте эти директивы ограничения частоты запросов в существующий подходящий блок location. Не создавайте дублирующие блоки location и не заменяйте существующую конфигурацию бэкенда.

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

Шаг 3. Проверьте конфигурацию Nginx

Проверьте конфигурацию:

sudo nginx -t

Если проверка прошла успешно, перезагрузите конфигурацию Nginx:

sudo systemctl reload nginx

Если возникла ошибка, исправьте её до перезагрузки конфигурации.

Шаг 4. Проверьте ограничение частоты запросов

Поскольку включён режим тестирования, запросы пока не будут отклоняться.

Отслеживайте журнал ошибок Nginx:

sudo tail -f /var/log/nginx/error.log

Из другого терминала отправьте небольшую серию тестовых запросов к конечной точке, которую вы контролируете:

for i in $(seq 1 15); do
  curl -s -o /dev/null -w "%{http_code}\n" \
  https://app.example.com/api/health
done

Замените URL на адрес работающей конечной точки вашего тестового приложения или приложения в промежуточной среде.

Если число запросов превысит лимит, Nginx должен записать в журнал ошибок сообщения, содержащие limiting requests, dry run.

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

Шаг 5. Включите ограничение частоты запросов

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

limit_req_dry_run on;

Снова проверьте конфигурацию и перезагрузите её в Nginx:

sudo nginx -t
sudo systemctl reload nginx

Теперь на запросы сверх лимита может возвращаться ответ HTTP 429 Too Many Requests.

Повторите контролируемую проверку и посмотрите коды ответов. Точные результаты зависят от времени поступления запросов и установленных лимитов.

Как отменить изменения

Если ограничение затрагивает обычных пользователей, восстановите:

limit_req_dry_run on;

Проверьте конфигурацию и перезагрузите её в Nginx. Это вернёт конфигурацию в режим мониторинга, при котором запросы не отклоняются.

Затем можно скорректировать лимиты с учётом реального трафика.

Важно: Nginx за Cloudflare или другим CDN

Если Nginx работает за обратным прокси-сервером, вместо IP-адреса исходного посетителя он может видеть IP-адрес прокси-сервера.

Если не исправить это перед применением лимитов по IP-адресу, запросы разных пользователей могут учитываться вместе.

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

Никогда не доверяйте заголовкам с IP-адресами, которые посетители могут указывать произвольно.

Заменяет ли ограничение частоты запросов в Nginx защиту от DDoS-атак?

Нет. Nginx может ограничивать чрезмерное число HTTP-запросов к вашему приложению, но не может отфильтровать трафик, который уже перегрузил сетевой канал сервера.

Для более полной защиты сочетайте меры на уровне приложения с противодействием атакам на уровне хостинга.

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

Заключение

Встроенное ограничение частоты запросов в Nginx помогает сократить нежелательный HTTP-трафик без установки дополнительного ПО.

Настройте лимит запросов, проверьте его в режиме тестирования и включайте применение ограничения только после изучения результатов.

Для комплексной защиты сервера сочетайте ограничение частоты запросов с подходящими средствами противодействия DDoS-атакам на вышестоящем уровне.