# limit_req і limit_conn у Nginx: захист від напливу запитів

> Як налаштувати limit_req і limit_conn у Nginx: зони пам'яті, burst, nodelay і коди відповіді 429 та 503 при перевищенні лімітів.

## Навіщо обмежувати частоту запитів у Nginx

Модулі limit\_req і limit\_conn захищають сервер від перевантаження: від ботів, які перебирають форми, від парсерів, які сканують каталог, і від звичайного сплеску трафіку після рекламної розсилки. Без лімітів один клієнт здатний зайняти всі воркери PHP-FPM і покласти сайт для інших відвідувачів.

limit\_req обмежує частоту запитів за секунду з однієї IP-адреси. limit\_conn обмежує кількість одночасних з'єднань. Це різні механізми, і часто їх застосовують разом.

## Як налаштувати limit\_req

Зону пам'яті для ліміту оголошують один раз у секції `http {}`, а застосовують — у потрібному `location`:

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

server {
    location /login.php {
        limit_req zone=perip burst=10 nodelay;
    }
}
```

Зона `perip` розміром 10 МБ зберігає приблизно 160 тисяч унікальних IP-адрес. Параметр `rate=5r/s` означає 5 запитів за секунду з однієї адреси в середньому.

## Параметри limit\_req: що вони важать

| Параметр | Значення | Ефект |
| --- | --- | --- |
| rate | 5r/s, 10r/m | Середня частота запитів з однієї адреси |
| burst | кількість запитів | Скільки запитів понад rate поставити в чергу |
| nodelay | прапорець | Не затримувати запити з burst, а одразу пропускати |
| limit\_req\_status | код відповіді | Який код повернути при перевищенні, за замовчуванням 503 |

Без `nodelay` Nginx притримує зайві запити і віддає їх із затримкою, вирівнюючи потік. Із `nodelay` запити з burst обробляються одразу, а зайві — скидаються кодом 503.

## Як налаштувати limit\_conn

limit\_conn обмежує кількість одночасних з'єднань з однієї адреси — корисно проти завантаження великих файлів у кілька потоків або повільних ботів:

```
http {
    limit_conn_zone $binary_remote_addr zone=connperip:10m;
}

server {
    location /download/ {
        limit_conn connperip 3;
    }
}
```

Це налаштування дозволяє не більше трьох одночасних з'єднань з однієї IP-адреси до каталогу `/download/`.

## Як повернути зрозумілий код помилки

За замовчуванням Nginx віддає код 503 Service Unavailable при перевищенні ліміту. Для API логічніший код 429 Too Many Requests:

```
limit_req_status 429;
limit_conn_status 429;
```

Додатково налаштуйте кастомну сторінку помилки через `error_page 429 /rate-limit.html;`, щоб відвідувач побачив зрозуміле повідомлення, а не голий код відповіді.

## Де застосовувати ліміти, а де ні

Розумно обмежувати не весь сайт, а точкові адреси:

- форми входу та реєстрації — від перебору паролів
- пошук по сайту — від парсерів, які навантажують базу даних
- API — від клієнтів, які надсилають запити частіше за домовлене
- статику та головну сторінку краще не чіпати: там ліміти частіше заважають, ніж допомагають

## Підсумок

Чек-лист для впровадження лімітів:

- оголосити зону пам'яті limit\_req\_zone і limit\_conn\_zone у http {}
- застосувати ліміт точково — до форм входу, пошуку та API
- підібрати rate і burst під реальний трафік, а не навмання
- повернути код 429 замість 503 там, де ліміт захищає API

Ліміти варто поєднувати із загальним захистом сервера: подивіться статтю про [загальне зміцнення безпеки Nginx](https://www.zevshost.net/uk/kb/nginx-security-hardening/) і про [діагностику помилок 502 та 504](https://www.zevshost.net/uk/kb/nginx-502-504-diagnostika/), які часто виникають через перевантаження бекенду, а не через сам Nginx.

---

Джерело: https://www.zevshost.net/uk/kb/nginx-limit-req-limit-conn/