Как DataDome на самом деле обнаруживает ботов

Большинство знакомится с DataDome одинаково: скрейпер, который работал вчера, начинает возвращать 403, или на месте страницы появляется капча-слайдер. Первый порыв — добавить прокси или сменить user agent. Это почти никогда не помогает, потому что DataDome не смотрит на какой-то один сигнал. Он оценивает целостную картину запроса, и решение — отправить картину, которая выглядит настоящей.

Вот на что он действительно смотрит.

Отпечаток устройства

JavaScript от DataDome выполняется на странице и собирает отпечаток клиента: размеры экрана и окна, часовой пояс, язык, установленные шрифты, хеши canvas и WebGL, список поддерживаемых кодеков и десятки более мелких сигналов. Сам по себе этот отпечаток — не приговор. Это идентичность, которую DataDome отслеживает между запросами, поэтому несогласованная или невозможная комбинация (user agent «Chrome на Windows» вместе с WebGL-рендерером Linux) сразу бросается в глаза.

TLS и порядок заголовков

Ещё до того как выполнится хоть какой-то JavaScript, у DataDome уже есть два сильных сигнала из самого соединения:

• Отпечаток TLS (JA3/JA4). Конкретный набор шифров и расширений, который предлагает ваш HTTP-клиент, редко совпадает с настоящим браузером. Рукопожатие requests или axios по умолчанию тривиально отличается от Chrome.
• Порядок и регистр заголовков. Браузеры отправляют заголовки в определённом, стабильном порядке. Большинство HTTP-библиотек — нет, и DataDome читает этот порядок как улику ещё до того, как посмотрит на значение какого-либо заголовка.

Именно поэтому подмена одной только строки User-Agent ничего не меняет. Строка говорит «Chrome»; рукопожатие говорит «Python».

Поведенческие теги

Как только страница загружается, DataDome отправляет на свой endpoint сбора данных поток поведенческих тегов: движения мыши, тайминг прокрутки, ритм нажатий клавиш, события focus и blur, а также интервалы между ними. Настоящая сессия даёт беспорядочный, «человекообразный» поток. Headless-браузер даёт либо ничего, либо что-то слишком чистое и слишком быстрое.

Ответ на этот payload и есть то, что устанавливает cookie datadome. Составьте payload правильно — и cookie вернётся в доверенном состоянии. Составьте неправильно или пропустите его — и вам подсунут интерстишиал или слайдер.

Почему headless-браузеры всё равно попадаются

Запуск Puppeteer или Playwright порождает настоящие теги и настоящее TLS-рукопожатие, поэтому он проходит больше, чем «сырой» HTTP-клиент. Но это медленно (секунды на сессию, сотни МБ RAM на воркер) и оставляет собственные отпечатки: navigator.webdriver, специфичные для headless особенности рендеринга и характерные для фреймворков автоматизации тайминги, которые stealth-плагины латают с отставанием на один релиз. В итоге вы поддерживаете ферму браузеров и бесконечную гонку плагинов, чтобы бороться с детектором, который обновляется быстрее, чем вы успеваете.

Как выглядит проходящий запрос

Запрос, которому DataDome доверяет, несёт три вещи, согласованные друг с другом:

1. Валидный cookie datadome в очищенном состоянии.
2. Отпечаток TLS и набор заголовков, под которые был выпущен этот cookie.
3. Исходящий запрос с IP, который вписывается в политику цели (прокси приносите свои).

Сложность — получить первые две вещи без браузера. Именно это мы и делаем: генерируем payload с тегами, решаем проверку устройства и слайдер на стороне сервера и отдаём обратно cookie datadome вместе с набором заголовков, под который он был подписан. Вы прикрепляете их к своему запросу и идёте прямо к данным. Ни headless Chrome, ни stealth-плагинов, ни игры в кошки-мышки.

Если вам нужны механика и рабочий пример, посмотрите страницу обхода DataDome. Если вас блокирует другой вендор, полный список стен охватывает Akamai, Cloudflare, PerimeterX, Imperva и остальных.