Обнаружение ботов в 2026 годуДиагностика сбоев скраперов на Cloudflare, DataDome и Akamai

Скрапер, который месяц назад работал, начинает возвращать ответы 403, страницы проверки или ответы HTTP 200 без нужных данных. Первым подозреваемым обычно становится свежий антибот-релиз Cloudflare, DataDome или Akamai, и иногда это действительно так. Но не реже причина в изменившемся шаблоне страницы, истёкшем сессионном куки, новом редиректе или пуле воркеров, который незаметно удвоил параллельность.

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

В этой статье разобрано, что три вендора действительно задокументировали в 2026 году и что каждое изменение означает для конвейера скрапинга, а также предложен практичный способ диагностировать сбои, избирательно эскалировать запросы и измерять восстановление. Код лежит в репозитории ScraperHub/what-changed-in-cloudflare-datadome-and-akamai-bot-detection-in-2026: это диагностический фреймворк на Python, который классифицирует ответы и сообщает о пригодных результатах. Он не решает проверки и не меняет идентичность запросов, как и ничто другое в этой статье.

Что изменилось в обнаружении ботов в 2026 году

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

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

Cloudflare: обнаружение продолжается после первого запроса

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

Доступность нужно проверять для каждой зоны. В журнале изменений о запуске говорится о развёртывании для всех клиентов, тогда как в анонсе Precursor представлен как часть Enterprise Bot Management, бесплатная до общей доступности позднее в этом году.

Adaptive Intelligence появился 31 августа. Его модель непрерывно переобучается на живом трафике и включается через Auto Update Machine Learning для клиентов Enterprise Bot Management, из-за чего периодические нумерованные релизы моделей становятся менее заметными вехами. В анонсе одноразовые краткоживущие правила описаны как компонент, который ещё появится, поэтому считайте их запланированными, а не выпущенными.

Параллельно Cloudflare разделила политику для ИИ-краулеров на отдельные настройки Search, Agent и Training. С 15 сентября новые зоны получают рекомендуемые пресеты, более строгие для сайтов, живущих за счёт рекламы; операторы могут изменить их в любой момент. Это выбор операторов, а не запрет всех автоматизированных запросов, а Bot Preference Sync может записывать выбранные настройки в robots.txt.

DataDome: целостность проверок и свидетельства браузера

Механизм DataDome обфускации на основе ВМ компилирует логику Device Check и Slider в байт-код, который выполняет собственный интерпретатор в браузере. Главный эффект в том, что проверку становится труднее дёшево разобрать и воспроизвести; новой категории сетевых отпечатков это не добавляет.

В разборе Proof of Browser описаны проверки, сочетающие рендеринг, WebGL, мутации DOM и тайминги. Это механизмы в описании вендора: ни эта статья, ни сопутствующий репозиторий не измеряют, насколько хорошо они что-либо обнаруживают. Документация Device Check объясняет, как результаты обнаружения запускают проверку.

DataDome также представила Agent Trust 5 мая, после того как добавила поддержку Web Bot Auth в январе. Подтверждением идентичности может служить подписанная аутентификация или другие доверенные механизмы. Копирование User-Agent известного краулера не устанавливает ни идентичность, ни разрешение.

Наконец, в версиях 3.0 модулей DataDome для Apache, Nginx, Cloudflare Worker и Fastly изменились обработка путей и исключение статических ресурсов. Это изменения интеграции, которые зависят от того, обновится ли каждый оператор, а не новый детектор TLS или HTTP/2.

Akamai: адаптивная валидация и более тонкая политика для ботов

В марте Akamai анонсировала улучшения Content Protector, включая защиту нативных приложений и Advanced Validation Framework. AVF может запрашивать дополнительные данные об устройстве или поведении, когда пассивный анализ не даёт однозначного ответа, а интерактивная проверка включается по желанию. Публичной даты общей доступности в анонсе нет.

Akamai также разделила трафик ИИ-ботов на более детальные категории: Training Crawlers, Search Crawlers и Fetchers and Agents, с соответствующими фильтрами в Web Security Analytics. Они дают операторам более тонкий контроль и не предписывают действие по умолчанию.

Рассмотренные здесь источники не дают публичных оснований утверждать, что Akamai выпустила новую базовую модель Bot Manager, новый формат _abck или новый детектор резидентных прокси в 2026 году. Та же сдержанность уместна и в отношении знакомых техник у других вендоров: TLS-фингерпринтинг, браузерные отпечатки и репутация IP по-прежнему важны, но само их существование не является анонсом 2026 года.

