Как выявить ботов на сайте: диагностика трафика
Как исследовать логи сайта, сопоставить частоту, IP и User-Agent, отличить полезные обращения и проверить правила перед блокировкой.
Боты — программы, которые обращаются к сайту автоматически. Среди них есть поисковые роботы, мониторинг доступности, интеграции и парсеры. Задача диагностики — понять, какие обращения создают проблему, и выбрать соразмерное правило. Одна необычная строка в журнале ещё не доказывает вредоносную активность.
Какие данные собрать
Начните с access-логов сервера или прокси. Для первичного разбора нужны время запроса, метод и путь, статус ответа, длительность, адрес источника и User-Agent. Сравнивайте одинаковые интервалы при обычной нагрузке и во время проблемы.
Не добавляйте в диагностическую выгрузку пароли, токены, тела запросов или полные URL с чувствительными параметрами. Если адреса и идентификаторы нужны для расследования, ограничьте доступ и срок хранения выгрузки.
Какие признаки сопоставлять
| Наблюдение | Возможная причина | Что проверить |
|---|---|---|
| Частые обращения с одного IP | Автоматизация, общий адрес или ошибка повторов | Частоту, пути и нормальные действия с этого IP |
| Последовательный обход страниц каталога | Парсинг или индексация | User-Agent, источник и скорость обхода |
| Много ответов 404 на разные пути | Сканирование или сломанные ссылки | Повторяемость путей и изменения сайта |
| Пустой или необычный User-Agent | Скрипт, интеграция или нестандартный клиент | Владельца интеграции и характер запросов |
| Всплеск после релиза | Ошибка приложения или изменившаяся загрузка | Новые запросы фронтенда и повторные попытки |
Это гипотезы для проверки. Ни одна строка таблицы не является самостоятельным правилом «запретить».
Пример разбора всплеска
Допустим, в условном журнале один IP отправил 900 запросов к каталогу за минуту. Большинство URL перебирают страницы по порядку, но User-Agent похож на браузер. Это основание исследовать автоматический обход, а не объявлять адрес ботом только по числу запросов.
Сначала проверьте, не видит ли журнал IP общего прокси. Затем сравните нагрузку с обычным просмотром каталога: сколько запросов создаёт одна страница, есть ли предзагрузка, не возник цикл повторов после ошибки. Если обращения действительно нежелательны, испытайте лимит в наблюдении. К известному источнику можно применить более узкое адресное правило.
Почему User-Agent недостаточно
User-Agent задаёт клиент, поэтому браузерную строку и имя поискового робота можно подделать. Пустая строка также встречается у допустимых интеграций. Проверка подстроки помогает выразить правило, но не подтверждает личность клиента.
Если клиент представляется Googlebot, сверяйте источник по официальной инструкции Google: доступны проверка диапазонов IP и проверка DNS в обратном и прямом направлении. Одного имени в заголовке или только обратной DNS-записи недостаточно. Такая проверка требует отдельной настройки; Fraudly не делает автоматическое исключение по имени робота.
Выберите действие по причине
- Если нежелательна частота обращений, изучите ограничение запросов по IP.
- Если установлен конкретный источник, рассмотрите блокировку IP или подсети и оцените сопутствующие ограничения.
- Если проблема появилась после релиза, исправьте лишние запросы или повторы приложения: блокировка собственного клиента скрывает причину.
- Если обращения полезны, учтите их при настройке правил и проверьте доступ поисковых роботов и интеграций после изменения защиты.
Сначала наблюдение, затем защита
В Fraudly режим наблюдения сохраняет доступ даже при нарушении правила. Он позволяет оценить срабатывания до включения блокировки. При переходе к защите проверьте ключевые сценарии посетителя и возможность отменить ошибочное ограничение.
Текущее ядро Fraudly проверяет IP/CIDR, параметры User-Agent и частоту. Эти проверки не заменяют полноценное исследование логов: автоматический поведенческий скоринг и постоянный журнал трафика не входят в описанный механизм. Для начала диагностики используйте журналы своего сервера или прокси.