Защита сайта от ботов: шесть лет практики фильтрации трафика
С проблемой качества веб-трафика я впервые столкнулся в 2020 году, когда занимался веб-разработкой и SEO. В привычных отчётах "Метрики" внезапно появился поток однотипных визитов из социальных сетей. Формально сессии выглядели как посещения обычных пользователей, однако поведение таких "гостей" быстро выдавало автоматизацию: одинаковые сценарии, подозрительная частота переходов и полное несоответствие реальной аудитории сайта.
Иногда речь шла о 30-60 подобных визитах в сутки. Для небольшого проекта это уже было заметной долей трафика, способной исказить статистику и повлиять на оценку поведенческих факторов. Вебвизор и другие отчёты показывали, что перед нами не случайная активность пользователей, а организованный поток с повторяющимися признаками.
В тот момент многие специалисты считали такой трафик безобидным или даже полезным. Однако многолетние наблюдения на собственных проектах и сайтах клиентов давали другую картину: появление аномальных визитов часто совпадало с ухудшением SEO-показателей и снижением видимости страниц в органической выдаче. Именно поэтому защита сайта от ботов стала для меня не разовой настройкой, а отдельным направлением технической работы.
Первые эксперименты и ограничения простых методов
Первой очевидной идеей была блокировка запросов по Referer. Но такой подход оказался слишком примитивным: заголовок легко подделывается, а легитимный трафик из социальных сетей при этом можно случайно потерять. Следующим шагом стали серверные проверки JavaScript и cookie. Они помогали отделить часть автоматизированных запросов от обычных браузеров, но не остановили поток полностью.
Проверка отдельных подсетей тоже дала лишь временный эффект. После блокировки нескольких диапазонов адресов активность продолжалась уже с других IP. Особенно наглядно проблему продемонстрировал IPv6: модель, основанная на списке "плохих адресов", быстро перестала работать. Большое количество доступных адресов позволяет менять сетевой идентификатор быстрее, чем администратор успевает обновлять правила.
Цифровой отпечаток браузера также нельзя считать паспортом пользователя. Параметры окружения можно имитировать, менять или намеренно сделать похожими на отпечатки реальных посетителей. Поэтому антибот для сайта, построенный только на одном fingerprint, неизбежно будет давать ошибки.
Отдельная ошибка - считать, что скрытие ботов из "Метрики" решает проблему. Скрипт, который не отправляет данные о подозрительной сессии в систему аналитики, лишь делает отчёты чище. Он не мешает роботу обращаться к страницам, создавать нагрузку, собирать данные или влиять на серверные показатели. Фильтры аналитики не заменяют сетевую защиту и контроль запросов на уровне инфраструктуры.
Практические наблюдения за 2020-2021 годы привели к простому выводу: почти любой одиночный признак можно подменить. IP-адрес, Referer, User-Agent, cookie, JavaScript-проверку и даже часть параметров браузера нельзя использовать как единственное основание для блокировки.
От ручных правил Cloudflare к многоуровневой модели
На раннем этапе наиболее гибким инструментом для меня стал Cloudflare. После серии экспериментов стало ясно, что стандартных настроек недостаточно: требовалась собственная конфигурация правил, учитывающая специфику конкретного сайта. Такой подход позволял анализировать сочетание факторов - частоту запросов, последовательность действий, сетевые характеристики и реакцию клиента на проверки.
Со временем набор правил разросся. Одни сценарии применялись к подозрительным переходам из рекламных и социальных источников, другие - к частым обращениям к определённым URL, третьи - к нетипичным комбинациям заголовков и поведения. Постепенно Cloudflare перестал восприниматься как готовый сервис с универсальной кнопкой "защитить сайт" и превратился в платформу, на которой реализовывалась собственная логика фильтрации.
При этом постоянное расширение blacklist не решало задачу окончательно. Список заблокированных адресов увеличивался, а новые источники трафика появлялись снова. Главной проблемой стала не только точность распознавания, но и цена ложного срабатывания. Агрессивное правило способно заблокировать реального клиента, поискового робота или важный корпоративный запрос.
Более подробный разбор эволюции методов и практики настройки правил можно найти в материале о [фильтрации трафика и защите сайта от ботов](https://habr.com/ru/articles/1078860/?utm_campaign=1078860&utm_source=habrahabr&utm_medium=rss). Важная мысль заключается в том, что фильтрация должна учитывать не отдельный сигнал, а совокупность признаков и контекст конкретного ресурса.
2025 год: переход к собственной системе защиты
В 2025 году дополнительные сложности возникли из-за ограничений работы привычных зарубежных сервисов в России. Начался переходный период: тестировались доступные российские решения, сравнивались их возможности, стабильность, качество распознавания и удобство интеграции.
Практика показала, что полностью универсального продукта не существует. Одни сервисы хорошо справлялись с массовыми атаками, но хуже различали сложные поведенческие сценарии. Другие предлагали удобную панель управления, однако оставляли мало возможностей для тонкой настройки. Поэтому всё более логичным становился переход к собственной многоуровневой архитектуре.
Однокнопочная модель защиты удобна только для типовых случаев. У разных сайтов различаются аудитория, география, критичные разделы, допустимая частота запросов и последствия блокировки. Интернет-магазину важно сохранить доступ для покупателей и платёжных интеграций, медиаресурсу - выдерживать всплески просмотров, а закрытому сервису - строго контролировать авторизацию и API.
Современная защита от DDoS-атак для сайта также не должна ограничиваться поглощением объёма запросов. DDoS может быть не только мощным, но и "медленным": небольшие потоки обращений, распределённые по множеству адресов, способны расходовать ресурсы приложений, базы данных и внешних API. Поэтому необходимы разные уровни контроля - от сетевого экрана и rate limit до анализа сессий.
Архитектура защиты в 2026 году
В собственной системе я отказался от идеи устойчивого сетевого отпечатка. TLS fingerprint, включая подходы наподобие JA3 и JA4, полезен как дополнительный сигнал, но не является доказательством автоматизации. Браузеры обновляются, прокси меняют параметры, а современные инструменты автоматизации умеют имитировать распространённые клиентские профили.
Более надёжным становится анализ клиентской среды в комплексе. В него входят особенности TLS, заголовки, поддержка JavaScript, cookies, последовательность переходов, интервалы между действиями, частота обращений, география, тип устройства и связь между несколькими сессиями. Важен не сам факт наличия одного признака, а согласованность всей картины.
Даже невидимая проверка не может считаться достаточной. Если её использовать изолированно, автоматизированные системы со временем адаптируются. Гораздо эффективнее сочетать мягкие проверки, ограничение скорости, временные challenge, поведенческие профили и кластерный анализ.
Кластерная аналитика позволяет находить не только отдельного подозрительного посетителя, но и группы связанных сессий. Например, десятки разных IP могут использовать одинаковый порядок URL, близкие интервалы запросов, совпадающие параметры клиента и одинаковые ошибки выполнения JavaScript. Каждый признак по отдельности может быть нормальным, но их совокупность указывает на общий автоматизированный сценарий.
Что изменилось за шесть лет
Главный итог практики 2020-2026 годов - отказ от простых универсальных правил. Надёжная фильтрация трафика сайта строится как адаптивная система с несколькими уровнями принятия решений. Она должна уметь не только блокировать, но и замедлять, ограничивать, отправлять на дополнительную проверку и наблюдать за развитием сессии.
Важно разделять классы трафика: обычных пользователей, поисковых роботов, партнёрские интеграции, API-клиентов, подозрительные автоматизированные сценарии и явно вредоносные запросы. Одинаковое правило для всех категорий неизбежно приведёт либо к пропуску атак, либо к потере полезной аудитории.
Дополнительное значение имеет журналирование решений. Администратор должен понимать, почему запрос получил определённый статус, какое правило сработало и как изменилась оценка риска. Без прозрачной аналитики защита превращается в набор случайных исключений, которые трудно сопровождать и проверять.
Наконец, защита веб-сайта от вредоносного трафика должна учитывать не только текущую атаку, но и долгосрочную динамику. Наблюдение за изменениями поведения, регулярное тестирование правил и контроль ложных блокировок позволяют постепенно адаптировать систему к новым инструментам автоматизации. За шесть лет стало очевидно: эффективный антибот - это не отдельный модуль, а постоянно развиваемая архитектура, объединяющая сеть, приложение, аналитику и накопленные данные.
