Хостинг пишет о нагрузке, хотя защита включена

Типичная ситуация: хостинг присылает письмо «высокая нагрузка», вы включаете защиту, а через день письмо приходит снова, и в нём десятки тысяч запросов, которых в журнале BotBan нет. Ошибки тут нет ни у кого, просто вы с хостингом смотрите на разные вещи.

Что считает хостинг

Статистика хостинга собирается на входе, на его веб-сервере. Туда попадает каждое обращение: за страницей, за картинкой, за manifest.json, за файлом, которого нет. Модуль BotBan работает внутри PHP. Он видит только те запросы, которые до PHP дошли, и не видит:

• статические файлы, которые веб-сервер отдаёт сам;
• страницы из кэша хостинга или кэширующего плагина, если кэш стоит перед PHP;
• запросы, которые хостинг сам отсёк своей защитой.

Последний пункт встречается чаще, чем кажется. Например, Beget при подозрении на атаку включает собственную проверку: посетителю без специальной cookie отдаётся крошечная страница со скриптом, который ставит cookie и перезагружает страницу. Робот без JavaScript получает эту заглушку снова и снова. До PHP он не доходит, в журнале BotBan его нет, а в статистике хостинга каждый его запрос учтён. При этом заглушка почти ничего не стоит серверу, и «нагрузка» в таком письме — это счётчик обращений, а не процессорное время.

Поэтому первый вопрос хостингу: какой именно показатель превышен и на каких запросах. Обычно ограничения вводят за процессорное время (у Beget это CP), и список самых «дорогих» страниц полезнее, чем список самых частых.

Что видит модуль

Даже из тех запросов, что дошли до PHP, в журнал попадает не каждый. Модуль помнит решение по посетителю столько секунд, сколько указано в настройке «Сколько помнить решение на сайте» (по умолчанию 60). Человек, открывший за минуту пять страниц, даёт одну запись; робот, стучащий раз в секунду с одного адреса, — одну запись в минуту, а не шестьдесят. Это сделано намеренно: иначе каждый запрос ждал бы ответа нашего сервера.

Про «самые активные адреса»

В списке адресов от хостинга сверху часто стоят адреса мобильных операторов: за одним таким адресом сидят сотни людей, и тысячи запросов в день с него — норма. Такие адреса мы не блокируем никогда, только проверяем браузер, когда есть другие поводы. Прежде чем жаловаться на адрес, посмотрите его в журнале: сеть и страна указаны у каждой записи.

Откуда на самом деле берётся нагрузка от роботов

• Поисковые роботы. Яндекс, Bing, Apple обходят сайт постоянно, а если у вас десятки региональных поддоменов, обход умножается на их число. Мы подтверждённых роботов не блокируем: это прямой путь вылететь из поиска. Скорость обхода Яндекса регулируется в Вебмастере, Bing понимает Crawl-delay в robots.txt, ненужные поисковики можно закрыть через Disallow.
• Сборщики данных. Роботы, которые собирают картинки и тексты для обучения моделей, ходят с сотен адресов и честно представляются. В настройках сайта есть переключатель «ИИ-краулеры»: выключите его, и они получат отказ вместо страницы.
• Безымянные парсеры. User-Agent вроде Mozilla/5.0 (compatible; crawler) — это робот, который не хочет, чтобы его нашли. Такой признак у нас весит максимум, и вместе с отсутствием браузерных заголовков парсер блокируется.
• Рекламные клики. Одна и та же страница с меткой yclid, открытая сотни раз, — это накрутка или проверка объявлений. По таким запросам срабатывают признаки частоты и отсутствия браузера.

Что сделать

1. Спросите хостинг, какой показатель превышен и какие страницы самые дорогие по процессорному времени.
2. Убедитесь, что запросы доходят до модуля: откройте журнал и сравните число записей за час с цифрами хостинга. Если разница в десятки раз, перед PHP стоит кэш или защита хостинга, и модулю просто нечего фильтровать.
3. Если у вас много поддоменов, ограничьте скорость обхода в Яндекс Вебмастере и в robots.txt.
4. Проверьте, что сайт не в режиме обучения: первые семь дней после подключения мы только наблюдаем. В разделе «Сайты» видно, когда обучение заканчивается, и его можно завершить досрочно.