Почему ваш новый сайт тормозит: бот-трафик против реальных пользователей

Пока ты пишешь лендинг и мечтаешь о первом посетителе, твой сервер уже лежит под нагрузкой — и это не пользователи. Автор разбора на Хабре развернул на скромной виртуалке текстовый агрегатор ИИ-новостей, а через неделю получил 25 000 ботов, 6 ГБ съеденной памяти и два дополнительных ядра в нагрузку. Разбираем, почему «новый сайт» — это сразу бот-трафик, и как это проверить.

Что случилось с продом

Сайт — чистый текст, без картинок, без тяжёлых вычислений. Виртуалка на шустром хосте: 64 ГБ RAM, 12 ядер, 500 ГБ SSD, канал 1 Гбит/с. Под сайт выделена пара ядер и пара гигов. Логика простая: тянет новости из 100 источников, прогоняет через LLM по API, раскладывает по 16 языковым версиям, часть — в Telegram, всё остальное — в RSS. Ничего криминального.

Через неделю — сайт «еле ползает». Автор — единственный живой пользователь. Добавил 6 ГБ памяти и ещё два ядра, чтобы просто открывалось. Открыл access-логи — увидел, что из 25 000 «посетителей» в сутки подавляющее большинство — боты. География IP — от RU до FI (два из них — сам автор с разных адресов). Вывод автора: любой свежий сайт с внятной структурой находится автоматикой за минуты, дальше начинается массовый обход.

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

Как отличить бота от юзера без магии

Cloudflare в РФ недоступен, поэтому автор пошёл собственным путём и собрал многослойный фильтр. Не одна метрика, а связка — чтобы массовому скрейперу было дорого обходить.

• Заголовки запроса. Реальный браузер присылает характерный набор — сжатие, языки, cookies, порядок полей. Парсер «под браузер» обычно прокалывается на нюансах.
• User-Agent. Явные боты (Googlebot, Bing, сервисные краулеры) учитываются отдельно, не как пользователи.
• Исполнение JS. Живой браузер выполняет скрипт и подтягивает элементы. Тупая «качалка» HTML — нет.
• Реальное действие. Скролл, клик, нажатие клавиши. Бот обычно этого не делает.
• Время на странице. Человек читает секунды–минуты, бот забирает HTML и уходит за миллисекунды.
• Обход языковых версий. Один посетитель, прошедший за сутки пять языков подряд — это машина. Реальный человек не нашёл свой язык за два клика и ушёл на английский, дальше идти незачем.
• Срез «страна × язык». Дата-центры и хостеры палятся аномалией: много языков, минимум прочтений на посетителя.

Одного признака мало — комбинация режет трафик точнее и поднимает цену обхода. Для массового бота это становится невыгодно.

Что делать на своей стороне

Сначала — увидеть картину. Логи nginx или Apache в руки, и смотрим распределение запросов по IP и странам. Если страна одна, а уникальных IP сотни в час — это не SEO-эффект, это сканер.

# Топ IP по запросам за сутки
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Доли трафика по странам (если лог уже с GeoIP)
awk '{print $country}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
# UA, которые прислали слишком много запросов
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Дальше — резать. На уровне nginx для подозрительных диапазонов:

# Пример жёсткого лимита для хостерских подсетей
limit_req_zone $binary_remote_addr zone=scrape:10m rate=2r/s;
server {
location / {
limit_req zone=scrape burst=5 nodelay;
if ($http_user_agent ~* (python-requests|scrapy|httpclient)) {
return 403;
}
}
}

Это костыль, но рабочий. На проде нормальный фильтр — связка из Nginx + fail2ban + собственные проверки (JS-challenge, fingerprint браузера, анализ поведения). Cloudflare как готовое решение — ок, если домен не для RU-аудитории.

Главный вывод автора простой: «новый сайт» — это сразу бот-трафик. Бюджет на защиту закладывай до того, как прикрутил первую метрику. И да — бэкапы. Когда бот положит базу ночью, восстанавливать будешь без выходных.