Как мы за полдня с помощью нейросети собрали модуль защиты от ботов

Darvin Digital – digital-агентство с собственными IT-разработками для российского рынка. 17 лет cоздаём сайты и продвигаем их. В этом материале показываем, как нейросеть ускорила создание системы защиты от ботов, какие доработки пришлось внести уже после запуска и какой результат это дало нам – на реальных проектах клиентов.

В чём вообще проблема

Когда говорят о трафике на сайт, обычно представляют людей. Но у любого сайта есть ещё один поток посетителей – боты, парсеры, сервисы автоматического сканирования и другой нецелевой трафик. Они заходят на страницы не ради покупки или заявки. Задачи у них разные: от индексации и сбора данных до сканирования страниц на предмет уязвимости для взлома.

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

Как это выглядит? Сайт может тормозить или периодически падать, аналитика начинает хуже отражать реальную картину, команда вместо развития проекта уходит в постоянное тушение технических пожаров: проверяет логи, ищет источник нагрузки, разбирается, почему снова просел сервер. А бизнес продолжает платить за инфраструктуру, поддержку, продвижение, но недополучает продаж и лидов.

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

Особенно заметно это проявлялось на больших e-commerce-проектах. Когда бот начинал обходить страницы с фильтрами, категориями, подборками и другими сложными разделами, серверу приходилось тратить ресурсы не на обслуживание покупателей, а на обработку автоматических запросов. Из-за этого росла нагрузка, а вместе с ней и объём кэша, то есть заранее сохранённых версий страниц, которые сайт создаёт для ускорения работы. На отдельных проектах этот кэш разрастался до десятков гигабайт, и обслуживать ресурс становилось всё тяжелее. И на разных проектах повторялся один и тот же сценарий, который напрямую влиял и на стабильность сайта, и на время команды. Именно с этого началась вся дальнейшая история.

Почему привычные решения перестали нас устраивать и что нашли на рынке

Первым рабочим инструментом для таких задач долгое время был Cloudflare – сервис, который помогает отсеивать лишние или подозрительные запросы ещё до того, как они начинают нагружать сайт.

Но в конце 2024 года Роскомнадзор рекомендовал отказаться от Cloudflare и указал, что используемое по умолчанию расширение TLS ECH ограничивается на территории России.

А в 2025 году ситуация стала ещё серёзнее. Сотрудники Cloudflare сообщили, что с 9 июня российские провайдеры начали системно замедлять доступ к сайтам и сервисам под её защитой.

Нужно было искать другие варианты. Но довольно быстро выяснилось, что удобной замены на рынке нет. Бесплатных решений команда фактически не нашла. Платные варианты либо стоили слишком дорого даже в базовой комплектации, либо подключались сложно и долго – через менеджеров и технических специалистов. А те сервисы, которые удавалось протестировать, не всегда давали нужную гибкость для повседневной работы: нельзя было управлять тем, какие боты могут заходить на сайт, а какие должны блокироваться; где-то возникали проблемы со статистикой: часть посещений начинала выглядеть как прямые заходы на сайт.

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

Что мы пробовали до того, как перейти к работе над модулем

К идее с модулем внутри DarvinCMS команда пришла не сразу. Перед этим было несколько попыток решить проблему более привычными способами.

Первый этап был самым простым. Когда очередной сайт начинал перегружаться, разработчики шли в логи. Логи – это технический журнал, где видно, кто и как обращался к сайту. Там смотрели, какие запросы приходят чаще всего, какие страницы нагружаются сильнее других, какие боты ведут себя особенно агрессивно. Постепенно начала накапливаться база наблюдений. Стало понятно, кто именно чаще всего создает нагрузку, какие user-agent, то есть подписи ботов, регулярно всплывают на разных проектах, и по каким сценариям всё это обычно происходит. По сути, команда внимательно собирала фактуру из повторяющихся инцидентов.

Второй этап – попытка решить задачу через прокси. То есть через отдельный промежуточный сервер, который принимает трафик на себя, фильтрует его и только потом пропускает на сайт. С технической точки зрения схема работала: трафик можно было фильтровать до того, как он доходил до сайта. Но у такого подхода быстро проявился серьёзный минус – ломалась статистика. Часть источников трафика терялась, а каналы в аналитике могли сводиться в прямые заходы. Получалось, что защита есть, но данные для маркетинга и анализа уже не те.