Диагностируйте сбой, прежде чем менять скрапер

Начните с одного сохранённого сбойного ответа. Зафиксируйте время, запрошенный и итоговый URL, заголовки и тело ответа, версию скрапера, локацию выходного узла, идентификатор сессии (если он важен) и уровень параллельности, а затем сравните всё это с заведомо рабочим снимком. Без этих измерений связь инцидента с релизом вендора остаётся во многом догадкой.

Сначала исключите распространённые сбои на стороне приложения:

1. Дрейф разметки или парсера: есть ли ожидаемый элемент в исходном HTML?
2. Рендеринг JavaScript: появляются ли данные только после выполнения на клиенте или в более позднем сетевом ответе?
3. Аутентификация: не перенаправил ли запрос на страницу входа, не потерялся ли куки, не истёк ли CSRF-токен?
4. Характер трафика: не изменились ли число воркеров, частота запросов или локация выходного узла?
5. Редиректы и варианты: не изменились ли канонический URL, локаль, версия для устройства или тип контента?

Затем классифицируйте сам ответ, а не исключение, которое выбросил ваш парсер.

Маркеры вендоров сужают поиск, но сами по себе не дают надёжной атрибуции. Cloudflare документирует заголовок cf-mitigated: challenge; заголовок cf-ray сам по себе не является вердиктом о блокировке, поскольку он есть в каждом проксируемом ответе. Куки или эндпоинты проверок DataDome добавляют контекст, а связанные с Akamai имена куки _abck и bm_sz ничего не доказывают о конкретном решении по применению защиты.

Отделяйте вердикт загрузки от успеха по содержимому

В Crawling API это различие можно наблюдать. cb_status содержит вердикт Crawlbase по ответу с учётом собственных проверок на блокировку и содержимое. original_status обычно содержит статус, который отправил целевой сайт. Итоговый url показывает редиректы, а с format=json эти поля приходят вместе с телом и полем domain_complexity с ценовым уровнем. Запрос к https://example.com/ 7 октября 2026 года вернул:

{
  "original_status": 200,
  "pc_status": 200,
  "cb_status": 200,
  "url": "https://example.com/",
  "domain_complexity": "standard"
}

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

Классификатор сопутствующего репозитория (файл final/bot_diag/classify.py) наглядно показывает это различие:

# final/bot_diag/classify.py
def classify_response(
    status: int | None,
    body: str,
    headers: Mapping[str, str] | None = None,
    expected_fields: Sequence[str] | None = None,
) -> str:
    header_map = _header_map(headers)
    text = body or ""
    lowered = text.lower()
    if _is_cloudflare_challenge(lowered, header_map) or _is_datadome_challenge(lowered, header_map):
        return LABEL_CHALLENGED
    is_blocked = (
        _is_akamai_block(text, lowered)
        or _is_cloudflare_block(lowered, header_map)
        or _is_datadome_block(status, lowered, header_map)
        or (status in {401, 403, 429} and bool(text.strip()))
    )
    if is_blocked:
        return LABEL_BLOCKED
    return _content_label(status, text, expected_fields)

Это фрагмент, а не самостоятельный пример: импорты, метки и вспомогательные функции находятся в других местах пакета. Он возвращает одну из четырёх меток: blocked, challenged, invalid_content и ok. Валидатор полей намеренно минималистичен и поддерживает простые шаблоны JSON и HTML, а не производственные схемы, поэтому изучите шаг 3 и его фикстуры, прежде чем адаптировать его под свои данные.

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

Выбирайте способ восстановления по классу сбоя

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

Согласованность запросов и сессии. Заявленная идентичность браузера должна согласовываться с транспортом, заголовками, историей куки и последовательностью навигации. Замена одного лишь User-Agent или выходного IP редко помогает против оценки целостности браузера или оценки на уровне сессии. Сохраняйте выходные узлы стабильными там, где процесс зависит от навигации с авторизацией или с сохранением состояния.

Выполнение в браузере. Используйте рендеринг, когда нужные вам поля зависят от JavaScript. Это дороже и медленнее: в Crawling API запрос с JavaScript тарифицируется по двойной стандартной ставке. Рендеринг не даёт права на доступ к целевому сайту и не является универсальным способом пройти проверку. Об операционном компромиссе читайте в статье о headless-браузерах и API для скрапинга.

