Как мы сжигали 400$ в месяц на чужие нейросети, или Что на самом деле происходит в ваших логах

Ноябрь прошлого года. У клиента падает интернет-магазин запчастей на 80 тысяч позиций. Сервер на Hetzner — 8 ядер, 32 гигабайта оперативки, вроде бы с запасом для среднего каталога. Симптомы банальные: в два часа ночи нагрузка на процессор улетает в полку, базы захлебываются в медленных запросах, Nginx начинает плеваться пятисотыми ошибками.

Первая реакция любого тимлида под давлением бизнеса: «Нужно масштабироваться». Арендовали вторую ноду, накинули ресурсов, настроили балансировщик. Билл вырос на 400 долларов в месяц. Помогло? Ровно на трое суток, пока нагрузка снова не догнала выделенные мощности. Проблема была не в базе, не в коде и уж точно не в реальных клиентах, которые ночью мирно спали.

Я залез в сырой access.log размером в пару гигабайт. И там творился кромешный ад.

Анатомия пустого расхода: куда уходят ядра и гигабайты

Мы привыкли думать, что боты — это Googlebot, пара краулеров Яндекса и редкие школьники со сканером sqlmap. Это опасная иллюзия. Когда открываешь реальные логи за сутки, выясняется: до 60% всего трафика на средних проектах генерируют сущности, которые никогда ничего у вас не купят.

Первая группа — генеративные платформы. GPTBot, ClaudeBot, Bytespider, CCBot. Они агрессивны. Если Google уважает директивы или хотя бы замедляется при росте времени ответа, то условный Bytespider от ByteDance идет по сайту как комбайн. Он игнорирует кеширующие заголовки, долбит в параллельные потоки и методично скачивает всё подряд. В нашем случае бот просто зациклился на бесконечной пагинации фильтра по годам выпуска деталей. Один скрипт генерировал 180 тяжелейших SQL-запросов в секунду. Простой анализ логов сайта на ботов показал, что этот единственный краулер съедал 45% процессорного времени сервера.

Вторая группа — фоновый автоматизированный шум. Это бесконечные попытки найти /.env, /wp-login.php (даже если у вас чистый Go или Django), /actuator/health, открытые дампы баз и бэкапы конфигов. Кажется ерундой: запрос вернул 404, закрыли соединение. Но когда таких запросов прилетает десять тысяч за десять минут, пул воркеров приложения тупо забивается ожиданием I/O. Реальные пользователи стоят в очереди, пока сервер вежливо объясняет сканеру из провинции Шаньси, что файла backup.sql.gz здесь нет.

Почему robots.txt больше не работает

Доверять robots.txt в текущих реалиях — все равно что закрывать квартиру на картонную задвижку. Приличные поисковики его читают. Сканеры уязвимостей используют его как карту: они смотрят в директиву Disallow, чтобы первым делом пойти именно туда, где спрятаны закрытые роуты и админки.

С ИИ-ботами ситуация не лучше. Кто-то заявляет, что соблюдает правила, но при малейшей ошибке в синтаксисе вашего файла краулер просто плюет на ограничения и начинает скрейпить сайт на максимальной скорости. Выяснить, какие ai боты посещают сайт прямо сейчас, глядя только в Google Analytics или Яндекс.Метрику, невозможно. Они не выполняют JavaScript. Их не видно в стандартных маркетинговых счетчиках. Их единственный след — строчка с User-Agent и IP-адресом в текстовом файле веб-сервера.

Безопасность сайта по логам: что искать руками

Если сервер начинает задыхаться, не спешите переписывать запросы в ORM. Откройте терминал и покрутите стандартный вывод. Базовая безопасность сайта по логам строится вокруг нескольких очевидных аномалий:

Смотрите на отношение уникальных IP к числу запросов на конкретный эндпоинт. Если с одной подсети за пять минут пришло 2000 запросов на форму поиска — это не вирусный трафик. Это скрейпинг или подбор параметров. Проверьте распределение статус-кодов. Резкий всплеск 404 и 403 кодов почти всегда означает работу фаззера, который щупает периметр по известным словарям эксплойтов. Наконец, отфильтруйте запросы с пустым или нестандартным User-Agent: питоновские библиотеки python-requests, aiohttp или консольный curl редко запускаются живыми клиентами на коммерческих витринах.

Когда мы вычистили трафик того магазина запчастей — жестко отрезали на уровне Nginx наглых ИИ-краулеров и дропнули подсети китайских облаков, методично сканировавших API — средняя нагрузка на CPU упала с 85% до 12%. Дополнительную ноду отключили на следующий же день. Мы просто перестали оплачивать вычислительные ресурсы чужих дата-центров.

Как мы устали разбирать гигабайты руками

В GuardLabs мы регулярно наступали на одни и те же грабли: приходит клиент с жалобами на производительность, и мы садимся писать скрипты на Bash и awk, чтобы отделить зерна от плевел. Тратить часы на парсинг каждого файла муторно. Заливать гигабайты клиентских логов в облачные SaaS-сервисы — плохая идея с точки зрения конфиденциальности, ведь там лежат реальные IP-адреса пользователей, внутренние токены и сессионные куки в реферерах.

В итоге мы написали инструмент под себя: локальный детектор сканеров и ботов, который исполняется прямо внутри вашего браузера. Ни один байт логов никуда не уходит по сети, всё вертится в оперативной памяти вашего компьютера через Web Workers. Если хотите без лишней рутины увидеть, кто именно подъедает ресурсы вашей инфраструктуры, попробуйте наш бесплатный инструмент: Анализатор логов сайта: какие ИИ-боты и сканеры его посещают. Загружаете свежий срез Nginx или Apache, смотрите на структуру паразитного трафика и наводите порядок в правилах файрвола до того, как хостинг выставит вам счет за перерасход.