После этого команда пошла глубже – на уровень сервера. Там, где сайт лежал на виртуальном сервере с полным доступом к настройкам, ботов действительно можно было блокировать довольно надёжно. Такой подход работал лучше: правила можно было прописывать жёстче, а лишний трафик отсекать ещё до того, как он доходил до сайта. Но и здесь быстро выяснилось, что в ежедневной работе это не самый удобный вариант. Во-первых, он зависел от конкретной инфраструктуры. Во-вторых, был довольно негибким. Если появлялся новый сценарий или новый агрессивный бот, приходилось снова идти в настройки сервера, искать доступы, править вручную, перезапускать нужные процессы. Для разового случая это терпимо. Для постоянной эксплуатации на нескольких проектах – уже нет. Кроме того, такой подход подходил не всем сайтам. Где-то был виртуальный сервер и нужная свобода действий, а где-то проект лежал на виртуальном хостинге, где возможности сильно ограничены. В таких условиях заблокировать бота на нужном уровне либо очень трудно, либо почти невозможно.

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

Выбор пал на Darvin CMS – систему управления сайтом, на которой работают проекты агентства. Если совсем просто, то это внутренняя система сайта, через которую управляют страницами, настройками и логикой работы.

Выбор в пользу нашей CMS не только технический, но и вполне прагматичный с точки зрения российских реалий. Платформа изначально была создана как собственная модульная система «всё-в-одном»: CMS, e-commerce и встроенная CRM в одной среде. Это важно, потому что в такой архитектуре проще не только управлять контентом и каталогом, а быстро добавлять прикладные инструменты под задачи проекта.

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

Если бы модуль защиты от ботов делали как отдельную внешнюю надстройку, команда снова столкнулась бы с теми же ограничениями: лишний слой между сайтом и пользователем. У разных сайтов разная структура, разная нагрузка и разные слабые места. Где-то чаще всего страдают фильтры каталога, где-то – служебные разделы, где-то – отдельные тяжёлые страницы. Когда защита размещена внутри CMS, её проще подстроить под конкретный проект. То есть речь шла уже не просто о защите, а об управляемом инструменте, который встроен в рабочую среду.

Как устроен модуль защиты от ботов и чем он удобнее внешних решений

Модуль BotGuard работает как внутренний фильтр на входе. Когда на сайт приходит новый запрос, система смотрит не только на сам факт захода, но и на его признаки: кто именно пытается открыть страницу, с какого адреса идёт запрос, к какому разделу обращаются и не похоже ли это поведение на уже известный сценарий работы бота.

Один из главных фильтров – user-agent. Это служебная строка, по которой сайт может понять, кто к нему обращается: обычный браузер, поисковый робот или автоматический сервис. Кроме user-agent модуль проверяет IP-адрес, то есть сетевой адрес источника запроса, а также сам адрес страницы, которую пытаются открыть. Если один из этих признаков совпадает с заданным правилом, система не пропускает такой запрос дальше.

Решение встроили именно в CMS не случайно. Так защиту можно быстро включать и выключать прямо внутри рабочей среды сайта. Не нужно подключать внешний прокси, поднимать отдельную сложную инфраструктуру или каждый раз идти в глубокие серверные настройки. По функциональности модуль получился достаточно гибким для повседневной работы.

Основные настройки защитника

Защиту можно просто включать и отключать. Можно блокировать запросы по user-agent, по IP-адресу, по конкретным адресам страниц и подозрительным путям. Можно отдельно отсекать заходы с пустым user-agent – это частый признак автоматического трафика. Можно задавать код ответа, который сайт будет возвращать ботам, то есть управлять не только самим запретом, но и тем, как система технически на него отреагирует.

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

В графе «Блокировка за 14 дней» можно увидеть количество заблокированных ботов

За счёт этого защита становится управляемой: можно не гадать, что именно происходит, а смотреть на факты. Чтобы сам журнал не создавал лишнюю нагрузку, для логов настраивается срок хранения. Их можно хранить ограниченное количество дней, а старые записи удалять вручную или автоматически.

Ещё одна сильная сторона – правила можно задавать не только на весь сайт целиком, но и на отдельные разделы.

