Кто на самом деле нагружает сайт: почему User-Agent врёт и как защитить сервер от сканеров

Большинство владельцев сайтов судят о визитах ботов по отчётам аналитики или логам с фильтром по User-Agent. Если в строке значится «Googlebot», «GPTBot» или «ClaudeBot», кажется, что сайт индексирует поисковик или читает нейросеть.

На практике девять из десяти таких записей на рабочем сервере — подделки. Под видом поисковиков и ИИ-краулеров приходят автоматические сканеры уязвимостей. Они перебирают системные файлы, ищут забытые архивы баз данных и создают паразитную нагрузку на бэкенд.

Мы разобрали логи боевого сервера веб-студии за две недели (с 23 августа по 6 сентября 2026 года), отделили настоящих роботов от подделок по сетевым маршрутам и замерам скорости, а затем закрыли сервер двухконтурной защитой на уровне Nginx.

Ниже — сухие цифры, замеры и рабочий конфиг.

1. Анатомия подделок: 10 тысяч хитов под чужими именами

За две недели сервер зафиксировал 10 048 запросов из облака Google Cloud (подсети 34.0.0.0/8, 35.0.0.0/8, 136.107.0.0/16, 136.118.0.0/16 с PTR-записями *.bc.googleusercontent.com).

Все они представлялись официальными краулерами: GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, PerplexityBot, GrokBot, Amazonbot.

О том, чем они занимались, говорят ответы сервера: 6 697 запросов завершились ошибкой 404 Not Found. Сканеры методично опрашивали пути, которых на нормальном сайте быть не может:

• Файлы конфигурации и ключи: /.env, /.env.local, /.git/config, /.yarnrc, /yarn.lock.
• Учётные данные серверов и облаков: /@fs/root/.aws/credentials, /@fs/proc/self/environ.
• Отладочные панели и известные уязвимости фреймворков: /debug/default/view, /_ignition/execute-solution (RCE в Laravel), /zabbix/.env.

23 августа подключился норвежский IP-адрес 87.120.104.29. Он выдал 3 286 запросов за один час, представляясь официальным Googlebot. Искал он не статьи и не портфолио, а конфигурационные файлы.

6 сентября тайский адрес 103.117.149.181 отправил 3 965 запросов за час, перебирая пароли к панели WordPress (/wp-login.php, /wp-admin/).

Вывод простой: настоящих GPTBot, Perplexity и Grok на сайте почти не было. Почти всё под их именами — вредоносный скан.

Реальный интерес со стороны нейросетей проявили только Meta (meta-externalagent — 1 897 запросов) и Anthropic (ClaudeBot — 308 запросов).

2. Как проверить бота: rDNS против поддельного заголовка

Полагаться на строку User-Agent бессмысленно: любой скрипт на Python или утилита curl позволяют подставить любое имя за одну секунду:

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.ru

Подлинность краулера проверяется на сетевом уровне — через двойное разрешение DNS (Forward-Confirmed Reverse DNS, FCrDNS) или по автономным системам (ASN):

1. Обратный запрос (rDNS): сервер берёт IP-адрес клиента и запрашивает его доменное имя (PTR-запись).
2. Прямой запрос (Forward DNS): сервер резолвит полученный домен обратно в IP. Если IP совпал с адресом клиента — бот подлинный.

Официальные поисковые и ИИ-роботы ходят с фиксированных доменов и собственных подсетей:

• Googlebot: PTR оканчивается на .googlebot.com или .google.com, диапазон подсетей 66.249.64.0/20.
• YandexBot: PTR оканчивается на *.spider.yandex.com или *.yandex.ru.
• Anthropic (ClaudeBot): автономная система AWS-ANTHROPIC, диапазоны 216.73.216.0/24 и 216.73.217.0/24.
• Meta (meta-externalagent): подсети 57.141.20.0/24.

Если клиент называется Googlebot или GPTBot, но соединение идёт с виртуальной машины Google Cloud, Hetzner или DigitalOcean — это стопроцентная подделка.

3. Почему бан по IP — тупиковый путь

Когда владелец сайта видит в логах сканирование, он обычно идёт блокировать адреса через iptables, ufw или fail2ban.

