Поиск ботов в логах Nginx: 12 команд, чтобы найти их за 10 минут

Access.log — единственное место, где записан каждый запрос к сайту без исключений. Ни Метрика, ни Google Analytics так не умеют: счётчики видят только тех, у кого выполнился JavaScript, а парсеры, скрейперы и брутфорс-скрипты JS не выполняют вовсе. Поэтому поиск ботов в логах Nginx остаётся самым честным и самым дешёвым способом узнать, кто на самом деле ходит на ваш сайт: инструменты уже стоят на сервере, платить не нужно, первые находки появляются через десять минут.

Масштаб проблемы понятен по отраслевой статистике. По отчёту Imperva Bad Bot Report за 2025 год автоматизированный трафик впервые за десятилетие превысил человеческий — 51% всех запросов в интернете, и 37% приходится на вредоносных ботов. В пересчёте на обычный корпоративный сайт это значит, что из ста тысяч строк access.log живым людям принадлежит меньше половины.

Мы в BotHunt разбираем логи каждого сайта, который к нам подключается, и первые находки почти всегда одинаковые: один IP с четырьмя тысячами запросов за ночь, «Googlebot», который не проходит обратный DNS, и клиент, забравший весь каталог, но ни разу не запросивший ни одной картинки. Ниже — готовые команды awk и grep под копипаст, разбор GoAccess, настройка log_format под ловлю ботов и честные границы метода: что по логам не видно в принципе.

Коротко:

• Поиск ботов в логах Nginx начинается с файла /var/log/nginx/access.log: в формате combined первое поле строки — IP клиента, а шестое поле при разбиении по кавычкам — User-Agent.

• Три самых быстрых признака бота в логах: аномальное число запросов с одного IP, полное отсутствие обращений к CSS, JS и картинкам, библиотечный или пустой User-Agent вроде python-requests и Go-http-client.

• Подделку «Googlebot» и «YandexBot» вычисляют обратным DNS-запросом за 30 секунд: имена роботов Яндекса заканчиваются на yandex.ru, yandex.net или yandex.com, роботов Google — на googlebot.com или google.com.

• GoAccess строит по access.log интерактивный отчёт в терминале или в HTML одной командой и не требует базы данных.

• Логи ловят простых ботов, но не видят поведенческих: накрутчик ПФ через резидентный прокси и настоящий браузер выглядит в access.log как обычный посетитель.

Что записывает access.log Nginx и где в строке искать ботов

Access.log Nginx пишет по одной строке на каждый HTTP-запрос: IP, время, метод, URL, код ответа, объём ответа, реферер и User-Agent. Поиск ботов в логах Nginx целиком строится на этих восьми полях — их хватает, чтобы отделить бота от человека примерно в 80% случаев без единого дополнительного инструмента.

По умолчанию используется формат combined. Он объявлен в nginx.conf так:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Одна реальная строка выглядит так:

203.0.113.45 - - [15/Aug/2026:03:41:12 +0300] "GET /catalog/?PAGEN_1=118 HTTP/1.1" 200 48213 "-" "python-requests/2.31.0"

Утилита awk по умолчанию режет строку по пробелам, поэтому номера полей фиксированы. Запомните таблицу ниже — она превращает любую команду из этой статьи в конструктор.

Последняя строка важна: User-Agent содержит пробелы, поэтому по пробелам его резать нельзя. Для него используют другой разделитель — кавычку: awk -F'"' '{print $6}'.

Подготовка за 60 секунд: где лежат логи, ротация и реальный IP

Стандартный путь — /var/log/nginx/access.log, но на хостингах с панелями управления он другой. Точный путь всегда можно узнать из собранного конфига, не гадая.

nginx -T 2>/dev/null | grep -E '^\s*access_log'

Дальше три вещи, которые ломают анализ чаще всего.

• Ротация. Logrotate ежедневно переименовывает файл в access.log.1 и жмёт старые в .gz. Если атака была позавчера, в свежем логе её нет. Читайте архивы напрямую.

• Объём. На нагруженном сайте access.log весит гигабайты, и awk по нему идёт минутами. Для разведки хватает последних 200 тысяч строк.

• Подменённый IP. Если сайт стоит за CDN, балансировщиком или reverse-proxy, в $remote_addr окажется адрес прокси, а не посетителя. Тогда весь топ по IP покажет один-единственный адрес — и анализ бесполезен.

Первые две проблемы решаются одной строкой:

# все логи, включая сжатые архивы
zcat -f /var/log/nginx/access.log* > /tmp/all.log

