Как работает обнаружение DataDome, по его собственной документации

Вы открываете страницу и получаете 403 с испытанием вместо контента, или страница на секунду показывает экран «проверяем ваше устройство» и продолжает загрузку. И то и другое - DataDome. Его документация довольно конкретна в том, что делает каждая часть, поэтому мы опираемся на неё, а не на форумы обхода: модуль на инфраструктуре сайта, JavaScript-тег на странице и cookie, которая их связывает.

Серверный модуль спрашивает о каждом запросе

Сайт ставит модуль DataDome в свой CDN, балансировщик нагрузки или сервер приложения. На каждый входящий запрос модуль обращается к API validate-request ещё до того, как выполнится код самого сайта. Справочник API DataDome перечисляет, что туда уходит:

• IP-адрес клиента
• заголовки запроса, например User-Agent, Accept и Referer
• CookiesList, имена cookie в исходном порядке, и CookiesLen
• идентификатор клиента из cookie datadome
• по желанию отпечатки TLS JA3 и JA4: DataDome их рекомендует, но не требует

Ответ 200 означает «передать запрос на исходный сервер». Любой другой код означает, что модуль сразу возвращает вам ответ DataDome, код и тело, и сервер сайта запроса не видит вовсе. Этот ответ и есть страница испытания.

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

Справочник также требует от интеграций fail open: если ответа DataDome нет из-за тайм-аута или ошибки, запрос пропускается. Так настоящие пользователи не страдают во время сбоя.

JS-тег наблюдает за страницей

Вторая часть работает в вашем браузере. Документация JS-тега говорит, что он собирает:

• поведение: движения мыши и нажатия клавиш
• данные об окружении, включая ОС, браузер и GPU
• проверки согласованности встроенных функций и атрибутов, которые, по словам DataDome, помогают находить headless Chrome, Puppeteer и Selenium

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

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

Ещё тег оборачивает XMLHttpRequest и fetch, чтобы при блокировке фонового запроса показать испытание, а не тихо упасть.

Cookie и Device Check

Страница DataDome о cookie описывает datadome как cookie, которая используется и для серверного, и для клиентского обнаружения, чтобы оценить легитимность запроса. Она зашифрована, не содержит персональных данных и живёт один год. DataDome предупреждает владельцев сайтов не менять её Domain и Path и не добавлять HttpOnly: тегу и страницам испытаний нужно её читать и писать.

Device Check - тот самый экран, который появляется и исчезает. DataDome описывает его как проверку, которая выполняется на устройстве пользователя без его участия и предназначена для выявления фреймворков автоматизации, подменённых окружений и программного доступа к интерфейсам. Он срабатывает, когда запрос выглядит подозрительно, а ресурс чувствителен, или когда DataDome подозревает бота, но доказательств для блокировки не хватает. У него есть невидимый режим, а если решения всё ещё нет, DataDome может перейти к CAPTCHA.

Чего ждать при работе с несколькими аккаунтами

• Одна cookie на одну личность. Cookie на год, которую сервер читает при каждом запросе, - это идентификатор. Общая для нескольких аккаунтов, она их связывает.
• Адрес выхода оценивается первым. Он есть в каждом обращении к API, раньше, чем существует ваша страница. Наш августовский отчёт о детекторах (на английском) измерял, насколько адрес выхода решал исход на сайте под DataDome, и это первое, что стоит исключить. Чем отличаются типы прокси, разобрано в статье про резидентные и серверные прокси.
• Первый визит - самый слабый случай. У профиля без cookie datadome и без истории за плечами ещё ничего нет.

Когда мы - неверный выбор

Если DataDome блокирует вас на первом же запросе в любом браузере, который вы пробуете, причина в адресе или в самом запросе, и другой браузер этого не изменит. Если вы массово собираете публичные данные, DataDome стоит именно затем, чтобы это остановить, а антидетект-браузер не инструмент для скрапинга. AntiBrow даёт каждой личности свой локальный профиль со своими cookie и отпечатком на уровне движка, а неограниченные локальные профили бесплатны. Это закрывает состояние на личность и согласованность, но не репутацию адреса и не поведение.

Проверьте сами

В DevTools найдите cookie datadome на сайте и запрос к тегу DataDome. Затем сравните холодный профиль и профиль, которым вы пользовались неделю, через один и тот же выход, и отметьте, какой из них увидит Device Check.

Источники, проверены 2026-10-22: API validate-request, JavaScript-тег, cookie и хранимые данные, Device Check.