Мы замерили жизненный цикл атакующих IP:

• Адрес 87.120.104.29 выдал 3 300 запросов за один час 23 августа и больше не вернулся.
• Адрес 103.117.149.181 сделал 3 969 запросов за один час 6 сентября и исчез.
• Каждый день в логах появляется от 3 до 15 новых IP-адресов с точно таким же поведением: короткий залп за 30–60 минут и полная смена пула.

Сканеры используют ротируемые прокси и виртуальные серверы с почасовой оплатой. Блокируя отдельные IP, вы воюете с одноразовыми расходниками. Таблицы firewall раздуваются, а следующий залп всё равно приходит с чистого адреса.

Исключение за две недели нашлось ровно одно: IP 80.94.95.211 методично приходил 10 дней из 15 и искал /.env и бэкапы баз. Такие адреса имеет смысл банить вручную. Для остальных нужен системный барьер.

4. Инженерный Rate Limiting: замеры скорости человека, робота и сканера

Ограничение частоты запросов (rate limiting) часто ставят наугад, выставляя цифры вроде 10 r/s. В итоге либо сервер продолжает захлёбываться, либо реальные пользователи натыкаются на ошибку 429 Too Many Requests.

Мы замерили пиковую скорость запросов к HTML-страницам для разных категорий посетителей:

Разрыв между человеком (и официальным поисковиком) и сканером — от 10 до 100 раз.

На основе этих цифр мы настроили лимит:

limit_req_zone $binary_remote_addr zone=page_limit:10m rate=3r/s;
limit_req zone=page_limit burst=30 nodelay;

Лимит rate=3r/s с запасом burst=30 позволяет живому посетителю мгновенно открыть пачку вкладок, но сразу отсекает скрипт, бьющий со скоростью 50–500 запросов в секунду.

Ловушка статики: почему нельзя лимитировать сайт целиком

Лимитировать весь сайт одним правилом (location /) — грубая ошибка.

При открытии страницы браузер параллельно запрашивает десятки статических файлов: бандлы Next.js, CSS-стили, веб-шрифты, картинки и иконки. Замер показал, что реальный браузер при загрузке даёт всплеск до 83 запросов в секунду.

Если включить лимит rate=3r/s burst=30 на весь сайт без разбора, браузер посетителя словит ошибку 429 на половине скриптов и стилей. Страница откроется белым экраном или сломанной версткой.

Лимитировать нужно только динамические HTML-страницы. В Nginx это делается через пустой ключ зоны для статики и доверенных сетей:

# Статические файлы отдаются без ограничений
location ~* ^/(_next/static|images|fonts)/|\\.(css|js|png|jpg|svg|woff2)$ {
    limit_req zone=page_limit burst=0; # пустой ключ отключает подсчет
    try_files $uri =404;
}

5. Связка Nginx Map + Geo: отсекаем подделки с нулевым оверхедом

Зачем тратить ресурсы Node.js или базы данных на обработку фальшивок, если их можно срезать на входе в Nginx?

Блокировать заголовки GPTBot или Googlebot нельзя — сайт выпадет из поиска и нейросетей. Блокировать подсети Google Cloud тоже нельзя — отсекутся нормальные сервисы и прокси.

Мы заблокировали строгое пересечение двух условий:

1. Клиент называет себя краулером в User-Agent.
2. IP-адрес клиента принадлежит облачным хостингам (Google Cloud), откуда эти краулеры официально никогда не работают.

Конфиг Nginx:

# 1. Проверяем заголовок User-Agent
map $http_user_agent $is_crawler_ua {
    default 0;
    ~*(Googlebot|YandexBot|GPTBot|ClaudeBot|PerplexityBot|GrokBot|Amazonbot) 1;
}

# 2. Проверяем облачные диапазоны
geo $is_cloud_network {
    default 0;
    34.0.0.0/8 1;
    35.0.0.0/8 1;
    104.154.0.0/15 1;
    130.211.0.0/16 1;
    136.107.0.0/16 1;
    136.118.0.0/16 1;
}