# быстрая разведка по последним 200 000 строкам
tail -n 200000 /var/log/nginx/access.log > /tmp/sample.log

Третья — модулем real_ip. Без него любые выводы про IP будут неверными:

set_real_ip_from 10.0.0.0/8;      # подсеть вашего прокси или CDN
real_ip_header   X-Forwarded-For;
real_ip_recursive on;

Поиск ботов в логах Nginx: 12 готовых команд awk и grep

Ниже — набор, с которого мы сами начинаем поиск ботов в логах Nginx на любом сайте. Команды идут от общего к частному: сначала находим подозрительные IP и User-Agent, затем проверяем каждого кандидата отдельно. Везде подставляйте свой путь к логу вместо access.log.

1. Топ-20 самых активных IP. Отправная точка. Живой посетитель за сутки делает десятки запросов, бот — тысячи.

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

2. Топ-20 User-Agent. Сразу видны curl, python-requests, Go-http-client, Scrapy, node-fetch и прочие непользовательские клиенты.

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

3. Что именно тянул подозрительный IP. Показывает цель визита: каталог, прайс, форма или админка.

awk '$1=="203.0.113.45" {print $7}' access.log | sort | uniq -c | sort -rn | head -30

4. Доля статики — главный маркер парсера. Браузер всегда подгружает CSS, JS и картинки. Парсеру они не нужны, поэтому доля статики у него близка к нулю.

awk '$1=="203.0.113.45" {tot++; if ($7 ~ /\.(css|js|png|jpe?g|webp|svg|gif|ico|woff2?)($|\?)/) st++} END {printf "всего %d, статика %d (%.1f%%)\n", tot, st, st*100/tot}' access.log

5. Плотность запросов по минутам. Ровные 60 запросов каждую минуту подряд — это расписание, а не человек.

awk '$1=="203.0.113.45" {print substr($4,14,5)}' access.log | sort | uniq -c | sort -rn | head

6. Распределение по часам. Ровная нагрузка в 03:00–06:00 при российской аудитории — сигнал автоматики.

awk '$1=="203.0.113.45" {print substr($4,14,2)}' access.log | sort | uniq -c | sort -k2n

7. Лидеры по 404. Сканеры уязвимостей перебирают /.env, /.git/config, /wp-admin и оставляют сотни 404 подряд.

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

8. Брутфорс страниц входа. Стандартные цели — WordPress, XML-RPC, Bitrix и Joomla.

grep -E 'POST (/wp-login\.php|/xmlrpc\.php|/bitrix/admin|/administrator)' access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

9. Пустой User-Agent. Прочерк вместо UA — почти всегда самописный скрипт или уязвимый сканер.

awk -F'"' '$6=="-" || $6=="" {split($1,a," "); print a[1]}' access.log \
  | sort | uniq -c | sort -rn | head -20

10. Группировка по подсетям /24. Ботнет и прокси-пул часто раскиданы по соседним адресам: по одному IP их не видно, по подсети — сразу.

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

11. Пики нагрузки по секундам. Находит момент атаки — дальше по этой секунде выбираются участники.

awk '{print $4}' access.log | uniq -c | sort -rn | head -10

12. Все IP, представившиеся ботом поисковика. Список кандидатов на проверку подделки — ей посвящён отдельный раздел ниже.

grep -iE 'googlebot|yandexbot|bingbot' access.log | awk '{print $1}' | sort -u

Практика: запускайте команды 1, 2 и 4 в такой последовательности. Первая даёт подозреваемых, вторая — их инструмент, третья доказывает автоматизацию. На типовом сайте этой связки хватает, чтобы за пять минут назвать конкретные IP.

Семь признаков бота в логах: как отличить парсер от посетителя

Отдельный признак почти никогда не доказателен: у мониторинга аптайма тоже пустой реферер, а у мобильного приложения — нестандартный User-Agent. Вердикт выносится по совокупности. Два совпадения — повод присмотреться, три и больше — практически гарантированный бот.

Отдельный класс — боты, которые представляются честно: AhrefsBot, SemrushBot, MJ12bot, DotBot, а с 2024 года ещё GPTBot, ClaudeBot и PerplexityBot. Они видны в топе User-Agent первой же командой, и решение по ним не техническое, а продуктовое: нужно ли вам, чтобы контент сайта попадал в обучающие датасеты и ответы AI-поиска. Разбор — в статье «Скрейпинг AI-ботами: как заблокировать в 2026».

Не хотите разбирать логи руками каждую неделю — BotHunt делает это в реальном времени и режет ботов до того, как они дойдут до сайта. 14 дней бесплатно, установка за минуту. Подключить защиту →