Повторы и эскалация. При временных сбоях делайте нарастающие паузы с верхним пределом. Невалидные URL и селекторы исправляйте, а не повторяйте без изменений. Подтверждённую блокировку исследуйте, а не долбите тем же запросом. Вот коды Crawling API, которые встречаются чаще всего, и что делать с ними в первую очередь:

Неудачный вызов также возвращается с HTTP-статусом 520. Это строка статуса, а не cb_status, поэтому всегда ветвите логику по cb_status из ответа. В репозитории шаг эскалации привязывает эскалацию на JavaScript к кодам 520 и 525 и добавляет page_wait=2000 и ajax_wait. Прежде чем использовать его повторно, сопоставьте его с таблицей выше: эскалируйте при 503 и при неожиданном 207, а 705 и 706 считайте сигналом снизить темп. Ожидания помогают с поздно рендерящимся контентом; от проваленной проверки они не спасают.

Идентичность и политика. Для именованных легитимных агентов подписанная идентичность и регистрация могут быть лучшим путём, чем имитация произвольного браузерного трафика. К этому уровню относятся Cloudflare Web Bot Auth, DataDome Agent Trust и связанные с агентами механизмы Akamai. Подтверждённая идентичность всё равно не гарантирует авторизацию.

Управляемое получение данных. Crawlbase предлагает Crawling API для интеграций на уровне запросов, Smart AI Proxy для существующих клиентов, совместимых с прокси, и Enterprise Crawler для пакетных заданий в очереди и доставки результатов. Управляемая инфраструктура избавляет от необходимости самостоятельно содержать парки браузеров и пулы прокси, но поддерживаемые целевые сайты, задержки, кредиты и долю сбоев по-прежнему нужно измерять.

Оценка восстановления с помощью сопутствующего проекта

Для репозитория нужен Python 3.10+; он содержит шесть пошаговых скриптов в steps/ и пакет bot_diag в final/. Это диагностический фреймворк, а не бенчмарк обхода защиты на живых сайтах ни одного из вендоров. Его конвейер:

1. Начните с запроса к Crawling API с Normal token, используя format=json.
2. Проверьте cb_status, original_status, итоговый URL и контент.
3. Классифицируйте ответ и проверьте обязательные поля.
4. Повторяйте или эскалируйте только там, где этого требует политика обработки сбоев.
5. Сохраните по одному результату на URL в CSV и подведите итоги по пригодным результатам и накладным расходам на повторы.
6. Покажите выбор между Smart AI Proxy и Crawling API для каждого домена.

Воспроизводимый базовый прогон

Клонируйте репозиторий, установите зависимости и начните с синтетического сценария, которому не нужен токен. Перейдите в каталог final и выполните:

python -m bot_diag evaluate urls.example.txt --fields price,title --dry-run

Для живого прогона задайте CRAWLBASE_TOKEN (и CRAWLBASE_JS_TOKEN для эскалации на JavaScript), подготовьте список URL, которые вам разрешено загружать, и запустите:

python -m bot_diag evaluate urls.txt --fields price,title \
  --concurrency 4 --max-retries 2 --out sample_results.csv

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

Для осмысленного сравнения возьмите выборку примерно от 100 до 200 URL, охватывающую типичные виды страниц, применяйте одинаковые правила валидации к каждому способу загрузки и повторяйте замеры в разные дни. Сегментируйте результаты по домену, классу страниц, географии и режиму рендеринга. Синтетические фикстуры проверяют логику программы; надёжность работы с целевыми сайтами измеряют только живые выборки, на загрузку которых у вас есть разрешение.

Осознанно переводите проблемный домен на другой маршрут

В примере маршрутизации подсчитываются наблюдаемые проверки для каждого нормализованного имени хоста. Пока их меньше порога по умолчанию, равного трём, домен остаётся на Smart AI Proxy; при достижении порога домен переводится на Crawling API:

# final/bot_diag/routing.py
def route_domain(
    domain: str,
    challenge_counts: Mapping[str, int],
    *,
    threshold: int = DEFAULT_CHALLENGE_THRESHOLD,
) -> str:
    """Return ``api`` after ``threshold`` challenges, otherwise ``proxy``.

    ``proxy`` means the caller's existing HTTP client should keep using
    ``smartproxy.crawlbase.com:8013``. ``api`` means that domain should move
    to the Crawling API. Counts must already be keyed by ``domain_key``.
    """
    if threshold < 1:
        raise ValueError("threshold must be at least 1")
    key = domain_key(domain)
    if challenge_counts.get(key, 0) >= threshold:
        return API
    return PROXY

