Nginx — при ограничении запросов блокируются обычные пользователи

#Симптом и границы применимости

После включения limit_req легитимные посетители видят ошибки или задержки, хотя атаки нет. Стандартный ответ ограничителя Nginx — 503, если администратор не задавал limit_req_status (например, 429); сначала подтвердите срабатывание именно limit_req, а не другой защиты.

#Возможные причины и как их отличить

#Пошаговая диагностика и исправление

1. Зафиксируйте ответ и время срабатыванияОткройте в браузере средства разработчика → «Сеть» и обновите обычную страницу. Запишите коды нескольких запросов, не создавая нагрузки. Если указан 429 либо 503, это ещё не доказывает limit_req: посмотрите ошибку конкретного запроса в серверном журнале.
2. Запуск на клиенте

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Запуск на клиенте. Не запускайте циклы запросов без разрешения и контроля нагрузки.

   curl -I https://example.com/

1. Найдите источник ограниченияПодключитесь к серверу по SSH и проверьте limit_req_zone, limit_req, limit_req_status, limit_req_dry_run и реальные server/location. Проверьте дополнительные механизмы: WAF, fail2ban, настройки CDN. Одна директива limit_req_zone только создаёт зону и сама по себе запросы не ограничивает.
2. Вывод только для администратора

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

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

   sudo nginx -T 2>&1 | grep -nE "limit_req|real_ip_|set_real_ip_from|server_name|location "

1. Найдите сообщения об ограниченииПосмотрите error_log нужного виртуального хоста в момент единичной ошибки: для limit_req характерны сообщения limiting requests. Если система пишет deny by rule или бан в брандмауэре, исследуйте другой слой защиты.
2. Путь журнала примерный, уточните error_log активного сервера

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Путь журнала примерный, уточните error_log активного сервера.

   sudo tail -n 100 /var/log/nginx/error.log

1. Проверьте правильность IP клиентаЕсли за CDN $remote_addr один для всех посетителей, сначала настройте реальные адреса только для доверенных прокси. Не ставьте set_real_ip_from 0.0.0.0/0. Значение $binary_remote_addr у ограничителя должно быть осмысленным после правильной обработки IP.

1. Измерьте поведение без блокировокЕсли версия Nginx поддерживает limit_req_dry_run (начиная с 1.17.1), установите on только в нужном контексте на время наблюдения после резервной копии; ограничитель будет вести учёт, но не отказывать запросам. Это временно ослабляет защиту, поэтому применяйте лишь на контролируемом участке и с мониторингом атак.
2. Фрагмент конфигурационного файла, НЕ запускать в терминале

   NginxКопировать всёВыделить

   Фрагмент конфигурационного файла, НЕ запускать в терминале. Строка конфигурации Nginx, НЕ команда shell. Поддержка зависит от версии; в ранних версиях директива не существует.

   limit_req_dry_run on;

1. Точечно настройте rate и burst на основании измеренийВыберите адекватный допустимый поток для данного URI по реальным графикам. Не увеличивайте все лимиты без анализа. Для API входа и обычной статики могут потребоваться отдельные правила. Наличие nodelay не отменяет отсечения при превышении burst; оно меняет задержки внутри допуска.

1. Проверяйте конфигурацию и верните защитуПосле каждой правки выполняйте тест синтаксиса и безопасное перечитывание. По окончании диагностики выключите dry_run и проверьте, что грубый поток по-прежнему ограничивается, а обычные пользователи не получают ошибок.
2. Понадобится sudo

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   Понадобится sudo. Сохраните исходный файл и метрики до/после.

   sudo nginx -t && sudo systemctl reload nginx

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

#Как проверить результат

При обычной навигации нет необоснованных 429/503 и задержек; записи limiting requests согласуются с настоящим превышением. После возврата dry_run off защитный порог подтверждён безопасным испытанием.

#Если проблема не устранена

Если жалобы остались, проверьте WAF/CDN и блокировки по IP, чтобы не лечить проблему одного слоя настройками другого. При всплеске бот-трафика верните более строгие пороги.