89,6% европейских сайтов с CDN — за Cloudflare: чем опасна монокультура фильтра

7 сентября 2026 года исследователи CipherCue опубликовали замер, который стоит прочитать всем, кто ходит в европейский веб автоматизированно: из 44 143 европейских компаний, у которых вообще удалось детектировать CDN, 89,6% сидят за Cloudflare. Не «лидер рынка с большим отрывом» — а почти весь рынок целиком. Для скрапинга, мультиаккаунтинга и любой автоматизации это означает простую вещь: доступ к девяти сайтам из десяти в ЕС решает один и тот же алгоритм, по одним и тем же признакам, в одну и ту же секунду.

Что именно посчитали

Выборка — компании из Германии, Великобритании, Нидерландов, Польши, Франции, Италии, Испании и Ирландии, у которых на сайте определился хотя бы один CDN-компонент. Детект шёл по HTTP-ответам и отпечаткам сервера: заголовок cf-ray и server: cloudflare для Cloudflare, x-served-by с кеш-маркером для Fastly, x-amz-cf-id для CloudFront. Дата наблюдений — 7 сентября 2026 года.

Расклад по провайдерам:

• Cloudflare — 39 547 компаний (89,6%)
• Amazon CloudFront — 3 112
• Fastly — 1 299
• Akamai — 396

По странам разброс заметный, но потолок везде высокий:

• Нидерланды — 95,6% (7 587 из 7 939)
• Великобритания — 93,2% (15 846 из 17 007)
• Польша — 92,6% (2 682 из 2 896)
• Франция — 86,2% (3 456 из 4 008)
• Италия — 85,4% (3 126 из 3 661)
• Германия — 81,4% (4 650 из 5 715)
• Испания и Ирландия — по 78,8%

Авторы сами оговаривают ограничения, и это честно: одна компания могла попасть под несколько провайдеров сразу (двойной учёт), а выборка смещена в сторону малого и среднего бизнеса — сегмента, где бесплатный тариф Cloudflare сильнее всего. То есть 89,6% — это доля среди компаний с детектированным CDN, а не среди всех европейских юрлиц.

Независимая проверка порядка величин есть: по данным W3Techs на сентябрь 2026 года Cloudflare используют 84,7% сайтов, у которых вообще известен reverse proxy, — это 25,2% всех сайтов в их индексе. Разные методики, разные выборки, но вывод один: перед четвертью веба и перед подавляющим большинством распознаваемых CDN-установок стоит один посредник.

Почему для автоматизации это не «просто доля рынка»

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

Cloudflare выставляет запросу bot score от 1 до 99: чем ниже, тем выше уверенность, что перед сайтом автоматика. Модель, которая этот балл считает, по описанию самой компании обрабатывает свыше 46 млн HTTP-запросов в секунду и учитывает не только ваш конкретный запрос, но и глобальную статистику по всей сети: репутацию IP, ASN и тип адреса (датацентр / резидентный / мобильный), согласованность заголовков, TLS-отпечаток, поведенческие признаки. Детект слоёный — эвристики плюс ML, причём на машинное обучение приходится большая часть решений.

Практическое следствие: ваш пул и ваш отпечаток оцениваются не сайтом, а сетью. Спалились на одном ресурсе — репутационный сигнал уже учтён при следующем запросе к другому. В мире, где на этой сети сидят девять из десяти европейских сайтов, «переключиться на другую цель и переждать» перестаёт быть стратегией.

Резидентный IP перестал быть индульгенцией

Старая логика «взял резидентный адрес — прошёл как человек» упирается в то, что провайдер фильтра давно ловит именно этот приём. Cloudflare публично описывал отдельную модель против ботов, идущих через резидентные прокси: сначала пробовали сетевые признаки (лишние хопы, латентность), но отказались из-за ложных срабатываний на спутниковом интернете, и перешли к поведенческому анализу — характерным всплескам активности у IP-адресов. В их же публикации приведён масштаб явления, который они видят: около 17 млн уникальных IP в час, задействованных в атаках через резидентные прокси, 45 тыс. ASN и 237 стран и регионов (цифры относятся к марту 2024 года, более свежих компания не приводила). Заявленная точность классификации распределённой атаки на одного из клиентов — 95%, прирост детекта ботов из облачных сетей — 20%.