Шаг 6 выводит решение; он не открывает прокси-соединение и не переключает маршрут автоматически. HTTPS-эндпоинт Smart AI Proxy: smartproxy.crawlbase.com:8013 с аутентификацией прокси по токену, а документация Smart AI Proxy описывает CrawlbaseAPI-Parameters (заголовок с параметрами, в том числе для JavaScript). В примере эскалация в Crawling API использует отдельный JavaScript token.

Реальному сервису маршрутизации также нужны счётчики с истечением срока, наблюдаемость, поведение автоматического выключателя (circuit breaker) и путь обратно к более дешёвому маршруту. Без них короткая серия из трёх проверок навсегда переведёт трафик хоста на другой маршрут.

Измеряйте стоимость пригодного результата, а не ответа HTTP 200

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

url_completion_rate    = urls_with_valid_final_result / input_urls
attempt_success_rate   = successful_attempts / all_fetch_attempts
cost_per_usable_result = total_allocated_cost / validated_results

Знаменатели различаются намеренно. Доля завершённых URL показывает, какая часть задания выполнена; успешность попыток показывает, насколько эффективен путь загрузки. Не ставьте их рядом и не называйте оба показателя «долей успеха».

Учитывайте затраты на прокси и вычисления, кредиты управляемого провайдера, накладные расходы на повторы, браузерную инфраструктуру и инженерную поддержку, не считая дважды то, что уже входит в тариф управляемого сервиса. В Crawlbase оплачиваются только успешные вызовы: ответы целевого сайта 200, 404, 410 и редиректы, пустые тела 200 (cb_status 207) и любые статусы, которые вы включили через custom_success_codes. Блокировки и внутренние сбои бесплатны. domain_complexity задаёт ценовой уровень, на который умножается каждый оплачиваемый запрос, поэтому фактический расход берите из статистики использования аккаунта и тарифов Crawlbase и не пытайтесь оценить его по числу запросов.

Самостоятельно управляемые клиенты могут быть экономичны на предсказуемых целевых сайтах или когда необходим полный контроль над браузером. Управляемое получение данных становится привлекательнее, когда поддержка обходных решений под конкретные домены начинает съедать инженерное время. Ни один из вариантов не отменяет необходимости проверять полученные данные.

Заключение

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

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

Основные источники

• Cloudflare: Precursor, документация Precursor, Adaptive Intelligence, управление ИИ-трафиком, политики для ИИ-краулеров смешанного назначения
• DataDome: обфускация на основе ВМ, Proof of Browser, Agent Trust, Device Check
• Akamai: улучшения Content Protector, категории трафика ИИ-ботов, обновление Web Security Analytics

Часто задаваемые вопросы (FAQ)

Почему скрапер проходит проверку, а потом всё равно получает отказ?

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

Означает ли HTTP 200, что скрапинг прошёл успешно?

Нет. Он подтверждает ответ только на одном уровне. Страница проверки, пустая оболочка, перенаправленная страница или правдоподобные, но неверные данные могут прийти с кодом 200. Прежде чем отмечать URL как завершённый, проверьте поля и их смысл.

Помогают ли резидентные прокси против современных систем обнаружения ботов?

Они помогают с репутацией IP и географическим доступом, но не с отсутствием выполнения в браузере или несогласованными сигналами сессии. Агрессивная ротация на каждый запрос может сделать процессы с сохранением состояния менее, а не более согласованными.

Какие ответы Crawling API оплачиваются?

Только успешные: cb_status 200 (включая 404, 410 и редиректы целевого сайта), пустые тела 200, отмеченные как cb_status 207, и статусы, которые вы включили через custom_success_codes. Блокировки, такие как 503, 704, 705 и 706, и внутренние сбои не оплачиваются.

Может ли Crawlbase гарантировать доступ к сайтам под защитой Cloudflare, DataDome или Akamai?

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

NZ

Neil Zamora

Старший архитектор · Crawlbase

Старший архитектор в Crawlbase, сосредоточен на системах, стоящих за краулингом в больших масштабах: ротация прокси, устойчивость к anti-bot и API, скрывающие эту сложность.

IK

Ian Kalvin

Инженер технической поддержки · Crawlbase

Инженер технической поддержки в Crawlbase, пишет с переднего края того, что на самом деле ломается в продакшене при скрейпинге и в прокси-конфигурациях.