Это особенно полезно на проектах, где нагрузку создают не все страницы, а конкретные «тяжёлые». За счёт этого защита получается более точной и не превращается в грубую общую блокировку.

Но на этом развитие модуля не остановилось. После запуска первой версии стало понятно, что одной блокировки по заранее заданным правилам недостаточно. Нужно было не просто останавливать уже известных ботов, но и видеть, как в целом ведет себя сайт под нагрузкой. Поэтому в модуль добавили мониторинг в реальном времени: загрузку процессора, оперативной памяти, графики за 14 дней и предупреждения о пиковых нагрузках. Это позволило следить за состоянием сайта прямо из интерфейса модуля, без постоянных заходов на сервер.

Так выглядит мониторинг внутри защитника: пиковая стартовая и текущая нагрузка, график за 14 дней

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

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

Потом всплыла ещё одна проблема: сама база событий начала быстро разрастаться. Блокировки, подозрительная активность, журнал – всё это создавало большой объём данных. Пришлось оптимизировать работу с базой. После этого модуль стал работать быстрее, в том числе в админке: журналы и статистика начали открываться заметно быстрее.

Количество блокировок только за 2 дня, не считая прочей служебной информации, с которой работает BotGuard. Такой объём данных без должной оптимизации мог бы стать дополнительной нагрузкой для сайта

Но и этого оказалось мало. На некоторых сайтах нагрузка все равно прыгала, даже когда большую часть известных ботов уже блокировали. Тогда мы пошли глубже и стали смотреть не только на самих ботов, но и на то, куда именно они ходят. Выяснилось, что сильнее всего сервер проседает из-за конкретных тяжелых страниц – в первую очередь фильтров и похожих разделов. После этого для таких страниц сделали отдельную защиту: на них стали пускать только реальных пользователей, а для ботов включили проверку по логике, близкой к невидимой капче. Пользователь этого почти не замечает, а автоматический трафик в большинстве случаев не проходит.

Точечная защита пути: боты не проходят, а обычные пользователи почти не замечают проверку

Эта доработка сработала: нагрузка начала резко падать. Но вместе с ней появилась новая проблема – на такие страницы перестали нормально попадать поисковые боты Яндекса и Google, а значит, страдала индексация. Тогда в модуль добавили белые списки. Для полезных ботов сделали отдельные исключения: они могут заходить на нужные страницы, не попадают в подозрительную активность и не режутся общими правилами. Так удалось одновременно сохранить низкую нагрузку и не потерять индексацию.

Белый список поисковых ботов: Яндекс и Google получили исключения, чтобы защита не мешала индексации

После этого всплыл еще один важный момент – статистика. Если реальный пользователь попадал под такую проверку на тяжелой странице, часть источников перехода могла искажаться. Это было критично, потому что большой процент заходов шёл как раз на фильтры и другие сложные разделы. Поэтому в модуль добавили ещё одну доработку: если человек приходит с внешнего сайта, его пропускают без проверки при первом заходе. Дальше уже включается защита. Для обычного пользователя это проходит незаметно. А вот для ботов такое исключение почти бесполезно: они, как правило, приходят напрямую, без внешнего перехода, и поэтому почти наверняка попадают под блокировку. В итоге удалось сохранить и защиту, и корректную статистику по источникам трафика.

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

На случай резкой атаки сделали и отдельный режим «Под атакой». В нем проверка включается для всех страниц сразу. Это аварийный сценарий, который позволяет быстро ужесточить защиту без ручной настройки множества правил.

Если нагрузка резко растет, модуль можно быстро перевести в режим защиты всех страниц

Для удобства работы на нескольких проектах в модуль добавили импорт и экспорт правил BotGuard. Это уже не для самой защиты, а для удобства эксплуатации: если нужный набор настроек уже собран на одном сайте, его можно быстрее переносить на другой проект, а не собирать все заново вручную.

Импорт и экспорт правил BotGuard позволяют быстро переносить готовые настройки между сайтами

Когда модуль начали использовать в работе, быстро стало ясно, что его главный плюс в том, что он собран под реальные задачи команды. Благодаря тому, что он встроен прямо в Darvin CMS, команда может быстро менять правила под ситуацию на конкретном проекте.

Как модуль показал себя на проектах клиентов

