Rate limiting — это механизм ограничения количества запросов к сайту за определенный промежуток времени. Его используют для защиты серверов от перегрузки, ботов и подозрительной активности. Когда поток обращений начинает расти слишком быстро, система просто ограничивает дальнейшие запросы от одного источника.
Такой подход помогает удерживать сайт в рабочем состоянии во время всплесков трафика и снижает нагрузку на приложение. Поэтому ограничения часто настраивают как базовую меру безопасности на уровне веб-сервера, CDN или прокси.
Что такое rate limiting на практике
Rate limiting — это механизм ограничения количества запросов от одного источника за определенный промежуток времени. Источником обычно выступает IP-адрес, иногда — пользовательский токен, cookie или API-ключ.
Простой пример: сервер разрешает 100 запросов в минуту с одного IP. Когда лимит превышен, дальнейшие обращения получают ответ 429 Too Many Requests или временную блокировку.
Такие правила часто включают на разных уровнях инфраструктуры:
-
на веб-сервере (например, Nginx или Apache);
-
в CDN-сервисах;
-
в reverse proxy;
-
на уровне API-шлюзов;
-
в WAF — веб-фаерволах.
Почему поисковые роботы легко попадают под ограничения
Поисковые системы индексируют сайт не так, как обычный пользователь. Их роботы сканируют страницы пачками: открывают несколько URL подряд, переходят по ссылкам, скачивают изображения и файлы.
Если сайт крупный, робот может сделать десятки запросов практически одновременно. Типичная картина выглядит так:
-
робот открывает HTML-страницу;
-
сразу загружает CSS и jаvascript;
-
скачивает изображения;
-
переходит на соседние страницы.
В итоге один визит может произвести 20–40 запросов. Если лимит установлен слишком низко, сервер начинает отвечать кодом 429. Робот воспринимает это как перегрузку сайта и снижает скорость обхода. Иногда он вообще прекращает индексировать новые страницы.
Особенно это заметно на больших проектах: интернет-магазинах, блогах с тысячами материалов, медиа-сайтах.
Как ограничения ломают рекламный трафик
С рекламой возникает другой сценарий. Пользователь кликает на объявление, открывает страницу и тут начинают работать рекламные скрипты, системы аналитики и пиксели отслеживания.
На одной странице могут обращаться к серверу:
-
скрипт веб-аналитики;
-
пиксель рекламной сети;
-
трекер конверсий;
-
система антифрода;
-
сторонние маркетинговые скрипты.
Каждый из них делает собственные запросы. Если несколько пользователей заходят одновременно, поток обращений резко увеличивается.
В таких условиях агрессивный rate limiting способен:
-
блокировать загрузку скриптов аналитики;
-
мешать отправке событий конверсий;
-
обрывать редиректы рекламных ссылок;
-
создавать ложные ошибки на лендингах.
В статистике это выглядит странно: клики есть, а часть визитов словно растворилась.
Самая частая ошибка — одинаковый лимит для всех
Многие администраторы настраивают ограничение по принципу «одно правило на весь сайт». Например: 50 запросов в минуту на IP.
Звучит логично, но реальная картина трафика намного разнообразнее. Разные типы клиентов ведут себя по-разному:
-
поисковые роботы могут открывать десятки страниц подряд;
-
мобильные сети иногда отправляют много пользователей через один IP;
-
браузеры делают параллельные запросы ресурсов страницы;
-
API-клиенты могут отправлять пакеты данных.
Если лимит слишком общий, он начинает задевать нормальных пользователей.
Практика: как настроить rate limiting без вреда для SEO
Хорошая настройка начинается с понимания того, кто обращается к сайту. Обычно выделяют несколько групп трафика.
1. Поисковые роботы
Их лучше обрабатывать отдельно. Для популярных ботов можно сделать более мягкие ограничения или отдельные правила.
Обычно проверяют:
-
User-Agent — строку идентификации робота;
-
диапазоны IP поисковых систем;
-
обратное DNS-разрешение.
В результате робот продолжает индексировать сайт, а защита от подозрительных клиентов остаётся активной.
2. API и внутренние сервисы
Если сайт использует API или внутренние микросервисы, им лучше назначить отдельные лимиты.
Часто применяют:
-
лимиты по API-ключу;
-
ограничения по токену авторизации;
-
более высокий порог запросов.
Это избавляет от ситуации, когда собственные сервисы начинают блокировать друг друга.
3. Обычные пользователи
Для посетителей сайта лимит обычно делают мягким. В большинстве проектов достаточно диапазона 100–300 запросов в минуту.
Такая величина позволяет спокойно загружать страницы и ресурсы, даже если пользователь быстро кликает по сайту.
Проверка перед запуском
Перед тем как включить ограничения на боевом сервере, стоит протестировать их на реальном трафике. Иначе сюрпризы появятся уже после запуска рекламных кампаний.
Полезно проверить несколько сценариев:
-
активный обход сайта поисковым роботом;
-
массовые переходы с рекламы;
-
быстрый серфинг по каталогу;
-
загрузку страниц с большим количеством ресурсов.
Отдельно смотрят на коды ответов сервера. Если в логах начинают появляться 429-ошибки для поисковых систем или пользователей, лимиты нужно пересматривать.
Мониторинг после настройки
Rate limiting редко настраивают один раз и навсегда. Поведение трафика меняется: запускаются новые рекламные кампании, появляются дополнительные сервисы, растёт число страниц.
Поэтому стоит регулярно проверять:
-
долю ответов 429 Too Many Requests;
-
ошибки загрузки скриптов;
-
скорость обхода сайта поисковыми системами;
-
данные аналитики и трекинга конверсий.
Если показатели внезапно меняются, одна из причин может скрываться именно в ограничениях запросов.
Когда ограничения действительно спасают сайт
Несмотря на все риски, rate limiting остаётся одним из самых полезных инструментов защиты. Он помогает пережить резкие всплески нагрузки, снижает эффект от скриптов-парсеров и ограничивает автоматические атаки.
Ключевая идея простая: ограничения должны учитывать поведение нормального трафика. Если правила создаются без этого понимания, под удар попадают поисковые роботы, рекламные системы и обычные пользователи.