Важная деталь оттуда же: модель сознательно не строится на блокировке IP — чтобы не выбивать живых пользователей из тех же сетей. Это хорошая новость для честного трафика с резидентных адресов и плохая — для тех, кто рассчитывает, что «дом» сам по себе даёт зелёный свет. Работает не тип адреса, а связка «тип адреса + поведение + отпечаток». Подробный разбор различий между стенками мы делали в сравнении антибот-систем Cloudflare, DataDome, Akamai и Kasada — сейчас к нему стоит вернуться с поправкой на то, что весов у первой строчки в Европе стало непропорционально много.

Обратная сторона: когда падает один — падают все

У монокультуры есть вторая грань, не про блокировки, а про доступность. Последние полтора года дали три показательных эпизода:

1. 18 ноября 2025 — глобальный сбой, затронувший, по оценкам, примерно каждую пятую веб-страницу и треть из 10 000 самых популярных сайтов и сервисов. Причина по разбору самой компании: изменение прав в кластере ClickHouse привело к дублированию строк в файле признаков, который используется ML-моделью для скоринга ботов. Иронично: механизм, решающий, человек вы или нет, положил заметную часть интернета.
2. 5 декабря 2025 — сбой с 8:47 UTC примерно на 25 минут, затронувший подмножество клиентов, на которых приходилось около 28% всего HTTP-трафика, проходящего через сеть.
3. 20 февраля 2026 — в 17:48 UTC у части клиентов, использующих BYOIP (свои IP-диапазоны), маршруты были отозваны по BGP из-за изменения в конвейере онбординга адресов.

Формулировка авторов исследования здесь точная: когда один провайдер стоит перед большей частью рынка, его ошибки перестают быть его проблемой и становятся проблемой всех одновременно. Для пайплайна сбора данных это значит, что «упал целевой сайт» и «упал весь регион» теперь различаются плохо — и алерты, настроенные на конкретный домен, врут.

Что с этим делать практически

Ниже — то, что реально меняется в рабочем процессе, если принять монокультуру фильтра как данность.

1. Тестируйте связку не на одном сайте. Если ваш отпечаток проходит на трёх ресурсах — вы, скорее всего, проверили один и тот же фильтр трижды. Берите в тестовый набор ресурс за CloudFront, за Fastly, за Akamai и без CDN вовсе, иначе выборка ничего не доказывает.
2. Разводите пулы по проектам, а не по сайтам. Раз репутация оценивается сетью, «отдельный пул под каждый домен» не изолирует ничего. Изоляция имеет смысл на уровне проекта и профиля: один проект — свой пул адресов, свой набор отпечатков, свой темп.
3. Смотрите на тип и происхождение адреса. ASN и категория адреса — прямой вход в скоринг. Для чувствительных целей осмысленны резидентные прокси и мобильные адреса; массовые технические задачи (проверка доступности, свои API, работа с площадками без жёсткого антибота) дешевле и честнее закрывать датацентр-прокси, не тратя дорогой трафик впустую.
4. Не жгите подсеть. Поведенческие модели ловят всплески активности на адресе. Ровный темп на широком пуле переживает скоринг лучше, чем короткий агрессивный залп с узкого.
5. Приводите отпечаток в порядок целиком. TLS-отпечаток, порядок и состав заголовков, версия HTTP, поведение JS — оцениваются вместе. Резидентный IP с отпечатком голого HTTP-клиента даёт худший результат, чем аккуратный датацентр-адрес с честным браузерным стеком.
6. Разделяйте «нас заблокировали» и «у них авария». Простое правило: при массовом росте ошибок сначала проверьте, не легло ли всё сразу у нескольких несвязанных целей и что показывает статус-страница провайдера. Ретраи в момент глобального сбоя — это способ сжечь пул на ровном месте.
7. Имейте план Б на день, когда упадёт фильтр. Очередь задач, которая умеет ждать и добирать пропущенное, дороже в разработке, но переживает 25 минут недоступности без потери данных.

Вывод

Цифра 89,6% — не про то, что Cloudflare плохой, и не про то, что европейский веб закрылся. Она про то, что разнообразие целей больше не означает разнообразия препятствий. Один скоринг, одна модель, одна репутационная база — и, как следствие, один общий режим отказа: и когда вас принимают за бота, и когда провайдер сам роняет маршруты.

Вывод для практики скучный, но рабочий: перестать оптимизировать обход «под сайт» и начать оптимизировать поведение — качество адресов, ровный темп, согласованный отпечаток, честная диагностика сбоев. Это единственное, что одинаково хорошо работает и по ту сторону 89,6%, и по эту.