Как проверить фейковый Googlebot и YandexBot в логах Nginx

Подделать User-Agent поисковика — одна строка кода, поэтому строке «Googlebot» в логе верить нельзя. Единственный корректный способ проверки — обратный DNS-запрос с подтверждением: по IP получают доменное имя, проверяют его окончание, а затем разрешают это имя обратно в IP и сверяют с исходным.

Яндекс описывает алгоритм в справке Вебмастера: имена всех его роботов заканчиваются на yandex.ru, yandex.net или yandex.com. Google описывает тот же принцип в документации Search Central и дополнительно публикует диапазоны IP в машиночитаемых JSON-файлах.

Готовый скрипт проверяет всех разом. Для утилиты dig нужен пакет dnsutils или bind-utils:

for ip in $(grep -iE 'googlebot|yandexbot' access.log | awk '{print $1}' | sort -u); do
  name=$(dig +short -x "$ip" | head -1)
  case "$name" in
    *googlebot.com.|*google.com.|*yandex.ru.|*yandex.net.|*yandex.com.)
      back=$(dig +short "$name" | head -1)
      [ "$back" = "$ip" ] && echo "OK    $ip $name" || echo "FAKE  $ip $name (обратная сверка не сошлась)" ;;
    *) echo "FAKE  $ip ${name:-нет PTR-записи}" ;;
  esac
done

Строки с пометкой FAKE — чужие скрипты, которые прикрываются именем поисковика, чтобы их не блокировали. Приём до сих пор работает по одной причине: почти все правила блокировки написаны по User-Agent, а не по факту принадлежности сети.

GoAccess: визуальный анализ логов Nginx за две минуты

GoAccess — консольный анализатор access.log, который строит интерактивный дашборд прямо в терминале или экспортирует его в самодостаточный HTML-файл. Базы данных и веб-сервера ему не нужно, разбор миллиона строк занимает секунды.

apt install goaccess        # Debian, Ubuntu
dnf install goaccess        # RHEL, AlmaLinux, Rocky

Три команды закрывают почти все задачи:

# 1. Интерактивный отчёт в терминале
goaccess /var/log/nginx/access.log --log-format=COMBINED

# 2. HTML-отчёт, включая архивные логи
zcat -f /var/log/nginx/access.log* | goaccess - --log-format=COMBINED -o /tmp/report.html

# 3. Живой дашборд, обновляемый в реальном времени
goaccess /var/log/nginx/access.log --log-format=COMBINED -o /tmp/report.html --real-time-html

В отчёте на ботов указывают четыре панели.

• Hosts. Топ IP с числом запросов и объёмом трафика. Отрыв лидера на порядок от остальных — кандидат номер один.

• Browsers и Operating Systems. Библиотечные клиенты попадают в «Unknown» или в отдельную строку — их не спутать с браузерами.

• Requested Files и Static Requests. Сравните объёмы: если динамических страниц отдано в разы больше, чем статики, по сайту идёт парсер.

• Not Found URLs. Список 404 показывает, что перебирает сканер уязвимостей.

Ограничение у GoAccess то же, что у любого лог-анализатора: он показывает срез прошлого и не остановит парсер, который работает прямо сейчас. Параметры форматов — в документации на goaccess.io.

Кастомный log_format: что добавить, чтобы боты палились сразу

Формат combined писали в 1996 году, и признаков современного бота в нём нет. Добавив пять переменных в log_format, вы получите в логе то, что раньше требовало отдельной аналитики. Формат JSON включается директивой escape=json и доступен начиная с Nginx 1.11.8.

log_format botlog escape=json
  '{'
  '"ts":"$time_iso8601",'
  '"ip":"$remote_addr",'
  '"xff":"$http_x_forwarded_for",'
  '"method":"$request_method",'
  '"uri":"$request_uri",'
  '"status":$status,'
  '"rt":$request_time,'
  '"ref":"$http_referer",'
  '"ua":"$http_user_agent",'
  '"lang":"$http_accept_language",'
  '"tls":"$ssl_protocol",'
  '"cipher":"$ssl_cipher"'
  '}';

access_log /var/log/nginx/bots.json.log botlog;

JSON-лог разбирается утилитой jq одной строкой. Например, все клиенты без Accept-Language:

jq -r 'select(.lang == "") | .ip' /var/log/nginx/bots.json.log | sort | uniq -c | sort -rn | head

Связка Accept-Language плюс параметры TLS — это уже подступ к фингерпринтингу. Полноценная версия того же подхода на уровне сети описана в статье про JA3-фингерпринтинг: там отпечаток снимается с ClientHello ещё до первого HTTP-запроса.

