Сегодня разберём, как ограничить скорость запросов к Node.js приложению через Nginx на Ubuntu 24.04. Почему это важно? Потому что любой публичный сервис рано или поздно сталкивается с наплывом клиентов, ботов, сканеров, а иногда и с DDoS-атаками. Если не поставить лимиты, даже самый оптимизированный Node.js сервер может превратиться в тыкву — или, точнее, в кучу 502 ошибок. В этой статье расскажу, как быстро и просто внедрить rate limiting через Nginx, чтобы ваш сервер не падал, а пользователи не страдали. Всё с примерами, схемами, реальными кейсами и даже парой лайфхаков для автоматизации.

Как это работает: лимитирование запросов через Nginx

Nginx — не только прокси и балансировщик, но и отличный инструмент для контроля нагрузки. Его модули ngx_http_limit_req_module и ngx_http_limit_conn_module позволяют ограничивать количество запросов и соединений с точностью до IP, URI, cookie и даже заголовков. Это работает как простая очередь: если клиент превышает лимит — его запросы либо замедляются, либо отбрасываются.

• limit_req — ограничивает скорость запросов (rate limiting).
• limit_conn — ограничивает количество одновременных соединений.

Всё это работает на уровне Nginx, то есть до того, как запрос попадёт в ваше Node.js приложение. Это значит — никакой лишней нагрузки на Node, никакого лишнего кода, всё быстро и прозрачно.

Быстрая настройка: шаг за шагом

Переходим к практике. Допустим, у вас уже есть Node.js приложение, которое крутится на порту 3000, а Nginx стоит фронтом. Вот как внедрить ограничение скорости запросов.

1. Убедитесь, что Nginx установлен
   
sudo apt update
sudo apt install nginx

2. Проверьте наличие нужных модулей
   Обычно limit_req и limit_conn уже встроены в стандартный пакет Nginx на Ubuntu 24.04. Проверить можно так:
   
nginx -V 2>&1 | grep --color -E 'limit_req|limit_conn'

   
   Если есть — отлично, идём дальше.
3. Настройте rate limiting в конфиге
   Открываем файл вашего сайта, например:
   
sudo nano /etc/nginx/sites-available/default

   
   Добавляем в http или server секцию:

   
   # Задаём зону лимита (10 МБ памяти, 10 запросов в секунду на IP)
   limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
   
   server {
       listen 80;
       server_name example.com;
   
       location / {
           proxy_pass http://localhost:3000;
           # Применяем лимит к каждому IP
           limit_req zone=api_limit burst=20 nodelay;
           # Можно добавить лимит соединений (опционально)
           limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
           limit_conn conn_limit 10;
       }
   }
       

   • burst — сколько запросов можно “выплеснуть” сверх лимита (например, если пользователь быстро кликает).
   • nodelay — если убрать, лишние запросы будут ставиться в очередь, а не сразу отбрасываться.
4. Перезапустите Nginx
   
sudo nginx -t
sudo systemctl reload nginx


Всё, теперь ваш Node.js сервер защищён от внезапных всплесков трафика и банальных ботов.

Примеры, схемы и практические советы

Кейс	Что происходит без лимита	Что происходит с лимитом	Рекомендация
Обычный пользователь	Может случайно зафлудить сервер (например, F5 в браузере)	Получит 503 или 429 ошибку, но сервер не ляжет	Лимит 5-10 r/s на IP — оптимально
Бот или сканер	Может за минуту сделать 10 000+ запросов, нагрузив Node.js	Большинство запросов будет отсеяно на уровне Nginx	Лимит 1-2 r/s, burst 5-10
API-клиент	Может случайно или намеренно превысить лимит	Чёткий контроль, можно возвращать кастомные ошибки	Лимитировать по ключу API (см. ниже)

Практический совет: Если у вас есть авторизация или API-ключи, можно лимитировать не только по IP, но и по значению ключа. Например:

limit_req_zone $http_x_api_key zone=api_key_limit:10m rate=5r/s;
...
location /api/ {
    limit_req zone=api_key_limit burst=10 nodelay;
}

Это спасает от ситуации, когда несколько клиентов сидят за одним NAT (например, офис или мобильный оператор).

Положительные и отрицательные кейсы

• Плюсы:
  • Сервер не падает от всплесков трафика
  • Node.js не тратит ресурсы на бесполезные запросы
  • Можно гибко настраивать лимиты для разных локаций, путей, ключей
  • Всё работает на уровне Nginx — быстро и прозрачно
• Минусы:
  • Легко “пережестить” и заблокировать реальных пользователей
  • IP-лимит не спасает от прокси и VPN (один бот — много IP)
  • Не учитывает сложные сценарии (например, разные лимиты для разных тарифов)

Альтернативные решения и утилиты

• Node.js middleware — например, express-rate-limit. Гибко, но нагрузка уже на Node, а не на фронте.
• Cloudflare Rate Limiting — если используете Cloudflare, можно лимитировать трафик ещё до сервера. Минус — не всегда бесплатен и не так гибок.
• fail2ban — умеет банить по логам Nginx, но это уже реакция на злоупотребление, а не превентивная мера.
• nginx-mod-http-geoip2 — можно лимитировать по странам, регионам, ASN.

Статистика и сравнение

Решение	Где работает	Производительность	Гибкость	Сложность
Nginx limit_req	На фронте, до Node.js	Очень высокая	Средняя	Низкая
Express-rate-limit	Внутри Node.js	Средняя	Высокая	Средняя
Cloudflare	На уровне CDN	Высокая	Средняя	Низкая
fail2ban	На сервере, по логам	Средняя	Низкая	Средняя

Интересные факты и нестандартные способы

• Лимит по User-Agent: Можно ограничивать не только по IP, но и по заголовкам. Например, если видите подозрительный User-Agent (curl, python-requests), можно сразу ставить лимит 1 r/s.
• Гибридные схемы: Используйте разные лимиты для разных путей. Например, /api/ — 5 r/s, /login — 1 r/s (защита от брутфорса), /static — без лимита.
• Автоматизация через Ansible: Можно генерировать конфиги Nginx с лимитами для каждого клиента или проекта автоматически.
• Мониторинг лимитов: Nginx пишет в логи, когда срабатывает лимит. Можно собирать эти события через ELK Stack и строить красивые графики.

Новые возможности и автоматизация

Ограничение скорости запросов через Nginx — это не только про защиту. Это ещё и про:

• Гибкое управление SLA для разных клиентов (например, VIP — больше лимит, free — меньше)
• Автоматическое масштабирование: если лимиты часто срабатывают — пора увеличивать ресурсы или переходить на VPS или выделенный сервер
• Интеграция с CI/CD: можно автоматически менять лимиты на тестовых и продакшн-окружениях
• Быстрое реагирование на атаки: меняем лимиты — и атака уже не страшна

Выводы и рекомендации

Ограничение скорости запросов через Nginx — это must-have для любого публичного Node.js приложения. Это просто, быстро, надёжно и не требует сложных доработок кода. Главное — не переборщить с лимитами и не забывать про реальные сценарии использования. Для большинства проектов хватит лимита 5-10 r/s на IP, но если у вас API с авторизацией — лимитируйте по ключу или токену. Не забывайте мониторить логи и быть готовыми к изменению лимитов на лету.

Если вы только начинаете строить свой сервис — смело ставьте Nginx с лимитами. Если уже работаете на shared-хостинге — самое время перейти на VPS или выделенный сервер и взять контроль в свои руки. А если хочется автоматизации — подключайте Ansible, Terraform и стройте инфраструктуру как код.

Официальная документация по теме:

• ngx_http_limit_req_module
• ngx_http_limit_conn_module

Пусть ваш Node.js сервер всегда будет бодр и свеж, а Nginx — надёжным щитом от любых напастей!

---

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

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