На всех проектах исходная проблема была одинаковой: автоматический трафик перегружал сайт. После внедрения модуля стало видно, что защита работает: нагрузка стабилизируется, а количество блокировок со временем начинает снижаться. Ниже – три коротких примера по проектам, где это хорошо видно на графиках.

Но итог везде похожий. После внедрения модуля сайт выходит в более стабильный режим: текущая нагрузка по CPU и RAM держится в нормальных значениях, а количество блокировок после пиков начинает снижаться. Это значит, что защита не просто фиксирует проблему, а помогает постепенно снижать её остроту на реальных проектах.

Почему на основную разработку ушло всего полдня

Фраза про «полдня на разработку» в заголовкее звучит подозрительно. Особенно когда речь идёт не о мелкой правке на сайте, а о модуле, который должен отсекать ботов. Поэтому здесь важно уточнить: задача не была маленькой и модуль в постоянной доработке. Но к моменту первичной разработки команда подошла к задаче не с пустыми руками – успела накопиться большая подготовительная база. Разработчики уже не один раз разбирали перегруженные сайты, смотрели логи, то есть технические журналы запросов, и фиксировали самых агрессивных ботов. Постепенно собрался список тех, кто чаще всего создает проблемы. Появился опыт ручной блокировки на разных проектах. Стало понятно, какие функции в будущем модуле обязательны, а без чего можно обойтись. Заодно успели проявиться и слабые места внешних сервисов: где теряется статистика, где не хватает гибкости, где все слишком сложно устроено.

То есть полдня ушло не на то, чтобы с нуля придумать защиту от ботов. Полдня ушло на сборку рабочей версии решения, к которому команда шла довольно давно. Самая сложная часть в таких задачах часто не код, а понимание, что именно нужно сделать. Здесь это понимание уже было. А нейросеть сильно ускорила процесс реализации.

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

В итоге скорость появилась из сочетания двух вещей: накопленного опыта и ИИ-инструмента. Именно поэтому на реализацию ушло полдня, хотя сама задача созревала гораздо дольше.

Не только про ботов, но и про работу с ИИ

В этом месте кейс про разработку модуля перестаёт быть только историей про защиту сайта от ботов. Он показывает больше: как команда может превращать боль в рабочий инструмент заметно быстрее, чем раньше. Да, ИИ не заменил разработчика и не решил задачу сам по себе, как обещают продавцы курсов по нейросетям. Но он помог сократить путь от идеи до рабочего результата. Обычно между пониманием проблемы и готовым инструментом – длинный путь: нужно собрать требования, написать основу, проверить логику структуры, исправить ошибки, довести решение до рабочего состояния. ИИ ускорил именно этот цикл. Не отменил экспертизу, а позволил быстрее пройти путь от замысла к прототипу, от прототипа к тестированию, а от тестирования – к инструменту, который можно использовать на реальных проектах.

Теперь небольшим командам больше не обязательно ждать, пока рынок выпустит идеальный продукт под их задачу. Если проблема повторяется, если эксперт хорошо понимает, где болит, и если требования уже можно сформулировать, порог для создания внутреннего решения становится ниже. Это очень важно в ситуациях, когда внешние сервисы либо дорогие, либо неудобные, либо слабо подходят под реальные процессы. Как в нашей истории.

Раньше в такой точке часто приходилось выбирать из двух неидеальных вариантов: либо мириться с чужим продуктом, либо откладывать задачу на потом. Теперь между этими крайностями появился третий путь – собрать прикладное решение внутри своей команды быстрее и с меньшими затратами, чем это было возможно несколько лет назад.

Этот кейс полезен не только как история про конкретный модуль. Он помогает посмотреть на то, как вообще можно решать повторяющиеся технические проблемы в бизнесе в реалиях РФ. Резюмируем ниже.

Если смотреть шире, история получилась не только про защиту от ботов. Она про более общий управленческий подход. Когда проблема повторяется, рынок не даёт удобного ответа, а команда уже накопила достаточно знаний, имеет смысл не только искать очередной внешний инструмент, но и честно спросить себя: а не проще ли собрать решение? В российских реалиях особенно ценны сайты, которые не завязаны на хрупкую внешнюю инфраструктуру и могут быстро адаптироваться под новые условия.