Как найти ботов в access-логе nginx: команды и бесплатный анализатор

Коротко: боты в логе nginx видны по четырём признакам: необычные или пустые User-Agent, много запросов с одной подсети, шквал ответов 404 и обращения к служебным путям вроде /wp-login.php и /.env. Найти их можно несколькими командами или загрузить лог в бесплатный анализатор.

Метрика видит только тех, кто выполнил код счётчика. Боты, которые просто скачивают HTML, в ней не появляются, зато остаются в журнале веб-сервера: каждый запрос записан с IP, адресом страницы, статусом ответа и строкой User-Agent. Разбираем, как вытащить из этого лога подозрительный трафик.

Какие данные есть в логе

По умолчанию nginx пишет лог в формате combined. Одна строка выглядит так:

203.0.113.7 - - [05/Oct/2026:10:00:05 +0300] "GET /wp-login.php HTTP/1.1" 404 153 "-" "python-requests/2.31.0"

Здесь есть IP-адрес, время, запрос, статус ответа, размер, источник перехода (referer) и User-Agent. Заголовки вроде Accept-Language в стандартном формате не пишутся, поэтому по логу нельзя проверить, есть ли они у клиента.

Быстрые проверки командами

Команды ниже работают на Linux или в Git Bash для формата combined. Для больших файлов сначала возьмите свежую часть: tail -n 200000 access.log > log.txt.

Самые частые User-Agent

awk -F'"' '{print $6}' log.txt | sort | uniq -c | sort -rn | head -20

Смотрите на скриптовые клиенты (python-requests, curl, Go-http-client), на странные короткие строки и на огромное число запросов с одним нестандартным UA.

Самые активные IP и подсети

awk '{print $1}' log.txt | sort | uniq -c | sort -rn | head -20
awk '{split($1,a,"."); print a[1]"."a[2]"."a[3]".0/24"}' log.txt | sort | uniq -c | sort -rn | head -20

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

Всплеск ошибок 404

awk '$9==404 {print $1}' log.txt | sort | uniq -c | sort -rn | head -20

Сканеры перебирают адреса вслепую и получают много 404. Человек в обычной ситуации столько несуществующих страниц не открывает.

Обращения к служебным путям

grep -E "wp-login|xmlrpc|\.env|phpmyadmin|\.git/" log.txt | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Если на сайте нет WordPress, любые запросы к wp-login.php это разведка. Так же с .env и .git: там нет ничего для посетителей, их ищут ради утечек.

Пустой User-Agent

awk -F'"' '$6=="-" || $6==""' log.txt | wc -l

Настоящие браузеры всегда представляются. Запросы без User-Agent почти всегда делают скрипты.

На что смотреть в итоге

• Скрипт вместо браузера. В User-Agent curl, python-requests, Scrapy, Go-http-client, либо строка пуста.
• Одна сеть, разные браузеры. Из одной подсети /24 идут запросы с несколькими разными User-Agent: так выглядит ротация строк.
• Только страницы, без картинок и стилей. Человеческий браузер загружает ресурсы страницы, бот часто забирает только HTML. Это видно, если сравнить число запросов одной подсети к страницам и к статике.
• Слишком быстро. Десятки запросов в секунду с одного адреса.
• Поддельный Googlebot или YandexBot. User-Agent настоящий, а IP чужой. Строка сама ничего не доказывает, проверять нужно адрес: обратный DNS должен вести на домен владельца, а прямой запрос по этому имени возвращать тот же IP. Подробнее в статье как проверить, настоящий ли это Googlebot.

То же самое одним кликом: анализатор access-лога

Если команды не хочется разбирать, загрузите лог в анализатор access-лога Bot Guard. Он принимает файл .log, .txt или .gz (до 8 МБ, до 200 тысяч строк) или вставленный текст формата combined. Лог разбирается в памяти и нигде не сохраняется. В результате:

• доля запросов, которые не похожи на людей, и разбивка по категориям: браузеры, поисковые и служебные боты, нежелательные боты по каталогу, подделки, скрипты, пустой User-Agent;
• самые частые User-Agent с числом запросов, IP и ответов 4xx и пометкой, по какому признаку вынесен вердикт;
• самые активные подсети с пометкой «похоже на ротацию User-Agent»;
• страницы, на которые чаще всего ходят не-люди, и доля ошибок 4xx по ним.

Если рядом есть Метрика, сравните результат с отчётом «Сколько ботов в вашей Метрике»: лог покажет тех, кто не запускает счётчик, а Метрика даст поведение на сайте и рекламу.

Чего лог не покажет

• Подлинность поискового бота: в логе есть только IP и строка, обратный DNS нужно делать отдельно (это умеет проверка User-Agent и IP).
• Ботов за домашними (резидентными) прокси и с настоящим браузером: для сервера это обычные посетители.
• Данные о заголовках и поведении (мышь, скорость действий): стандартный лог их не содержит.

Что делать, когда нашли ботов

1. Не блокируйте по User-Agent вслепую. Легко зацепить настоящего поискового бота или нужный сервис. Сначала проверьте IP.
2. Ограничьте частоту запросов. Для nginx достаточно limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s; в блоке http и limit_req zone=perip burst=20 nodelay; в нужном location. Подберите значения под вашу нагрузку.
3. Закройте лишние адреса. Служебные пути, которых у вас нет, можно отдавать с кодом 444 или 403.
4. Автоматизируйте. Ручные списки устаревают быстро. Защита Bot Guard проверяет каждый запрос по User-Agent, IP, заголовкам и поведению и блокирует ботов в реальном времени, подключается к WordPress плагином и к 1С-Битриксу модулем.

Частые вопросы

Как найти ботов в логе, если у меня не combined, а другой формат?

Команды из статьи рассчитаны на combined. В другом формате номера полей awk будут другими: проверьте директиву log_format в конфигурации nginx и подставьте нужные номера. Анализатор тоже ждёт формат combined.

Сколько строк лога достаточно для анализа?

Обычно хватает последних 50–200 тысяч строк или нескольких дней трафика. Для выводов о редких ботах нужен больший период.

Можно ли доверять User-Agent в логе?

Нет. Строку отправляет сам клиент, и скрипт может написать в ней что угодно, в том числе «Googlebot». Настоящего бота подтверждает IP-адрес.

Это безопасно: я загружаю лог на чужой сайт?

Анализатор разбирает лог в памяти за один запрос и не сохраняет его на сервере. Если боитесь, перед загрузкой уберите из лога лишнее, например адреса со служебными параметрами.

Что делать, если ботов много, а блокировать нечем?

Начните с ограничения частоты запросов на уровне nginx, а для постоянной защиты подключите сервис, который проверяет каждый визит и блокирует ботов автоматически.