Лимиты в NGINX: как защитить сервер от перегрузок и DoS‑атак

1. Сколько соединений может обработать один воркер

В NGINX каждый воркер‑процесс способен обслуживать определённое число одновременных соединений. Это задаётся директивой:

worker_connections 1024;

• Здесь учитываются все дескрипторы, включая клиентские соединения и прокси‑сессии к бэкендам.

• По умолчанию NGINX использует 768 соединений, но для серьёзных нагрузок лучше поднять до 1024+, не забывая про лимит открытых файлов в ОС (ulimit -n).

Расчёт максимального числа клиентов:

max_clients=worker_processes×worker_connections\text{max\_clients} = \text{worker\_processes} \times \text{worker\_connections}max_clients=worker_processes×worker_connections

Пример:

worker_processes = 4
worker_connections = 1024
max_clients = 4 × 1024 = 4096

То есть сервер может обслуживать до 4096 соединений одновременно (минус коннекты к upstream).

Пример конфигурации events.conf:

events {
    worker_connections 1024;  # максимум соединений на воркер
    # accept_mutex on;        # равномерное принятие коннектов (опционально)
}

2. Ограничение одновременных соединений: limit_conn

Чтобы защитить сервер от «дружелюбной» перегрузки, например, когда бот‑краулер открывает сотни соединений, используется ngx_http_limit_conn_module:

• limit_conn_zone — создаёт область памяти для хранения текущих соединений (обычно по IP).

• limit_conn — задаёт лимит одновременных соединений.

Пример настройки:

http {
    limit_conn_zone $binary_remote_addr zone=perip:10m;

    server {
        location / {
            limit_conn perip 10;         # не больше 10 соединений на IP
            limit_conn_status 429;       # выдаём 429 вместо дефолтного 503
            limit_conn_log_level info;   # уровень логирования при отказе
        }
    }
}

• 10m зоны на 64-битной платформе хранят примерно 16 000 уникальных IP.

• При переполнении NGINX сразу отдаёт ошибку (503/429).

Dry-run и логирование:

limit_conn_dry_run on;       # не блокирует, а только логирует
limit_conn_log_level notice;

Так можно тестировать лимиты, не блокируя клиентов.

3. Ограничение скорости запросов: limit_req

Если нужно контролировать частоту запросов, применяется ngx_http_limit_req_module.

Механизм основан на «leaky bucket» — запросы попадают в бакет и «вытекают» с заданной скоростью.

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

    server {
        location /login {
            limit_req zone=login burst=10 nodelay;
            limit_req_status 429;
            limit_req_log_level warn;
        }
    }
}

• burst — пиковое количество запросов, которое сервер пропускает сверх лимита.

• nodelay — отказ сразу при превышении лимита, без задержки.

• Без nodelay лишние запросы будут ожидать своей очереди.

4. Где хранится состояние

В NGINX есть shared memory zones — специальная общая память для лимитов:

• Slab-пул разбивает память на одинаковые блоки для быстрого выделения и освобождения.

• Для limit_conn используется хеш-таблица или сбалансированное дерево по IP.

• Для limit_req — красно‑чёрное дерево + очередь «протекающего ведра».

• Доступ защищён встроенным мьютексом — нет гонок даже при сотнях воркеров.

Механизм работы:

1. При новом запросе NGINX берёт ключ (IP), ищет запись в зоне.

2. Если записи нет — создаёт новую.

3. Проверяет счётчики и решает, пропускать запрос или отказать.

5. Реакция сервера при превышении лимита

• По умолчанию:

  • limit_conn → 503 Service Unavailable

  • limit_req → 503 Service Unavailable

• Лучше отдавать 429 Too Many Requests, чтобы клиенты понимали причину.

Пример логов

2025/04/04 13:45:12 [warn] 12345#0: *67890 limiting requests, excess: 5 by zone "login"
2025/04/04 13:45:12 [info] 12345#0: *67890 a client request is temporarily blocked by zone "perip"

6. Практические нюансы

• Размер зоны: 1 MB ≈ 16 000 записей; для 100 000 IP/сутки потребуется 10–12 MB.

• burst vs delay: для login/API можно применять разные подходы:

  • login: burst=1; nodelay

  • API: burst=10; delay 10

• Разные зоны для разных endpoint: чтобы лимиты не конфликтовали.

• Исключения: через map или geo можно исключить внутренние IP:

map $remote_addr $limit {
    10.0.0.0/8         "";
    default            $binary_remote_addr;
}

limit_req_zone $limit zone=api:20m rate=20r/s;

7. Сторонние модули и NGINX Plus

7.1 ngx_brotli — снижение трафика

• Brotli‑сжатие уменьшает объём передаваемых данных, разгружая лимиты по трафику:

http {
    brotli on;
    brotli_comp_level 6;
    brotli_types text/html text/css application/javascript;
}

7.2 ngx_http_limit_traffic_ratefilter_module — лимит по байтам

• Позволяет ограничить скорость передачи, например 100 KB/s на IP:

http {
    limit_traffic_rate_zone $binary_remote_addr zone=bytetraf:10m;

    server {
        location /downloads/ {
            limit_traffic_rate zone=bytetraf rate=100k;
        }
    }
}

7.3 NGINX Plus — расширенные возможности

• Синхронизация зон между нодами — zone_sync.

• Адаптивное ограничение: скорость передачи зависит от метрик, например:

map $upstream_response_time $dyn_rate {
    "~^[0-9]\.[0-1]" 200k;   # быстрые ответы — больше скорости
    default           50k;    # медленные — ограничение
}

server {
    location /stream/ {
        limit_rate $dyn_rate;
    }
}