# 3. Блокируем только пересечение
map "$is_crawler_ua:$is_cloud_network" $block_fake_bot {
    "1:1" 1;
    default 0;
}

В блоке виртуального хоста остаётся одна строка:

if ($block_fake_bot) {
    return 403;
}

Настоящий Googlebot с IP 66.249.* получает ответ 200 OK. Обычный пользователь или сторонний сервис из Google Cloud без бот-заголовка получает 200 OK. Поддельный краулер моментально получает 403 Forbidden силами Nginx за долю миллисекунды.

6. Ложная тревога: «Нас взломали, в логах 200 OK на запрос .env»

Во время разбора логов нам попалась тревожная строка:

"GET /?file=../../.env HTTP/2.0" 200 136241

Первая реакция — паника: сервер вернул код 200 на попытку выкачать файл конфигурации (Directory Traversal).

Мы проверили ответ через curl. Размер ответа — 136 килобайт, а внутри — обычный HTML главной страницы сайта. Next.js просто проигнорировал незнакомый GET-параметр и вернул стандартную страницу. Никакой утечки не произошло.

Но здесь есть другая проблема: рендеринг главной страницы требует работы Node.js и памяти сервера. Когда бот шлёт тысячи таких запросов, он впустую греет процессор. Поэтому подобные конструкции стоит отсекать ещё на веб-сервере.

7. Где границы этого подхода

У этого решения есть понятные границы, о которых нужно помнить:

1. Медленный распределённый парсинг. Если конкурент запустит 5 000 домашних прокси и будет делать по одному запросу в минуту с каждого адреса без подозрительных заголовков, rate limiting 3 r/s его не заметит. Здесь нужен поведенческий анализ и капча.
2. Смена облачных провайдеров. Правило по Google Cloud закрывает подсети GCP. Если злоумышленник перенесёт сканер на Hetzner, OVH или Scaleway, правило придётся дополнять новыми диапазонами.
3. Целенаправленный скан под видом браузера. Если бот идёт с нормального провайдера со скоростью 1–2 страницы в секунду и стандартным заголовком Chrome, сервер посчитает его обычным посетителем.

Защита сервера не делается один раз: правила приходится докручивать по мере появления новых сетей и аномалий в логах.

8. Чеклист для вашего сервера

Что стоит проверить прямо сейчас:

• [ ] Логируется ли Host? Если на одном Nginx крутится несколько сайтов, без переменной $host в начале строки лога все запросы смешиваются в кашу.
• [ ] Разделен ли rate limit для динамики и статики? Убедитесь, что лимит частоты не бьёт по параллельной загрузке картинок, стилей и шрифтов реальных пользователей.
• [ ] Проверены ли краулеры по rDNS? Не верьте счетчикам аналитики на слово: сверяйте реальные IP поисковиков и ИИ-ботов с их официальными сетями.
• [ ] Закрыты ли файлы окружения? Пути /.env, /.git, /.aws, /wp-config* должны отдавать 403 или 404 в Nginx до обращения к бэкенду.
• [ ] Анализируются ли всплески? Рост трафика в 4 утра при пустой корзине и отсутствии заявок — это не «успех в SEO», а повод открыть access.log.

Инженерная поддержка и мониторинг инфраструктуры

В большинстве компаний техническая поддержка сайта сводится к замене баннеров и обновлению CMS раз в квартал. В это время сервер годами обслуживает паразитный трафик, базы данных раздуваются мусорными сессиями, а во время реального пика рекламной кампании сайт начинает падать.

Инженеры студии 2САЙТ смотрят на поддержку по-другому:

• Мы регулярно анализируем серверные логи и отсекаем паразитный трафик до того, как он создаст проблемы для бизнеса.
• Настраиваем отказоустойчивые конфигурации Nginx, Node.js и баз данных с защитой от сканеров и перегрузок.
• Следим за тем, чтобы ресурсы хостинга расходовались на реальных клиентов, а не на сканеры уязвимостей.

Если вам нужна надежная серверная инфраструктура и регулярный инженерный контроль — посмотрите условия и тарифы технической поддержки сайтов или свяжитесь с нами для аудита текущего состояния сервера.