#Симптом и границы применимости
При включении защиты от частых запросов обычные пользователи получают 429/503 либо задержки, особенно за общей сетью офиса или мобильного оператора. Причину нужно искать в ключе учёта, лимите и порядке реального IP.
Эта инструкция относится к конкретному сайту в панели управления хостингом, когда его обслуживают Nginx, Apache, PHP-FPM или их сочетание. Названия разделов и доступность SSH зависят от установленной панели и прав пользователя; шаги, которых нет в вашем интерфейсе, выполняет администратор сервера.
#Возможные причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Все клиенты считаются одним IPРеальный адрес за CDN не определяется | В логах совпадает адрес у разных посетителей | Настроить доверенный realip до оценки лимита |
| Порог не учитывает обычные всплескиОдна страница запрашивает множество CSS/JS/API | После открытия страницы быстро появляются ошибки | Отрегулировать зону, burst и область действия |
| Несколько ограничителейПанель/WAF/CDN и Nginx ограничивают одни запросы | Ошибки идут с разных уровней | Найти слой отказа по журналам |
#Пошаговая диагностика и исправление
- Отличите ограничение от неисправностиПроверьте точный HTTP-код, время ошибки и путь запроса в F12 → «Сеть». В Nginx ограничитель по умолчанию может возвращать 503, а не только 429; не судите по одному коду.
- Выясните, какой слой отклоняет запросСопоставьте CDN, WAF, панель сайта и журналы Nginx. Если отказ происходит перед сервером, изменение limit_req на нём не поможет. Запишите конкретное правило, адрес клиента и несколько времён срабатывания.
- Проверьте ключ учётаПосмотрите, что указано в limit_req_zone: для пользователей за прокси ключ $binary_remote_addr корректен только после безопасной настройки настоящего IP. Нельзя бездумно доверять всему X-Forwarded-For.
- Оцените обычную нагрузку без стресс-тестаОткройте одну страницу, измерьте число и частоту запросов через F12, посмотрите, не идут ли фоновые запросы интерфейса чаще заданного порога. Не проводите массовые запросы к рабочему сайту.
- Уточните значения rate, burst и область действияВ конфигурации проверьте нужную зону, скорость и запас burst. Отдельные обращения к /api/ и /login/ могут требовать разных правил. Для сайта за корпоративным NAT избегайте порогов, срабатывающих на всю организацию.
- Испытайте правило без блокировкиЕсли версия Nginx поддерживает limit_req_dry_run, используйте её на нужном участке: ограничения учитываются, но запросы не блокируются. Применяйте только после резервной копии и проверки синтаксиса; не выключайте все защитные ограничения.Linux · Терминал (Bash)КомандаНужен sudoПроверка конфигурации из SSH, права администратора. Не включает тестовый режим сама по себе.
sudo nginx -t
- Проверьте защиту и доступностьПосле адресной корректировки повторите обычное открытие сайта и вход в аккаунт. Убедитесь, что защитные ограничения для явно чрезмерных запросов сохранились, а реальные посетители не получают ложных блокировок. При ухудшении восстановите предыдущее правило.
#Проверка результата
Обычное использование сайта не приводит к необоснованным 429/503, а защитные правила продолжают действовать для подтверждённой злоупотребляющей нагрузки.
#Если проблема осталась
Если за одним IP находятся тысячи пользователей, разделите лимиты по эндпоинтам и проверьте корректную обработку адресов за прокси вместо полного отключения защиты.
#Безопасный откат
Если после изменения ошибка усилилась, верните сохранённое значение только изменённого параметра и повторно проверьте конфигурацию используемого веб-сервера до применения. Не возвращайте всю базу или весь сервер из резервной копии, если достаточно откатить одну настройку. При отсутствии доступа к нужному уровню обратитесь к администратору с точными временем, адресом, кодом ответа и обезличенными фрагментами журналов.