Хотите видеть ботов в момент запроса, а не в завтрашнем логе? Агент BotHunt выносит вердикт за 4–12 мс и не пропускает бота до страницы. Попробовать 14 дней бесплатно →

Что делать с найденными ботами: deny, limit_req и их пределы

Нашли — блокируйте, но правильным инструментом. Точечный deny по IP годится для разового вредителя, лимит запросов — для защиты тяжёлых страниц, фильтр по User-Agent — только для честных ботов, которые не маскируются.

Фильтр по User-Agent с ответом 444 (Nginx закрывает соединение, не отдавая ничего):

map $http_user_agent $bad_bot {
    default 0;
    ~*(AhrefsBot|SemrushBot|MJ12bot|DotBot|Bytespider|python-requests|Scrapy) 1;
    "" 1;
}

server {
    if ($bad_bot) { return 444; }
}

Ограничение частоты — 30 запросов в минуту на IP с допуском на всплеск:

limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/m;

location / {
    limit_req zone=perip burst=20 nodelay;
}

Главная ошибка при блокировке по User-Agent — задеть поисковики. Проверяйте регулярку на тестовой строке до перезагрузки конфига. Почему сам robots.txt защитой не является, разбираем в материале «robots.txt как защита от ботов: мифы». Сценарий с админками WordPress — в статье «Защита WordPress от брутфорса».

Чего логи Nginx не покажут: четыре предела метода

Анализ логов — обязательная гигиена, но не защита. Он отвечает на вопрос «кто приходил вчера», а не «кого не пустить сейчас». Четыре ограничения нужно понимать до того, как вы построите на логах всю оборону.

• Только постфактум. К моменту, когда команда отработала, каталог уже выкачан, а формы уже забиты спамом. Лог фиксирует ущерб, а не предотвращает его.

• Нет сигналов браузера. В access.log нет движения мыши, скролла, таймингов между действиями и результатов canvas-теста. Именно по ним отличают эмулированный браузер от живого — и именно этих данных на уровне HTTP не существует.

• Резидентные прокси обнуляют топ по IP. Когда каждый запрос идёт с нового адреса из реальной домашней сети, самый активный IP в логе делает пять запросов, а не пять тысяч. Первая же команда из этой статьи не покажет ничего.

• Накрутка ПФ невидима. Бот, имитирующий поведение пользователя, запускает настоящий Chrome, отдаёт валидный User-Agent и честно грузит всю статику. В логах он неотличим от посетителя.

Ссылки на подробные разборы: резидентные прокси и ASN-фильтрация, признаки атаки поведенческими ботами и как обнаружить парсер на сайте семью способами. Пятое, менее очевидное ограничение — объём: на логе в 10 млн строк последовательные awk-проходы занимают минуты, и регулярный мониторинг вручную становится нереальным.

Практический вывод простой. Логи дают разовую диагностику и доказательства: именно из них берут конкретные IP, User-Agent и URL для отчёта или для обращения к хостеру. Постоянную фильтрацию строят на уровне запроса — до того, как он дошёл до приложения. Агент BotHunt проверяет каждый запрос за 4–12 миллисекунд и отсекает автоматику по поведению и отпечатку, а не по строке User-Agent, которую бот пишет сам про себя.

Готовый скрипт: отчёт по ботам в логах Nginx за 10 минут

Скрипт ниже сводит поиск ботов в логах Nginx к одной команде: он собирает топ IP, топ User-Agent, лидеров по 404, попытки входа и долю статики у главного подозреваемого. Сохраните как botreport.sh, дайте права на исполнение и запустите с путём к логу.

#!/bin/bash
LOG="${1:-/var/log/nginx/access.log}"

echo "=== Топ-10 IP ==="
awk '{print $1}' "$LOG" | sort | uniq -c | sort -rn | head -10

echo "=== Топ-10 User-Agent ==="
awk -F'"' '{print $6}' "$LOG" | sort | uniq -c | sort -rn | head -10

echo "=== Топ-5 по 404 ==="
awk '$9==404 {print $1}' "$LOG" | sort | uniq -c | sort -rn | head -5

echo "=== Попытки входа ==="
grep -cE 'POST (/wp-login\.php|/xmlrpc\.php|/bitrix/admin)' "$LOG"

echo "=== Доля статики у самого активного IP ==="
TOP=$(awk '{print $1}' "$LOG" | sort | uniq -c | sort -rn | head -1 | awk '{print $2}')
awk -v ip="$TOP" '$1==ip {tot++; if ($7 ~ /\.(css|js|png|jpe?g|webp|svg|gif|ico|woff2?)($|\?)/) st++} END {printf "%s: всего %d, статика %d (%.1f%%)\n", ip, tot, st, st*100/tot}' "$LOG"

