Практический разбор 2020–2026: от поведенческих ботов и правил Cloudflare до многоуровневой защиты и кластерной аналитики трафика.
С вопросом качества веб‑трафика я впервые столкнулся в 2020. На тот момент я занимался веб‑разработкой и SEO. Когда привычную картину адекватного трафика в метрике сменил непонятный на то время шторм аномальных визитов, было непонятно, откуда это идёт и что с этим делать. В то время это проявлялось как аномально большое количество однотипных переходов на сайт из различных социальных сетей. При детальном анализе Вебвизора и других отчётов Метрики становилось понятно, что реальные люди не могут иметь такое поведение и их не может быть так много, в то время как реальный трафик сайта, который был ранее, вообще не похож на этих новых друзей из соцсетей. Так как вопрос поведенческих факторов и структуры трафика изнутри для меня были критичны, пришлось погрузиться в эту тему более глубоко. Тогда я ещё не знал, что это погружение будет таким долгим и к чему оно меня приведёт в дальнейшем. Из всего инструментария, который существовал на то время, я выбрал для меня Cloudflare, так как это был единственный инструмент, в котором я видел технический потенциал для столь сложной и непонятной на тот момент проблемы.
После многих дней анализа и экспериментов я понял, что кастомная конфигурация ручных правил фильтрации трафика в Cloudflare — это единственное, что может реально потянуть те задачи, которые вырисовывались передо мной. С того времени вышла в свет моя первая статья «Боты из соцсетей в метрике. Защита от негативной накрутки ПФ». Постепенно я дописывал эту статью, добавлял в неё уже реальные кейсы для объективного анализа. Несмотря на то что большое количество SEO‑шников и других людей, так или иначе задействованных на рынке веб‑разработки и продвижения сайтов, заявляли и убеждали друг друга в том, что этот аномальный и доколе никому невиданный искусственный трафик абсолютно безопасен для сайта и даже полезен, я всё равно продолжал анализировать, проводить эксперименты и замерять динамику SEO на множестве своих проектов и сайтов моих клиентов. Мои исследования, которые я проводил не на одном примере, а на множестве проектов, показывали одну и ту же картину: появление странного, неадекватного и непонятного трафика на сайте точно совпадало с началом падения его SEO. Происходила пессимизация позиций органики, и всё шло по примерно одной и той же схеме. На тот момент это явление не имело никакого общепризнанного названия, и этот вопрос вообще никем не поднимался, потому что это не имело массового характера до этого периода. Условно для себя я назвал это явление «поведенческими ботами», так как было понятно, что это технология накрутки поведенческих факторов, которая направлена на определённые цели.
После этого на меня обрушилось много звонков, которые нашли меня по моей статье с задачей помочь им ликвидировать этот непонятный и пугающий бот‑трафик. В процессе работы я выявил определённые закономерности, которые были практически у всех проектов по одной схеме. Сначала на сайт обрушивался огромный объём автоматизированного трафика из социальных сетей, при детальном анализе которых в Вебвизоре Метрики было ясно, что это не живые люди, а боты. При попытке блокировать вход на сайт из соцсетей эти боты сразу же автоматически меняли своё поведение и выполняли уже прямые переходы на сайт. При блокировке прямых переходов они переходили во внешние переходы с генерацией бесконечного количества внешних доменов. Имели место общие закономерности, например такие, что первая волна ботов шла из мобильного IP‑пула сети МегаФон, а при блокировке этой подсети IP‑пулы автоматически менялись, причём менялись они так, что казалось, конца и краю их IP‑географии нет. Некоторые люди пытались блокировать ПФ‑ботов через HTACCESS, что приводило к тотальной изоляции всего сайта. Цифровые отпечатки Метрики у таких визитов менялись. Было понятно, что боты генерируют и подделывают уникальные отпечатки Метрики, имитируя во время каждого захода на сайт чистую историю под видом нового пользователя.
2020–2021: начало эпохи поведенческих ботов и борьба с негативной накруткой поведенческих факторов
Первый период сейчас интересен мне не только как история. В нём очень хорошо видны почти все проблемы, с которыми фильтрация автоматизированного трафика сталкивается и сегодня: поддельный источник перехода, постоянная ротация IP, новый цифровой отпечаток пользователя, автоматическая реакция на блокировку и постоянное изменение параметров визита на сайт. Разница лишь в том, что в 2020 году всё это выглядело гораздо грубее и было заметнее в системах аналитики.
Как выглядела первая волна: 30–60 «посетителей» в сутки из социальных сетей
В моём первом подробно разобранном случае аномальная активность появилась ориентировочно в марте 2020 года. Метрика начала ежедневно показывать всплеск переходов из Twitter, Instagram, YouTube, Одноклассников, «Моего мира», Яндекс Дзена и ВКонтакте. В старой статье я фиксировал порядок величины — примерно 30–60 таких визитов в сутки. При этом на этих площадках у проекта не было опубликованных ссылок, способных объяснить такой приток посетителей из соцсетей.
Одного отчёта «Источники» было мало, поэтому я стал смотреть Вебвизор Метрики, разрешения экранов, последовательность переходов и общую картину поведения. Уже тогда бросались в глаза сочетания, которых раньше в нормальном трафике проекта практически не встречалось: странные разрешения экрана, однотипность поведения, резкие серии визитов и отсутствие какой‑либо реальной причины для массового интереса со стороны социальных сетей.
Это важный исторический момент: до этого периода времени источники переходов всегда воспринимались как достоверные и реальные, но с этого момента впервые возникла мысль: а что, если эти визиты из соцсетей — это имитация и подделка? Дальнейшие эксперименты показали, что мои предположения оказались верными.
Первое тупиковое решение: блокировать то, что показывает Referer
Один из первых экспериментов был максимально примитивным: заблокировать вход на сайт по реферерам соцсетей через.htaccess.
Естественно, такой подход не годился, так как он полностью блокировал вообще все визиты из соцсетей, включая и живых пользователей, которые шли оттуда на сайт. Даже при тотальной блокировке рефереров соцсетей проблема не решалась. Автоматически вместо визитов из соцсетей появлялись заходы с другими внешними доменами, а после дальнейших ограничений часть того же аномального трафика начинала отображаться уже как прямые входы на сайт.
То есть я получил следующие фактические результаты эксперимента: при изменении правил ограничения входа на сайт автоматически меняется и алгоритм этого аномального трафика, а именно: меняются параметры визитов. Именно тогда стало понятно, что Referer нельзя воспринимать как реально подтверждённый источник происхождения посетителя сайта. Отсюда возникла мысль, что это могут быть программные боты.
Серверная проверка JavaScript и cookie изменила картину, но не остановила поток аномального трафика
Далее я обратился к хостеру в техподдержку. На стороне сервера shared‑сервера была включена проверка, которая отсекала клиентов без поддержки JavaScript и cookie. Для 2020 года и того времени это был вполне логичный способ отделить примитивные скрипты от обычных браузеров.
После включения проверки подозрительные визиты резко перестали выглядеть как социальный трафик. Значительная часть стала отражаться как прямые входы или внутренние переходы. Иными словами, серверная проверка JavaScript/cookie не остановила поток ботов, но влияла на их алгоритм и вскрывала то, что ранее было замаскировано под другой источник перехода на сайт.
Этот эпизод сформировал принцип, который я использую до сих пор: успешное выполнение браузерной проверки — это подтверждение технической способности посетителя сайта выполнить конкретное действие, но и не доказательство того, что перед нами живой человек. Современная автоматизация умеет работать в полноценной браузерной среде, но первые признаки этой проблемы я увидел ещё тогда.
Две подсети, которые сначала выглядели как решение
После изменения серверной проверки стали заметнее сетевые источники. В одном из первых периодов основная масса подозрительных запросов концентрировалась в двух диапазонах: 31.173.80.0/21 и 178.176.64.0/19. Я добавил их в блокировку и на коротком интервале получил именно тот результат, которого тогда добивался: аномальные визиты практически исчезли из отчёта.
Но этот успех оказался локальным. В дальнейшем адреса и сети менялись. В старых материалах я описывал это как использование динамических мобильных прокси: один и тот же тип поведения появлялся с новой адресацией, а попытка расширять блок‑листы постепенно вела к конфликту с реальными абонентами и легитимными роботами. Важно и другое: принадлежность IP мобильному оператору не означает, что оператор имеет отношение к источнику автоматизации. Это всего лишь точка выхода, которую использует клиент или прокси‑инфраструктура.
Здесь впервые проявилась фундаментальная проблема IP‑блокировки: адрес удобен как технический признак, но плохо работает как долговременная идентичность. Если каждый новый запрос можно вывести через другой адрес, то ручной blacklist становится гонкой, в которой защитник всегда реагирует на уже использованную точку.
IPv6 показал, насколько быстро устаревает модель «список плохих адресов»
В 2021 году в наблюдаемом потоке стало заметно больше IPv6. В старой рабочей схеме я даже применял максимально жёсткое правило к IPv6-трафику, потому что основная модель фильтрации была заточена под накопленные IPv4-наблюдения. С сегодняшней точки зрения это хороший пример временного инженерного решения: оно может быть оправдано как диагностика, но не может быть универсальной стратегией.
Сам IPv6, разумеется, ничего не говорит о добросовестности посетителя. Практический вывод был другим: если защита держится на конкретном семействе адресов, нескольких подсетях и ручных списках, то для обхода защиты сайта достаточно постоянно менять IP‑адреса, пулы IP, ASN, через которые идёт вход на сайт.
Цифровой отпечаток тоже оказался не паспортом человека
Параллельно я анализировал цифровые отпечатки, которые были доступны в системах аналитики. В первых кейсах подозрительные визиты часто выглядели так, будто каждый новый вход принадлежит новому пользователю с новой историей. Это хорошо сочеталось с ротацией IP: новый адрес, новый отпечаток, новый источник — и каждый отдельный визит внешне слабо связан с предыдущим.
В старых публикациях я писал, что «ПФ‑боты» подделывают fingerprint. Основанием для такого вывода было то, что у большого количества однотипных бот‑визитов цифровой отпечаток постоянно менялся. Каждый новый заход мог выглядеть для системы как новый браузер или новый пользователь. Независимо от того, каким именно способом это достигалось — изменением параметров клиентской среды, запуском новых браузерных профилей или другими механизмами, — практический результат был одинаковым: использовать fingerprint как единственный устойчивый идентификатор такого трафика было невозможно.
Термины «ПФ‑боты» и «поведенческие боты» в то время я использовал условно, чтобы отделить этот новый класс автоматизации от классических ботов и краулеров. Речь шла уже о системах, которые не просто автоматически обходили страницы сайта, а старались имитировать живого пользователя: меняли сетевые и клиентские признаки, переходили между страницами и выполняли определённые действия на сайте. В 2020 году устоявшейся терминологии для такого трафика ещё не было, поэтому в своих публикациях я использовал собственные рабочие обозначения. Позже термин «ПФ‑боты» и «поведенческие боты» получил широкое распространение.
Скрыть поведенческих ботов из Метрики — не значит остановить их
В 2020 году параллельно с попытками технической блокировки в интернете распространялся гораздо более простой совет: если подозрительные визиты идут с определённых IP‑адресов или диапазонов, их можно исключить из статистики Яндекс Метрики. Визуально результат действительно выглядел убедительно — нежелательный трафик переставал попадать в отчёты, показатели становились чище и могло создаваться впечатление, что проблема решена.
Именно этот подход я тогда критиковал в своих публикациях. Я называл его «визуальным самообманом», потому что менялось только то, что видел владелец сайта в интерфейсе аналитики. Сам бот при этом никуда не исчезал. Его соединение продолжало доходить до веб‑сервера, запрос обрабатывался сайтом, а все действия оставались видны уже не в отчёте Метрики, а, например, в серверном access log.
С инженерной точки зрения это были две совершенно разные операции. Исключение IP из системы аналитики означает примерно следующее:
бот → сайт → веб‑сервер → приложение → Метрика не учитывает визит
Реальная фильтрация должна решать другую задачу:
бот → фильтрация → запрос не допускается к защищаемому ресурсу
Разница принципиальная. В первом случае можно получить красивую статистику, но сервер продолжает принимать и обрабатывать нежелательные обращения.
Была и вторая проблема. Уже тогда интересующий меня трафик активно использовал динамически меняющиеся адреса, в том числе мобильные IP‑пулы. Поэтому исключать отдельные IP было практически бессмысленно: сегодня запрос приходит с одного адреса, через некоторое время — уже с другого. Но и исключать из аналитики целую мобильную подсеть было плохим решением. В тех же адресных пулах находятся обычные пользователи мобильного оператора, поэтому вместе с ботами из отчётов начинают исчезать и реальные посетители. Именно на это я отдельно обращал внимание в старой статье.
Получалась довольно странная ситуация: чем агрессивнее администратор «очищал» Метрику по IP‑диапазонам, тем красивее могла становиться картинка в аналитике, но тем меньше она соответствовала реальному трафику сайта. При этом фактическая нагрузка от автоматизированных запросов не уменьшалась, потому что сами обращения продолжали доходить до веб‑сервера.
Скрипт, скрывающий Метрику от ботов, тоже не решал проблему
В то время встречался ещё один способ борьбы с поведенческими ботами, который сильно пиарился и некоторым казался решением проблемы с ботами. На сайт устанавливался скрипт, задача которого заключалась не в блокировке самого бота, а в том, чтобы не показывать ему счётчик Яндекс Метрики. Если посетитель определялся как бот, Метрика для него не срабатывала и его визит просто не появлялся в статистике.
Для владельца сайта результат мог выглядеть почти идеально. До установки скрипта в Метрике были десятки подозрительных визитов, после установки они исчезали. Возникало естественное ощущение: «ботов больше нет».
Но на техническом уровне бот никуда не исчезал.
Он по‑прежнему устанавливал соединение с сайтом, запрашивал страницы, обращался к веб‑серверу и приложению, мог обходить страницы, собирать данные, создавать нагрузку или выполнять другие автоматизированные действия. Изменилось только одно — Яндекс Метрика переставала сообщать владельцу сайта о существовании этих визитов.
Это легко было перепутать с реальной защитой, если смотреть только на интерфейс аналитики. Серверный access log при этом продолжал фиксировать обращения. Получалось, что автоматизированный трафик фактически продолжал существовать, но становился менее заметным для администратора.
С инженерной точки зрения не зафиксировать визит в системе аналитики — не то же самое, что не допустить запрос к сайту.
Поэтому уже тогда я относился к таким решениям скептически, и сразу было понятно, что это самообман для тех, кто хочет прятать голову в песок, и не более того. Такие решения могли сделать отчёты Метрики визуально чище, но не решали саму задачу фильтрации трафика. Для защиты сайта важно не то, появился ли бот в отчёте, а дошёл ли его запрос до защищаемого ресурса и что произошло после этого.
Фильтры Метрики не заменяют сетевую фильтрацию
Отдельный эксперимент в 2020 году был связан со встроенной фильтрацией роботов в Яндекс Метрике. Я обратился в техническую поддержку Яндекса и получил рекомендацию включить в настройках счётчика опцию «Фильтровать роботов по строгим правилам и поведению». Я включил её и продолжил наблюдение за тем же аномальным потоком. Практического изменения не произошло: характерные визиты продолжали фиксироваться примерно в прежнем объёме, а со временем их количество доходило примерно до 60 в сутки.
Этот эксперимент помог разделить две совершенно разные задачи. Яндекс Метрика — система веб‑аналитики. Она может определять, учитывать или не учитывать визиты как роботные в своих отчётах, но сама по себе не является средством сетевой фильтрации входящих запросов к сайту. Даже если нежелательный визит перестанет отображаться в отчёте, HTTP‑запрос всё равно может дойти до веб‑сервера и быть обработан приложением.
Поэтому «не видеть бота в аналитике» и «не пропустить автоматизированный запрос к сайту» — принципиально разные результаты.
Что я тогда наблюдал в SEO — и как оцениваю это сейчас
Параллельно с аномальным трафиком на моём первом проекте началось заметное снижение органических позиций. Позже похожую временную связь я наблюдал и на других проектах: возникает долгосрочный автоматизированный трафик, похожий на «ПФ‑ботов», ухудшаются поведенческие показатели, а через некоторое время и часто даже сразу проседает органика. Именно эти повторяющиеся наблюдения и заставили меня продолжать исследования, когда значительная часть SEO‑сообщества считала такой трафик безвредным. Некоторые SEO‑шники убеждали себя и всех в том, что поведенческие боты даже идут на пользу сайту. До сих пор и сегодня есть лагерь SEO‑шников и других IT специализирующихся на веб‑разработках и веб‑трафике людей, который считает, что любой автоматизированный трафик идёт сайту на пользу, что блокировать поведенческих ботов нельзя и вредно, что это снижает конверсию, SEO‑позиции сайта и прочее.
В то время я занимался только веб‑разработкой и SEO, не имея никакого отношения к услугам веб‑безопасности и фильтрации трафика. Поэтому у меня не было мотива и цели вводить людей в заблуждение. Я работал по проектам по их белому SEO‑продвижению и нёс персональную ответственность за судьбу позиций органики сайта не только в краткосрочном периоде, но и в долгосрочном. Я никогда не был сторонником серых и чёрных методов SEO, таких как накрутка поведенческих факторов ботами и другими манипуляциями, которые накладывали на проект риски попадания в бан поисковых систем, что могло в любой момент обнулить весь проект и всю многолетнюю SEO‑работу. Я стремился к концепции, в которой SEO всегда должно было быть белым и честным как по отношению к самому проекту, так и по отношению к его конкурентам. При этом, конечно, далеко не все придерживались такой моей SEO‑идеологии.
На большом количестве веб‑проектов я видел одну и ту же закономерность: появление аномального автоматизированного трафика по времени совпадало с ухудшением позиций в поиске. При этом я не утверждаю, что один график Яндекс Метрики сам по себе способен доказать прямую причинно‑следственную связь. На SEO одновременно влияет множество факторов. Тем не менее для меня и моих проектов, с которыми я работал, целесообразность защиты трафика и обеспечение чистоты трафика была как минимум хотя бы по этим причинам: если трафик сайта явно не похож на живую аудиторию, меняет своё поведение после блокировок, создаёт нагрузку и искажает аналитику, его необходимо анализировать независимо от того, какой именно вес он имеет в поисковом ранжировании. Если имеется фактор автоматизированного трафика, бот‑трафика, который делает аналитику сайта некорректной, то это уже не может быть нормой и требует качественного исправления.
Итог 2020–2021: почти все одиночные признаки можно было изменить
К концу первого этапа у меня накопилась уже не теория, а последовательность собственных неудачных и удачных экспериментов. Блокировка по Referer заставляла поток бот‑трафика менять источник. Блокировка конкретных подсетей давала временный эффект, но адреса ротировались. Серверная браузерная проверка ничего не давала, кроме блокировки нужных сервисов, которые должны были подключаться к сайту. Аналитические фильтры Метрики не решали задачу по ликвидации «ПФ‑ботов» на сайте. Цифровые отпечатки, формируемые в Метрике, не позволяли устойчиво идентифицировать посетителя.
Наблюдение 2020–2021 | Что я пробовал | Что происходило после изменения |
Переходы якобы из соцсетей | Блокировка по Referer | Появлялись новые внешние источники или прямые входы |
Концентрация в отдельных IP‑сетях | Блокировка подсетей | Автоматическая смена IP, ASN и отсутствие стабильного долгосрочного результата |
Примитивные и браузероподобные клиенты | Проверка JavaScript/cookie | Поведенческие боты меняли свой алгоритм, но продолжали идти на сайт |
Высокая изменчивость идентификаторов | Сопоставление цифровых отпечатков | Каждый отдельный визит выглядел как новый клиент |
В бот‑трафике появился IPv6 | Отдельные правила для IPv6-трафика и дополнительная Challenge‑проверка | IP‑адреса и сети продолжали меняться, поэтому привязка защиты к отдельным адресам не давала устойчивого результата |
Именно после этого Cloudflare перестал быть для меня просто CDN или внешним сервисом. Он стал рабочей платформой, на которой я мог собирать всё больше собственных WAF‑правил и проверять их уже на разных сайтах.
2022–2024: модернизация конфигурации правил фильтрации в Cloudflare
В начале Cloudflare‑периода логика WAF‑правил была сравнительно простой. Если подозрительный поток виден из определённых сетей — работаем с сетью. Если источник явно поддельный — учитываем Referer. Если целый класс трафика в конкретный момент не удаётся надёжно классифицировать — выдаём дополнительную проверку. Были отдельные исключения для поисковых систем и служебных запросов.
Когда штатные проверки Cloudflare перестали быть достаточными
На первых этапах я активно использовал встроенные в Cloudflare механизмы дополнительной проверки посетителя. И довольно быстро обнаружилось, что разные варианты проверки дают совершенно разный результат против поведенческой автоматизации.
Автоматическая невидимая проверка была практически незаметна для обычного пользователя, что являлось её большим преимуществом, но невидимая проверка оказалась бесполезна против «ПФ‑ботов». На всех проектах интересующий меня бот‑трафик проходил такую проверку, менялся только источник перехода в Метрике. Визиты поведенческих ботов, которые прошли невидимую Challenge‑проверку Cloudflare, фиксировались в Метрике как внутренние переходы. Пришлось искать более жёсткие проверки Cloudflare, чтобы остановить ботов.
Следующим уровнем была интерактивная проверка Cloudflare. Пользователю показывалось задание, в том числе с последовательным выбором изображений. Для живого посетителя такая проверка могла быть настолько долгой и раздражающей, что сама защита начинала становиться проблемой для сайта. Многие люди просто не стали бы проходить несколько раундов такой проверки ради того, чтобы открыть обычную страницу. В будущем эту адскую капчу в Cloudflare заменили на очень простую, в которой посетителю нужно было только поставить одну галочку о том, что он человек, а не бот.
При этом против поведенческих ботов это было эффективно. На большинстве проектов такая проверка действительно останавливала тот поток, который свободно проходил автоматические механизмы. Однако со временем появились проекты, на которых часть поведенческой автоматизации начала проходить даже эту интерактивную проверку.
Защитный механизм, который ещё недавно выглядел практически непреодолимым для автоматизации, постепенно переставал быть таким. Приходилось исходить уже не из предположения «бот не сможет выполнить это действие», а из более неприятного сценария: если механизм массово применяется на популярных сайтах, рано или поздно автоматизация научится работать и с ним.
Подобную картину я наблюдал не только в Cloudflare. В старых исследованиях я фиксировал прохождение поведенческими ботами JavaScript‑проверок и различных распространённых интерактивных проверок. На отдельных проектах было видно большое количество сквозных проходов автоматизированного трафика через установленную проверку.
На наиболее проблемных проектах мне пришлось использовать следующий метод. Я подключал платный тариф Cloudflare, использовал возможность Custom Pages и вместо стандартной страницы интерактивной проверки подставлял собственную самописную страницу со своей проверкой. Она отличалась от массового стандартного механизма Cloudflare и полностью останавливала тот бот‑трафик, который уже научился проходить штатные проверки.
Это не было универсальным или вечным решением. Скорее наоборот — этот эпизод хорошо показал мне характер самой гонки. Сначала автоматизация проходит простые проверки, затем более сложные. Распространённый защитный механизм становится известной целью, под которую начинают адаптироваться инструменты автоматизации. После этого защите снова приходится менять логику.
Именно поэтому к этому периоду я окончательно перестал воспринимать какой‑либо один Challenge как самостоятельное решение проблемы. Важным становилось уже не наличие одной «сложной проверки», а возможность сочетать разные признаки, применять разные сценарии к разным классам трафика и постоянно менять конфигурацию вслед за поведением автоматизации.
Сохранившиеся у меня ранние конфигурации Cloudflare хорошо показывают этот этап. Например, в 2021 году у меня существовало отдельное правило для IPv6, которое направляло весь такой трафик на дополнительную проверку. В другом правиле отдельно разрешались переходы с признаками Яндекса и Google. Сейчас такие решения выглядят слишком широкими, но именно так и развивается рабочая система: сначала выделяются крупные классы, затем каждый из них дробится по мере появления ложных срабатываний и новых наблюдений.
От нескольких правил к разным сценариям трафика
По мере работы на разных проектах стало понятно, что «прямой трафик», «внешний трафик» и «органику» нельзя обрабатывать одинаково. У каждого класса своя нормальная структура. Для интернет‑магазина естественны AJAX‑запросы, фильтры каталога и интеграции. Для корпоративного сайта критичны формы и CRM. Для проекта с большим SEO‑трафиком особенно опасно случайно ограничить поискового робота или часть реальных переходов из поиска.
В результате конфигурация Cloudflare начала разрастаться не только по количеству запретов, но и по количеству исключений. Появлялись отдельные правила для URL и методов, списки доверенных сетей, User‑Agent, география, условия для поисковых роботов, правила для прямых и внешних заходов, отдельное отношение к служебным запросам и формам. Важнее всего было не число правил, а их взаимное влияние: изменение одного условия могло неожиданно изменить прохождение другого класса трафика.
Это уже было ближе к эксплуатации сети, чем к установке готового «антибота». После каждого изменения нужно было смотреть Метрику, серверные события, жалобы пользователей, работу форм, поисковую индексацию и только потом решать, стало лучше или хуже.
Почему blacklist становился всё менее ценным, хотя продолжал расти
IP‑списки при этом никуда не исчезли. Они полезны для очевидных источников сканирования, повторяющегося спама и устойчивых инфраструктурных диапазонов. Но опыт первых лет уже показал, что в поведенческой автоматизации адрес быстро устаревает. Поэтому к концу Cloudflare‑периода blacklist был лишь одной из частей системы, а не её центром.
Масштаб накопления хорошо виден по одному из моих рабочих списков: к 2025 году в нём было несколько тысяч записей. Само число не является показателем качества защиты. Наоборот, для меня оно стало иллюстрацией того, почему нельзя бесконечно решать динамическую задачу статическим списком. Тысячи записей требуют контроля актуальности, исключений и понимания того, не задел ли очередной диапазон легитимный трафик.
Сам по себе чёрный список применялся, конечно, не для тотальной блокировки, а для проверки трафика из определённых IP‑пулов. Живые люди, которые попадали в общие пулы с поведенческими ботами, могли зайти на сайт, пройдя капчу Cloudflare.
Главной проблемой стала не только точность, но и цена ложного срабатывания
Чем больше сайтов проходило через фильтрацию, тем сильнее менялась постановка задачи. В 2020 году вопрос звучал просто: «как остановить этот странный поток?». В 2023–2024 годах этого уже было мало. Нужно было остановить нежелательную автоматизацию так, чтобы владелец сайта не получил взамен новую проблему: неработающую форму, сломанный API, потерянную индексацию или недовольного клиента.
Отдельно росло требование к удобству реального посетителя. Самый устойчивый способ подтвердить присутствие человека — попросить его выполнить явное действие. Но бизнес закономерно не хочет показывать лишний экран проверки каждому входящему пользователю. Для магазина это риск конверсии, для рекламного трафика — дополнительная потеря уже оплаченного клика, для обычного корпоративного сайта — просто раздражение.
Поэтому конфигурация усложнялась сразу в двух направлениях: боты становились технически сильнее, а владельцы сайтов требовали всё меньше видимых проверок. Это принципиально разные причины. Если учитывать только задачу остановки поведенческих ботов, то легко построить очень жёсткую защиту, которая усложняет работу живым пользователям.
Задача | Если решать её в отрыве от остальных | Что приходилось делать на практике |
Максимально остановить автоматизацию | Усилять проверки для всех | Отделять рискованные сценарии от обычного трафика |
Не мешать живым пользователям | Убирать дополнительные проверки | Компенсировать это другими наблюдениями и исключениями |
Не ломать сайт | Разрешать всё спорное | Делать индивидуальные правила для CMS, форм, API и интеграций |
Сохранить управляемость | Не добавлять новые условия | Постоянно пересматривать и упрощать накопившуюся конфигурацию |
Почему к 2024 году Cloudflare был уже не «готовым сервисом», а средой для моей логики
К этому моменту значительная часть результата зависела уже не от того, что Cloudflare умеет «из коробки», а от того, как именно собрана конкретная конфигурация. Два сайта с одинаковой платформой защиты могли показывать совершенно разный результат, если для одного учитывались реальные источники, формы и поисковые роботы, а для второго просто включался универсальный набор блокировок.
С инженерной точки зрения это был важный этап. Cloudflare дал удобный слой управления веб‑трафиком и возможность быстро проверять гипотезы, но одновременно показал предел подхода, в котором вся логика живёт внутри возможностей и интерфейса внешней платформы. Чем больше становилась собственная логика, тем сильнее хотелось управлять не только правилами, но и самим способом сбора событий, аналитикой и реакцией системы.
2025: ограничения работы Cloudflare в России и переход к собственной системе защиты
К 2025 году к чисто техническим причинам добавился инфраструктурный фактор. Доступ к ресурсам, использующим Cloudflare, из российских сетей стал работать нестабильно. В официальном техническом разборе от 26 июня 2025 года Cloudflare сообщала, что с 9 июня наблюдает ограничения со стороны российских операторов связи: сбросы соединений, тайм‑ауты и механизм, при котором часть соединений фактически переставала передавать данные после первых примерно 16 КБ. Для владельца российского сайта причина конкретного ограничения в практическом смысле вторична. Если критическая внешняя платформа перестаёт гарантированно работать между пользователем и сайтом, это становится риском доступности независимо от того, кто прав в споре о причинах. С точки зрения эксплуатации проблема простая: часть тракта находится за пределами контроля владельца проекта. С точки зрения российского веб‑проекта эта ситуация выявила более фундаментальную проблему зависимости от иностранной инфраструктуры. Можно спорить о причинах и обоснованности конкретных ограничений, но инженерный вывод для меня оказался другим: критическая система защиты российского сайта не должна полностью зависеть от зарубежной платформы.
Я не считаю Cloudflare плохой технологией, но и не считаю её лучшей в своей области. На мой взгляд, Cloudflare стал для меня первым уровнем в развитии сетевой фильтрации и WAF‑экранирования веб‑трафика. На протяжении многих лет работы с Cloudflare я находил большое количество дефектов в его работе, которые документировал, подробно описывал, рисовал сложные схемы, потратив на это огромное количество времени своей жизни. Все задокументированные мной баги, дефекты и недоработки Cloudflare я отправлял в техническую поддержку этого сервиса, общался со специалистами, добивался эскалирования моих тикетов, но в конечном итоге получал один и тот же результат: полное отсутствие каких‑либо доработок, реальных изменений и исправлений в сервисе Cloudflare. Все многократные тикеты и их эскалации в итоге не приводили ни к чему. Я видел абсурдную, на мой взгляд, систему обработки заявок в тикет‑системе Cloudflare, в процессе которой моя заявка переходила через огромное количество сотрудников. Они благодарили меня, желали всего доброго, доброго дня, доброй ночи, но в итоге — ноль, полный ноль. Тогда я понял, что для реализации качественного инструмента — такого, как его понимаю я и как привык понимать качество на протяжении всего своего профессионального пути в IT, — Cloudflare, вне всяких сомнений, не был и никогда не будет для меня подлинно качественным продуктом.
Получается своеобразное продолжение моей первой статьи на Хабре о эволюции сети доступа в интернет в Павловском узле связи: там я рассказывал об эволюции сети и Интернета, а здесь — уже об эволюции моей собственной работы с веб‑трафиком и защитой сайтов. Все мои идеи, мысли и задумки возможно воплотить в жизнь только в том случае, если я сам разработаю свой продукт, свой инструмент для фильтрации веб‑трафика. Пять лет работы с Cloudflare дали мне огромную практическую школу: от самых примитивных IP‑ и Referer‑правил до сложной конфигурации с большим количеством условий, исключений и сложной логики обработки веб‑трафика. Но к 2025 году одновременно со сложностью фильтрации выросла цена инфраструктурной зависимости. Наступил сложный переходный этап, где мне нужно было либо выбирать из существующих российских решений, либо разрабатывать свою систему фильтрации трафика от поведенческих ботов, спама, парсеров, взлома, вредоносного трафика.
Источник по этому эпизоду: Cloudflare Blog, 26.06.2025 — «Russian Internet users are unable to access the open Internet».
Переходный этап: тестирование существующих российских сервисов защиты
До того как начинать разработку собственной системы, я не стал исходить из предположения, что на российском рынке нет подходящих решений. Сначала я решил проверить уже существующие сервисы на практике. Я подключал и тестировал ряд популярных решений этого класса на разных проектах, смотрел не только на то, что написано на главной странице сервиса, но и на фактический результат: какой трафик проходит, какой останавливается, что происходит с живыми пользователями и насколько система остаётся управляемой после включения. Создавал различные правила и настройки в кабинетах сервисов, наблюдал за практическими результатами фильтрации трафика, оценивал и тестировал качество работы сайта в целом и его доступность в разных сегментах сети.
Названия сервисов здесь намеренно не привожу. Для этой статьи важнее не спор конкретных брендов, а инженерные выводы, которые я получил в процессе тестирования разных подходов.
За годы работы я не раз замечал, как идеи, формулировки и концепции, которые я самостоятельно разрабатывал и публично описывал, спустя некоторое время появлялись у других участников рынка уже в очень похожем виде. Спорить по этому поводу я не вижу смысла. Для меня гораздо важнее всегда было создавать собственные решения, развивать свои инженерные идеи и отличаться от подхода, при котором проще наблюдать за чужой работой и повторять уже найденные кем‑то решения, чем создавать что‑то своё.
На протяжении многих лет работы с фильтрацией трафика мне также неоднократно писали люди, которые представлялись потенциальными клиентами, но по характеру вопросов было видно, что их интересует прежде всего внутренняя логика работы системы, архитектурные решения, особенности фильтрации и детали реализации. Я не могу достоверно знать мотивы каждого такого обращения, поэтому не хочу превращать эту статью в обвинение кого‑либо. Но сам факт подобных ситуаций ещё сильнее убедил меня в том, что техническое преимущество нельзя строить только на открытом наборе правил, формулировок или отдельных приёмов — его нужно создавать постоянно развивающейся инженерной системой.
Именно здесь особенно сильно проявилось различие подходов. На рынке неизбежно есть компании, для которых в первую очередь важны продажи, упаковка продукта и масштабирование бизнеса. В этом нет ничего необычного. У меня же мотивация всегда была другой: мне было важно прежде всего довести технический продукт до состояния, при котором я сам могу считать его качественным, эффективным, стабильным и инженерно обоснованным.
Возможно, это не самый быстрый путь к коммерческому успеху. Но я всю жизнь оставался прежде всего сетевым инженером и привык относиться к своей работе серьёзно. Для меня профессионализм — это не название должности и не маркетинговая формулировка, а ответственность за результат, постоянное развитие и стремление делать свою работу лучше.
Поэтому путь создателя для меня всегда был важнее пути простого продавца. Мне было интереснее построить сложный технический продукт, развивать его собственными силами и добиваться того, чтобы его качество подтверждалось реальной эксплуатацией, а не только рекламным описанием.
Что показали практические тесты
Начиная примерно с 2024 года на IT‑рынке России появилось большое количество самостоятельных сервисов защиты сайтов от ботов, уже не привязанных к Cloudflare. В описаниях многих решений акцент делался на автоматической и «невидимой» защите: владелец сайта подключает сервис, а дальше система должна сама отделять людей от автоматизации без дополнительных действий со стороны посетителя. На практике я не увидел режима, который можно было бы один раз включить и после этого больше не сопровождать. Более того, различные варианты конфигурации настроек обработки трафика приводили к возникновению критических проблем, таких как тотальная блокировка живых людей без возможности вообще зайти на сайт. При более глубоких настройках увеличивалось количество ошибок в консоли браузера, что говорило о некорректной работе проксируемого сайта по причине фильтрации трафика.
На некоторых сервисах, которые вообще обещали полностью автоматизированную блокировку ботов без каких‑либо настроек, картина была ещё более печальной. Большая часть поведенческих ботов спокойно проходила на сайт, а значительная часть живых людей получала тотальные блокировки без какой‑либо возможности попасть на сайт. Это был лишь первый уровень тестирования сервисов защиты. Далее я уже тестировал фильтрацию трафика не только визуально, но и оценивал работу пропуска или блокировки поисковых краулеров, тех или иных нужных для веб‑проекта технических сервисов, проверял, как работает сайт при выполнении скриптов, AJAX‑запросов, POST‑запросов и множества других технических частей сайта, которые на первый визуальный взгляд не бросаются в глаза. То есть практически фильтрация любого веб‑трафика всё равно оставалась постоянной инженерной работой. Для меня отсюда сформировался важный вывод: невидимость проверки для пользователя сама по себе не является показателем качества. Если защита незаметна одному человеку, это не значит, что она незаметна кому‑то другому, а таких других — тысячи и миллионы в сети. Если защита незаметна, но ломает корректную работу технических частей движка сайта и других сетевых процессов, то она неприемлема для реальной веб‑эксплуатации. Если она рандомно, наугад, по нестабильным плавающим признакам блокирует всё подозрительное и вместе с ботами отрезает реальных пользователей, это тоже плохой результат. Качество находится в балансе между полнотой фильтрации, ложными срабатываниями и возможностью легитимного посетителя подтвердить себя. А самое лучшее качество — это минимизация необходимости подтверждать себя живыми пользователями, что является сегодняшним требованием комфортной и качественной работы целевой аудитории на сайте.
В результате вместо обещанной «одной кнопки» или чудесной блокировки ботов по слепкам и тому подобного снова остро вставала техническая и инженерная задача: реализовать гибридную систему фильтрации трафика, которая объединит в себе всё самое лучшее от Cloudflare, впитает в себя все мои новые инженерные идеи, которые невозможно было реализовать там, а также позволит постоянно модернизировать эту систему, усложняя её, повышая уровень качества, надёжности, точности, стабильности, предсказуемости и, главное, возможности глубочайшей конфигурации правил сетевой фильтрации, которая будет превосходить всё то, что было у меня раньше.
Что из существующих подходов я счёл действительно полезным
При этом сами тесты были для меня полезны. Я не пришёл к выводу, что всё существующее на рынке было бесполезным. В некоторых технических решениях существующих сервисов защиты встречались отдельные подходы, в которых я видел концептуальный потенциал. При их доработке и объединении с моими собственными решениями они могли дать хороший результат. Я смотрел на это не как на готовую систему, которую нужно повторить, а как на набор инженерных идей: что действительно останавливает автоматизацию, где появляются ложные срабатывания, насколько хорошо система переживает изменение характера трафика и что происходит с посетителем в спорной ситуации.
Постепенно у меня сформировался набор требований к собственной системе. Фильтрация должна происходить до защищаемого ресурса; решение не должно строиться на одном IP‑адресе, одном цифровом отпечатке или одной невидимой проверке; разные классы трафика должны обрабатываться по‑разному; а сомнительный, но не однозначно вредоносный посетитель должен иметь возможность пройти дополнительную проверку, а не попадать в безвыходную блокировку.
Не менее важным оказался эксплуатационный вопрос. Я не хотел строить сервис, в котором владелец сайта после подключения должен ежедневно самостоятельно разбираться в порогах, исключениях и изменившемся поведении ботов или отдельно искать специалиста для постоянной донастройки. Если защита требует инженерного сопровождения, то это сопровождение должно быть частью самой системы и услуги, а не проблемой клиента.
После этого выбор для меня окончательно сузился. Мне не удалось найти готового решения, которое одновременно соответствовало бы моим требованиям к точности фильтрации, контролю ложных срабатываний, гибкости логики и модели эксплуатации. Поэтому следующим этапом стала уже не настройка чужой платформы и не поиск очередного сервиса, а разработка собственной системы.
CronArmor: переход к собственной системе многоуровневой защиты
Новая система изначально проектировалась не как копия Cloudflare или какого‑либо из протестированных российских сервисов. За несколько лет сама задача стала значительно шире борьбы только с поведенческими ботами. Мне требовалась система защиты сайта от нескольких классов нежелательного и вредоносного трафика: распределённых парсеров, сканеров, попыток взлома, AI‑краулеров, поддельных поисковых роботов, спам‑ботов, спама с форм и поведенческой автоматизации, вредоносного трафика. Именно этот более широкий набор задач и определил направление развития CronArmor.
Для моих задач собственная система оказалась принципиально удобнее прежней модели не потому, что существует одно «секретное» правило. Главное преимущество — полный контроль над тем, какие события собирать, как сопоставлять их между собой, какие профили применять к разным сайтам и как быстро менять логику после появления новой формы автоматизации. Аналитика и фильтрация здесь развиваются как одна система, а не как два независимых продукта.
Почему я не строю CronArmor как «однокнопочную» защиту
CronArmor я строил не как систему, которую можно описать формулой «включил один переключатель — и проблема решена». Профиль защиты зависит от конкретного проекта, а сопровождение является частью эксплуатации: трафик наблюдается, изменения поведения автоматизации учитываются, а профиль защиты корректируется NOC‑инженером по мере необходимости. В такой модели постоянная инженерная работа не перекладывается на владельца сайта.
Отдельный принцип — не оставлять легитимного пользователя в безвыходной блокировке только потому, что один из сигналов оказался подозрительным. Если запрос не относится к однозначно вредоносному классу, система должна иметь возможность перейти к дополнительной проверке, а не превращать сомнение в окончательный запрет. Именно поэтому я не рассматриваю ни один IP, цифровой отпечаток или одну невидимую проверку как окончательный вердикт.
Цель при этом — максимально приблизить очищенный трафик к реальной аудитории. Я сознательно не формулирую это как «100% защиты», потому что без заранее определённой методики измерения такая цифра превращается в рекламный лозунг. На практике качество я оцениваю по совокупности данных: серверным событиям, структуре трафика, ложным срабатываниям, обращениям пользователей и тому, что остаётся после фильтрации.
Почему я не делаю один профиль защиты для всех сайтов
К этому времени окончательно исчезла идея, что существует одна правильная строгость для любого проекта. На части сайтов наиболее надёжным вариантом остаётся интерактивная проверка присутствия пользователя. На других сайтах бизнес‑требование прямо противоположное: максимально сократить видимые действия и перенести основную оценку в невидимые проверки клиентской среды.
Это не вопрос «старого» и «нового» метода. Это выбор между ценой ошибки и ценой дополнительного действия. Если форма заявки приносит одну дорогую заявку в день, можно позволить себе более строгую проверку. Если на интернет‑магазин приходит большой платный трафик, лишнее действие для каждого человека может стоить дороже, чем небольшой процент пропущенной автоматизации. Поэтому профиль должен соответствовать сайту, а не модному названию технологии.
Какие классы трафика современная защита должна хотя бы различать
К 2026 году выражение «бот» стало слишком общим. В один и тот же час к сайту могут обращаться совершенно разные автоматические клиенты, и блокировать их одной логикой бессмысленно.
Класс трафика | Пример задачи / поведения | Почему нельзя применять одно решение |
Проверенные поисковые роботы | Индексация и служебные обходы | Их блокировка напрямую вредит доступности сайта для поиска |
Поддельные поисковые роботы | User‑Agent имитирует Google/Yandex | Имя в User‑Agent ещё не подтверждает происхождение |
AI‑ и сервисные краулеры | Сбор контента, поиск, обучение/индексация | Для разных владельцев сайта политика допуска может отличаться |
Коммерческие парсеры | Массовый обход каталогов, цен и контента | Часто выглядят как обычные браузеры, меняют IP и распределяют запросы по большому количеству адресов |
Сканеры | Поиск открытых панелей, известных путей, версий CMS, уязвимых компонентов и служебных URL | Важна совокупность URI, частоты запросов, сетевого поведения и признаков автоматического перебора |
Вредоносный трафик и веб‑атаки | SQL‑инъекции, XSS, попытки обхода путей, LFI/RFI, выполнение команд и другие классы вредоносных HTTP‑запросов | Здесь важнее содержимое самого HTTP‑запроса и признаки атаки, выявляемые WAF, чем поведенческая идентификация клиента |
Поведенческая автоматизация | Имитация пользовательских визитов и действий на сайте | Один отдельный запрос может не отличаться от нормального, поэтому важна структура поведения и совокупность признаков |
Спам‑боты | Отправка форм, массовые заявки и автоматизированные обращения | Нужна защита конкретного бизнес‑действия, а не только просмотра страницы |
Внутренняя реализация этих механизмов в статье намеренно не раскрывается. Для истории эволюции важнее другое: современная система защиты должна уметь принимать разные решения для разных типов автоматизации и не превращать одно правило в универсальный молоток.
Группа в логе | Запросы | IP / URL | Инженерный вывод | |
47.82.0.0/16 + 47.79.0.0/16 | 23 960 | 2 835 IP / 23 959 URL | Основная нагрузка — перебор товарных фильтров, а не повтор с одного адреса | |
Chrome/118 | 2 415 | 2 411 IP / 2 410 URL | Почти одноразовый IP на запрос | |
GeedoShopProductFinder | 1 140 | Явный UA | Простой случай — клиент сам сообщает тип | |
GPTBot + OAI‑SearchBot | 426 | Сервисные UA | Отдельная политика доступа, не смешивать со взломом | |
Googlebot + YandexBot | 43 | Проверенные поисковые роботы | Нагрузка мала по сравнению с парсерами | |
92 | 41 | 3 | 1 |
|
Период | На что я в первую очередь смотрел | Что ломало этот подход |
2020 | Referer, отдельные IP и подсети, единичный визит | Подмена источников и ротация адресов |
2021 | IP + браузерные проверки + цифровые отпечатки | Автоматизация выполняет клиентскую логику и меняет идентификаторы |
2022–2024 | Сочетания правил Cloudflare, списки, исключения, класс трафика | Рост сложности конфигурации и ложных срабатываний |
2025 | Многоуровневая система на собственной инфраструктуре | Нужно одновременно держать точность, UX и управляемость |
2026 | Группы событий и кластерная аналитика | Нужно отличать распределённую автоматизацию от легитимных распределённых систем |
От Cloudflare к собственной архитектуре защиты
К 2026 году изменился не только набор правил фильтрации. Изменился сам подход к построению защиты.
Мои последние конфигурации Cloudflare уже были достаточно сложными. В них одновременно использовались IP‑адреса и сети, ASN, User‑Agent, Referer, HTTP‑версия, поисковые и рекламные метки, cookie, исключения для статических ресурсов и AJAX, отдельные trust‑правила и Interactive Challenge.
Но всё это оставалось конфигурацией внутри готовой платформы. Я комбинировал доступные признаки и определял, какое действие Cloudflare должен выполнить при совпадении заданных условий.
В CronArmor архитектура стала другой.
Возможность | Cloudflare в моих конфигурациях | CronArmor |
Правила по IP, сетям и ASN | Да | Да |
Анализ User‑Agent и Referer | Да | Да |
Проверка поисковых роботов | User‑Agent + сетевое происхождение | Отдельная серверная валидация происхождения |
Разделение доверенного и недоверенного трафика | Через правила и механизмы Cloudflare | Собственное состояние доверия клиента |
Цифровой отпечаток клиента | В моих конфигурациях не использовался | Собственный отпечаток клиентской среды, не основанный на JA3/JA4 |
Невидимая проверка клиента | Механизмы самой платформы | Несколько собственных невидимых технических проверок |
Интерактивное подтверждение человека | Cloudflare Interactive Challenge | Собственная интерактивная проверка присутствия пользователя |
Обработка известных ботов и сканеров | Набор правил | Отдельный уровень фильтрации |
Работа с AJAX/API/CMS | Исключения в Cloudflare Rules | Отдельные правила и исключения для AJAX, API и служебных запросов CMS |
Вредоносные HTTP‑запросы | WAF‑правила Cloudflare | Отдельная серверная фильтрация вредоносного HTTP‑трафика |
Серверная аналитика прохождения проверок | Ограничена возможностями платформы и доступного тарифа | Собственная серверная аналитика и журналирование событий |
Анализ отдельного запроса | Основная модель | Сохраняется как один из уровней |
Анализ совокупности событий | Не было собственного уровня | Кластерная аналитика трафика |
Управление архитектурой проверок | Ограничено возможностями Cloudflare | Собственная логика системы защиты |
Именно последняя разница для меня наиболее существенна. В Cloudflare я совершенствовал правила внутри существующей системы. В CronArmor я уже могу определять, какие уровни анализа вообще существуют, какие данные между ними сохраняются и как разные категории веб‑трафика должны обрабатываться.
Почему я отказался от идеи «устойчивого сетевого отпечатка»
Отдельной веткой моих экспериментов были сетевые TLS‑отпечатки JA3 и JA4. На первый взгляд идея выглядела привлекательно. Если IP‑адрес постоянно меняется, можно попытаться идентифицировать автоматизированного клиента по характеристикам устанавливаемого им TLS‑соединения. В моей практической задаче бесшовной фильтрации поведенческих ботов этого оказалось недостаточно: сетевой fingerprint не стал устойчивой идентичностью клиента, а значения, встречающиеся у автоматизации, могли пересекаться с обычным браузерным трафиком.
С JA3 проблема оказалась особенно наглядной. Fastly в 2023 году наблюдала изменение непосредственно на своей глобальной сети после того, как Chromium начал переставлять TLS‑расширения в ClientHello. Поскольку JA3 учитывает их порядок, число возможных перестановок для набора расширений Chrome оценивалось почти как 15!, то есть порядка 10¹² вариантов. Практически каждое новое соединение современного Chrome могло получать новый JA3. Это означало, что нестабильность возникала уже у обычного браузера, без всякого участия бота.
JA4 создавался в том числе как ответ на эту проблему: он нормализует и сортирует часть параметров ClientHello, поэтому значительно меньше зависит от случайного порядка TLS‑расширений. Но это не превращает его в «паспорт» конкретного браузера или человека. Cloudflare в 2024 году прямо указала, что JA3/JA4 сами по себе недостаточны против сложных вредоносных клиентов: fingerprints могут подделываться, изменяться, а характер трафика постоянно эволюционирует. Поэтому поверх JA4 Cloudflare использует межзапросные JA4 Signals — статистику по множеству запросов, IP, User‑Agent и другим признакам за временное окно.
Есть и практический пример нестабильности самого JA4. В эксперименте ntop/nDPI 2026 года один Safari с одного IP сформировал несколько JA4 из‑за различий в TLS ClientHello, связанных в том числе с pre_shared_key и возобновлением TLS‑сессий. То есть JA4 устойчивее JA3 к перестановке расширений, но он всё равно не является неизменным идентификатором одного клиента. JA4 действительно технически устойчивее JA3 к перестановке TLS‑расширений, но из этого не следует, что он эффективен как самостоятельный способ фильтрации поведенческих ботов. В научной работе When Handshakes Tell the Truth: Detecting Web Bad Bots via TLS Fingerprints (2026) модели на признаках JA4 показали высокие результаты на тестовом наборе JA4DB: лучшая модель достигла accuracy 98,63%, F1 0,9734 и AUC 0,998. Однако это результат классификации конкретного набора TLS‑fingerprints, а не доказательство того, что один JA4 способен устойчиво отделить современного поведенческого бота, работающего через полноценный браузер, от живого пользователя. Сами авторы отдельно указывают необходимость дальнейшей проверки устойчивости против advanced bot evasion и добавления других device‑fingerprinting features.
Параметр | JA3 | JA4 |
Что анализирует | TLS ClientHello | TLS ClientHello с нормализацией части параметров |
Зависимость от порядка TLS‑расширений | Высокая: порядок входит в fingerprint | В значительной степени уменьшена сортировкой/нормализацией |
Современный Chrome/Chromium | Может формировать практически новый JA3 на каждом соединении | Значительно стабильнее JA3 при перестановке расширений |
Может ли один и тот же браузер иметь несколько fingerprints | Да, очень часто | Да: возможны изменения из‑за TLS‑параметров, session resumption и других динамических факторов |
Могут ли разные живые пользователи иметь одинаковый fingerprint | Да | Да |
Может ли автоматизация через настоящий браузер пересекаться с живым трафиком | Да | Да; TLS fingerprint характеризует TLS‑клиент, а не того, кто управляет браузером |
Полезность против простых HTTP‑клиентов и скриптов | Ограниченная, особенно для современного Chromium‑трафика | Заметно выше как дополнительный признак |
Полезность против сложного поведенческого бота в полноценном браузере | Низкая: не отделяет реальный браузер от автоматизации | Низкая: более стабильный TLS‑отпечаток всё равно не определяет человека |
Можно ли использовать как единственный ответ «бот или человек» | Нет | Нет |
Именно последнее ограничение принципиально для моей задачи. Современная автоматизация всё чаще работает внутри полноценного браузера. DataDome, например, показывала, что новые версии Headless Chrome используют ту же кодовую базу, что и обычный Chrome, и их браузерные fingerprints стали почти одинаковыми. На TLS‑уровне проблема ещё фундаментальнее: если автоматизация использует тот же Chromium/BoringSSL, JA4 описывает свойства TLS‑клиента, но сам по себе не сообщает, управляет этим браузером человек или программа.
Рисунок 9. Исследование JA3 и JA4: устойчивость TLS‑отпечатков. JA4 значительно устойчивее JA3 к перестановке TLS‑расширений, однако и он не является неизменным идентификатором клиента: fingerprint одного и того же браузера может изменяться между соединениями и на длительном интервале времени.
Поэтому в своей системе я не стал строить идентификацию поведенческого трафика вокруг JA3 или JA4. Для моей задачи они не решают главную проблему: устойчивое различение браузероподобной автоматизации и реального пользователя, а главное стабильная точность и уникальность между разными живыми пользователями и поведенческими ботами. Технически более стабильный JA4 всё равно остаётся отпечатком TLS‑клиента, а не доказательством того, что браузером управляет человек, но и стабильности на среднесрочной и долгосрочной дистанции времени у него тоже нет.
Рисунок 10. Почему одних JA3/JA4 недостаточно для выявления поведенческих ботов. Живой пользователь и автоматизация могут использовать один и тот же браузер и TLS‑стек, поэтому их TLS‑отпечатки могут совпадать. При этом один fingerprint не является уникальным идентификатором конкретного пользователя или бота и не позволяет надёжно разделить эти классы трафика.
От TLS‑fingerprint к отпечатку клиентской среды
Это привело меня к другому направлению — определению цифрового отпечатка клиентской среды. Это другой подход и другая система формирования цифровых отпечатков, не относящаяся к JA3, JA4 или другому TLS fingerprinting. В CronArmor такой отпечаток определяется для запросов, которые взаимодействуют с защитой как полноценная браузерная среда — и для живых пользователей, и для браузероподобной автоматизации.
На уровне публичного описания граница для меня выглядит так: сетевой TLS‑fingerprint характеризует параметры TLS‑клиента и соединения; используемый в CronArmor цифровой отпечаток относится к клиентской среде. Сам состав признаков и способ формирования такого отпечатка в этой статье я не описываю.
Рисунок 11. Возможности и ограничения JA3/JA4. TLS‑fingerprint полезен для выявления нестандартных клиентов, но при браузерной автоматизации может совпадать с трафиком живых пользователей. Поэтому JA3/JA4 — дополнительный, а не самостоятельный признак.
Одной невидимой проверки тоже оказалось недостаточно
Ещё одно принципиальное отличие от моей прежней схемы — в CronArmor нет предположения, что одна успешно выполненная браузерная проверка автоматически означает присутствие человека. Поведенческий бот сам по себе может работать внутри полноценного браузера. Поэтому выполнение клиентской логики, работа с cookie или успешное прохождение одной технической проверки говорят прежде всего о возможностях клиентской среды, но не дают окончательного ответа о природе трафика. В результате в CronArmor появились несколько разных уровней невидимых проверок, которые оценивают разные аспекты взаимодействия клиентской среды с системой защиты и могут дополнять друг друга. Для случаев, когда технических проверок недостаточно, отдельно существует интерактивное подтверждение присутствия пользователя. Оно применяется не ко всему трафику подряд, а только при определённой совокупности условий; результат проверки может учитываться при последующих запросах клиента.
CronArmor в 2026 году
Если уже не сравнивать систему с Cloudflare, а просто дать её техническую характеристику, то в общих чертах она выглядит так.
Уровень системы | Назначение |
Сетевая оценка запроса | IP, сеть, ASN, география и другие признаки происхождения трафика |
Классификация автоматизированного трафика | Разделение известных роботов, сканеров, сервисных клиентов и браузероподобной автоматизации |
Валидация поисковых роботов | Проверка не только заявленного User‑Agent, но и происхождения запроса |
Цифровые отпечатки клиентской среды | Отдельный от TLS fingerprinting класс признаков для браузероподобного трафика |
Несколько невидимых технических проверок | Дополнительная оценка клиентской среды без действий пользователя |
Интерактивная проверка присутствия пользователя | Дополнительное подтверждение в неоднозначных случаях |
Состояние доверия | Возможность учитывать уже полученные результаты при последующих запросах клиента |
Серверная фильтрация | Обработка нежелательных автоматизированных и вредоносных HTTP‑запросов до защищаемого сайта |
Правила и исключения для прикладного трафика | Корректная работа AJAX, API, CMS, платёжных и других технических запросов |
Серверная аналитика и журналирование событий | Наблюдение за фактическими запросами и результатами прохождения защитных механизмов |
Кластерная аналитика трафика | Анализ трафика на уровне совокупности событий, а не только отдельных запросов |
Что в итоге изменилось за шесть лет
За шесть лет я прошёл путь от сложной конфигурации правил Cloudflare к собственной системе, в которой уже определяются не только условия фильтрации, но и сами уровни анализа веб‑трафика. IP, ASN, Referer и User‑Agent никуда не исчезли, но теперь они являются лишь частью общей картины. Мои собственные эксперименты с JA3 и JA4, а также опубликованные исследования Fastly, Cloudflare, ntop/nDPI и других команд показывают одну и ту же фундаментальную проблему: JA3 нестабилен уже на уровне современного браузера, а JA4, хотя технически устойчивее к перестановке TLS‑расширений, всё равно не становится устойчивой идентичностью поведенческого бота. Нормализация JA4 устраняет одну из наиболее заметных проблем JA3 — зависимость от порядка TLS‑расширений. Однако практическую проблему фильтрации поведенческих ботов это не решает: автоматизация, работающая через настоящий Chromium/BoringSSL, может иметь тот же TLS‑профиль, что и обычный пользователь Chrome. Один fingerprint не отвечает на вопрос, кто управляет браузером — человек или программа. Показательно, что даже Cloudflare не рассматривает JA4 как самостоятельный вердикт и дополняет его межзапросными сигналами.
Поэтому следующим шагом для меня стал не поиск ещё одного «идеального» сетевого fingerprint, а сложный комплекс разных технологий: собственные отпечатки клиентской среды, несколько вариантов невидимых проверок, интерактивное подтверждение в неоднозначных случаях, серверная аналитика, кластерная аналитика трафика и многоуровневая система фильтрации с глубокой индивидуальной конфигурацией под конкретный проект. Поэтому главный результат этих шести лет для меня — не новое правило и не новый fingerprint, а переход от настройки правил фильтрации внутри готовой платформы к собственной архитектуре защиты веб‑трафика, где решение формируется на нескольких независимых уровнях анализа.
Архивный материал автора
• «Боты из соц сетей в Метрике. Защита от негативной накрутки ПФ» — архивная публикация автора, первоначально опубликованная в 2020 году на прежнем персональном сайте и позднее перенесённая на текущий домен. Материал впоследствии дополнялся новыми наблюдениями и практическими экспериментами.
Источники по JA3/JA4 и браузерной автоматизации
• Fastly Security Research, 08.02.2023 — A First Look at Chrome’s TLS ClientHello Permutation in the Wild — практические данные о рандомизации порядка TLS‑расширений в Chromium и её влиянии на стабильность JA3.
• Cloudflare, 12.08.2024 — Advancing Threat Intelligence: JA4 fingerprints and inter‑request signals — описание JA4 и перехода от анализа одного TLS‑fingerprint к дополнительным межзапросным сигналам.
• Cloudflare Docs — JA3/JA4 fingerprint — техническая документация Cloudflare по использованию JA3 и JA4 в Bot Management.
• ntop/nDPI, 02.01.2026 — Is JA4 Now Obsolete? — эксперимент с изменчивостью JA4 одного и того же клиента между TLS‑соединениями и влиянием динамических TLS‑расширений.
• Jarad, Bicakci, 2026 — When Handshakes Tell the Truth: Detecting Web Bad Bots via TLS Fingerprints — исследование эффективности машинного обучения на базе JA4 для классификации автоматизированного трафика и ограничений такого подхода.
• DataDome, 13.06.2024 — How New Headless Chrome & the CDP Signal Are Impacting Bot Detection — практический разбор современной браузерной автоматизации и проблемы различения обычного браузера и автоматизации, работающей через тот же Chromium.