Порядок работы с отчётом занимает те самые десять минут.

1. Запустите скрипт на логе за сутки и выпишите три-пять IP из топа.

2. Прогоните каждый через команду с долей статики: меньше 10% — почти наверняка парсер.

3. Проверьте всех, кто назвался поисковиком, обратным DNS — фейки идут в блок сразу.

4. Сопоставьте всплески по часам с данными Метрики: расхождение показывает трафик без JavaScript.

5. Закройте разовые адреса через deny, поставьте limit_req на тяжёлые разделы и переходите к постоянной защите.

Полезное дополнение — сверка с аналитикой. Разрыв между числом запросов в логе и визитами в счётчике и есть трафик, который не выполняет JS. Как читать это со стороны Метрики, мы описали в статье «Признаки мусорного трафика в Яндекс Метрике».

BotHunt закрывает то, что логи только показывают: фильтрует ботов в момент запроса, чистит трафик из Директа и Метрики и ставится одной строкой кода. Тариф Site — 890 ₽ в месяц. Смотреть тарифы →

Часто задаваемые вопросы

Где лежат логи Nginx и как их посмотреть?

Поиск ботов в логах Nginx начинается с файлов /var/log/nginx/access.log и error.log — это путь по умолчанию. На хостингах с панелями управления он другой, обычно внутри домашней директории пользователя. Точный путь всегда виден в собранном конфиге: выполните nginx -T | grep access_log. Читать файл можно любой утилитой: tail -f для живого потока, less для навигации, awk и grep для выборок.

За какой период нужны логи, чтобы найти ботов?

Для первичной диагностики достаточно суток: этого хватает, чтобы увидеть ночные всплески и топ активных IP. Для доказательства систематического парсинга берите неделю — тогда видно, что один и тот же клиент возвращается по расписанию. Учитывайте ротацию: старые дни лежат в сжатых архивах access.log.N.gz.

Как отличить настоящего Googlebot от подделки?

Только обратным DNS-запросом с подтверждением. Получите по IP доменное имя командой dig +short -x, проверьте, что оно заканчивается на googlebot.com или google.com, затем разрешите это имя обратно и убедитесь, что IP совпал с исходным. Для роботов Яндекса домены — yandex.ru, yandex.net и yandex.com. Проверять по одному User-Agent бесполезно: он подделывается одной строкой кода.

Почему боты, которые накручивают поведенческие факторы, не видны в логах?

Потому что они работают через настоящий браузер и через резидентные прокси. В access.log такой бот отдаёт валидный User-Agent Chrome, грузит CSS, JS и картинки, а каждый его запрос приходит с нового IP домашнего провайдера. По полям строки лога он неотличим от живого посетителя. Такие боты вычисляются только по поведению на странице и по отпечатку браузера.

Можно ли анализировать логи, если сайт стоит за CDN или прокси?

Да, но сначала нужно включить модуль real_ip. Без него в поле $remote_addr будет записан адрес CDN, и топ по IP покажет один адрес на весь лог. Добавьте директивы set_real_ip_from с подсетью вашего прокси и real_ip_header X-Forwarded-For, перезагрузите конфиг и анализируйте логи, записанные уже после этого.

Что выбрать: GoAccess или команды awk и grep?

Оба, для разных задач. GoAccess даёт обзорную картину за минуту: топ хостов, браузеры, 404, объёмы. Команды awk и grep нужны для точечных проверок, которых в дашборде нет, — например, для расчёта доли статики у конкретного IP. Практичный порядок: сначала GoAccess для общей картины, затем awk по найденным подозреваемым.

Стоит ли блокировать ботов директивой deny в Nginx?

Для разового вредителя — да, это быстро и бесплатно. Как постоянная стратегия — нет: список IP устаревает за часы, потому что боты меняют адреса, а поддерживать его вручную невозможно. Блокировка по User-Agent помогает только против честных краулеров, которые не маскируются. Против подделки нужен анализ поведения и отпечатка клиента.

Какая доля ботов в логах считается нормальной?

Универсальной нормы нет, но ориентир дают отраслевые отчёты: по данным Imperva за 2025 год автоматизированный трафик составляет около 51% всех запросов в интернете, из них 37% — вредоносные боты. Часть этого трафика полезна: поисковые краулеры и мониторинг аптайма сайту нужны. Тревожный сигнал — не сама доля, а рост нагрузки без роста заявок и продаж.