Обнаружение headless браузеров: как сайты видят бота

Вы сменили прокси и настроили отдельный цифровой отпечаток для каждого профиля, но по-прежнему сталкиваетесь с дополнительными проверками или ограничениями доступа к сайтам? Это говорит о том, что управление окружением браузера требует гораздо большего, чем изменение нескольких настроек. При каждом посещении веб-сайты могут анализировать разные типы данных, чтобы определить, является ли посетитель реальным человеком или ботом.

Как же работают методы обнаружения ботов и можно ли обнаружить антидетект-браузеры? В этой статье мы разберем механизмы обнаружения и факторы, влияющие на то, как сайты выявляют автоматизированную активность браузера.

1. Что такое headless-браузер и чем он отличается от обычного браузера?

Headless-браузер — это браузер, который работает без видимого графического интерфейса и обычно управляется с помощью кода через такие инструменты, как Puppeteer, Playwright или Selenium. При этом он может загружать веб-страницы, выполнять JavaScript и отправлять запросы так же, как обычный браузер. Поэтому для обнаружения автоматизированного трафика веб-сайтам необходимо анализировать различия в окружении и работе браузера.

1.1. Чем отличаются headless-режим, headful-режим и автоматизация?

Чтобы понять, как веб-сайты обнаруживают headless-браузеры, сначала нужно различать два понятия: режим отображения и способ управления браузером. Headless описывает, отображает ли браузер видимое окно, а автоматизация означает управление браузером с помощью скриптов.

Эти три распространенных сценария можно сравнить следующим образом:

Главное отличие заключается в том, что headless не означает автоматизацию. Браузером с видимым интерфейсом также можно автоматически управлять через Puppeteer или Playwright. И наоборот, отсутствие видимого окна само по себе не доказывает, что браузер выполняет действия бота.

Например, при запуске Puppeteer в headful-режиме Chrome по-прежнему открывает обычное окно, но его действия могут выполняться с помощью скриптов. Поэтому сайты не ограничиваются проверкой наличия графического интерфейса. Они также могут анализировать признаки, связанные со способом управления браузером.

1.2. Чем отличаются новый headless-режим Chrome и chrome-headless-shell?

Реализация headless-режима Chrome претерпела несколько важных изменений в разных версиях браузера. Раньше в headless-режиме использовалась отдельная реализация, которая не полностью разделяла исходный код с обычным Chrome. В результате headless-окружение имело определенные отличия, которые инструменты обнаружения ботов могли использовать в качестве индикаторов.

В настоящее время новый headless-режим унифицирован с реализацией обычного headful-режима. В частности, начиная с Chrome 112, headless-режим использует тот же код браузера, что и обычный Chrome, но не создает видимое окно. В Chrome 132 старая реализация headless-режима была перенесена в отдельный исполняемый файл chrome-headless-shell, распространяемый через Chrome for Testing.

При использовании Puppeteer можно встретить два варианта:

• headless: true: запускает Chrome в новом headless-режиме.
• headless: 'shell': запускает файл chrome-headless-shell со старой реализацией headless-режима.

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

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

2. Какие сигналы веб-сайты используют для обнаружения headless-браузеров?

Веб-сайты обнаруживают headless-браузеры, анализируя несколько групп сигналов, а не полагаясь на одну отдельную характеристику. Проверяемые данные могут поступать из HTTP-заголовков, свойств JavaScript, протоколов управления браузером, сведений об устройстве, поведения пользователя и сетевых подключений.

Каждая группа сигналов раскрывает отдельную сторону окружения браузера. Например, User-Agent предоставляет информацию о заявленном браузере, а navigator.webdriver указывает, управляется ли браузер с помощью средств автоматизации. Если несколько значений противоречат друг другу, у веб-сайта появляется больше оснований считать посещение подозрительным.

2.1. Сигналы на уровне HTTP

Когда вы посещаете веб-сайт, браузер отправляет HTTP-заголовки, которые предоставляют серверу определенную информацию об устройстве и окружении браузера. Сайты могут анализировать эти данные до выполнения более подробных проверок с помощью JavaScript.

К часто проверяемым сигналам относятся:

• User-Agent, содержащий HeadlessChrome: Некоторые конфигурации Chrome в headless-режиме могут отправлять строку User-Agent, содержащую HeadlessChrome. Веб-сайты могут считывать это значение непосредственно из запросов на стороне сервера или через свойство navigator.userAgent в браузере. Однако такая строка присутствует не во всех конфигурациях headless-режима, поэтому ее нельзя использовать как единственное основание для вывода.
• Несоответствие Client Hints и User-Agent: Client Hints предоставляет дополнительную информацию о бренде, версии, операционной системе и устройстве браузера через такие заголовки, как Sec-CH-UA и Sec-CH-UA-Platform. Если User-Agent указывает одну версию Chrome, а Client Hints содержит не связанную с ней информацию, веб-сайт может зафиксировать это несоответствие.
• Отсутствующие или необычные заголовки: Такие заголовки, как Accept-Language, указывают предпочитаемый язык браузера. Если эта информация отсутствует или не совпадает с другими данными, система может расценить это как сигнал, требующий дополнительной проверки.

Обратите внимание, что HTTP-заголовки могут различаться в зависимости от браузера, его версии и настроек. Поэтому сайты обычно сопоставляют их с другими сигналами, а не считают одно значение окончательным доказательством. Chrome также предлагает механизм User-Agent Client Hints, который позволяет передавать информацию о браузере в более структурированном виде.

2.2. Сигналы, связанные со свойствами JavaScript

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

К важным свойствам относятся:

• navigator.webdriver: Это свойство указывает, управляется ли браузер с помощью автоматизации через механизм WebDriver. Согласно стандарту W3C, оно возвращает true, когда активен флаг WebDriver. В Chrome это свойство может возвращать true, если браузер запущен с определенными параметрами, например --enable-automation, --headless или --remote-debugging-port, установленным на порт 0. Важно отличать navigator.webdriver от headless-режима: это свойство связано с состоянием автоматизации браузера, а не исключительно с его работой без графического интерфейса.
  W3C+1
• Рендерер WebGL: WebGL позволяет веб-сайтам получать информацию о возможностях графической обработки устройства. В некоторых средах без подходящего GPU браузер может использовать программный графический рендерер, например SwiftShader. Если эта информация не соответствует заявленной операционной системе или конфигурации устройства, сайты могут зафиксировать несоответствие.
• Размеры экрана и окна: Такие значения, как screen.width, screen.height, window.innerWidth и window.outerWidth, предоставляют информацию о доступной области отображения. Некоторые конфигурации автоматизации могут создавать стандартные размеры или несоответствия между этими свойствами.

Вы можете проверить некоторые базовые сведения, открыв инструменты разработчика браузера и введя соответствующие команды JavaScript в Консоли. Однако результаты отражают только состояние окружения в конкретный момент. Они не позволяют точно определить, как другой веб-сайт оценит ваш браузер.

Используйте следующий код, чтобы быстро проверить несколько свойств:

console.log("WebDriver:", navigator.webdriver);

console.log("Screen size:", screen.width, "x", screen.height);

console.log("Window size:", window.innerWidth, "x", window.innerHeight);

const canvas = document.createElement("canvas");
const gl = canvas.getContext("webgl");

if (gl) {
  const debugInfo = gl.getExtension("WEBGL_debug_renderer_info");

  console.log(
    "WebGL renderer:",
    debugInfo
      ? gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL)
      : "Renderer information unavailable"
  );
}

2.3. Следы протокола Chrome DevTools

Помимо свойств, доступных непосредственно через JavaScript, веб-сайты также могут искать признаки, возникающие при управлении браузером с помощью внешних инструментов. Один из механизмов, связанных с этим процессом, — Chrome DevTools Protocol (CDP).

CDP — это протокол, который позволяет внешним инструментам взаимодействовать с Chrome и управлять браузером. Он также используется в Chrome DevTools и поддерживается такими инструментами автоматизации, как Puppeteer и Playwright.

При подключении к Chrome инструмент автоматизации может отправлять команды CDP для активации необходимых функций. Например, Runtime.enable позволяет инструменту получать события, связанные со средой JavaScript. Некоторые операции, выполняемые через CDP, могут изменять способ обработки или отображения информации в Консоли браузера, создавая сигналы, которые веб-сайты могут анализировать.

Если эти сигналы отличаются от поведения, обычно наблюдаемого в обычных браузерах, антибот-система может расценить их как признаки автоматизации. Однако следы CDP не всегда свидетельствуют о работе бота. Пользователи, открывающие Chrome DevTools для проверки веб-сайта, также могут вызывать похожие эффекты. Поэтому для принятия решения системам обнаружения необходимо учитывать дополнительные сигналы.

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

2.4. Признаки измененного окружения браузера

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

Существуют две важные группы сигналов:

• Переопределенные свойства, не соответствующие нативной реализации: Некоторые скрипты могут изменять значения таких свойств, как navigator.webdriver, или другие сведения о браузере. Однако некорректные изменения также могут влиять на геттеры, прототипы или способ доступа к свойствам. Веб-сайты могут проверять эти особенности, чтобы обнаруживать подмененные данные.
• Противоречивая информация об устройстве: Например, User-Agent может указывать Windows, тогда как определенные данные о платформе, шрифтах или WebGL не соответствуют этой системе. Аналогичным образом часовой пояс и местоположение IP могут создавать несогласованную комбинацию, если не учитывать контекст использования.

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

2.5. Сигналы поведения пользователя

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

К некоторым особенностям поведения, которые могут привлечь внимание, относятся:

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

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

2.6. Сетевые сигналы

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

Обычно проверяются две группы данных:

• Репутация IP-адреса: Веб-сайты могут оценивать историю и репутацию IP-адреса. Например, IP-адрес, ранее связанный с многочисленными подозрительными попытками входа или большим количеством запросов, может быть отнесен к категории повышенного риска. IP-адреса дата-центров также могут оцениваться иначе, чем домашние IP-адреса, в зависимости от политики конкретной платформы.
• TLS-отпечаток: TLS-отпечаток отражает определенные характеристики процесса установления зашифрованного соединения. Если эта информация не соответствует заявленному браузеру или окружению, система может зафиксировать несоответствие.

Сетевые сигналы не позволяют напрямую определить, работает ли браузер в headless-режиме. Вместо этого они предоставляют дополнительную информацию об IP-адресах, характеристиках соединения и репутации источника трафика, помогая веб-сайтам оценивать, есть ли у посещения признаки необычной активности.

Краткое сравнение сигналов обнаружения

Каждая группа сигналов предоставляет свой тип информации. Следующая таблица поможет понять, что именно могут проверять веб-сайты и насколько вероятны ложные срабатывания в каждом случае.

Как правило, веб-сайты не полагаются на один сигнал при оценке посещения. Вместо этого они объединяют данные браузера, поведение пользователя и информацию о сетевом подключении. Один необычный признак недостаточен, чтобы доказать, что пользователь работает с headless-браузером. Однако если одновременно обнаруживается несколько сигналов, система может оценить посещение как более рискованное.

2.7. Какие старые методы обнаружения headless-браузеров необходимо пересмотреть?

При изучении методов обнаружения headless-браузеров можно встретить множество руководств, в которых свойства navigator.plugins, navigator.languages, window.chrome и WebRTC описываются как способы выявления headless-браузеров. Эти индикаторы часто упоминаются в документации, посвященной старым версиям Headless Chrome.

Однако начиная с версии 112 Chrome изменил реализацию headless-режима. Новый headless-режим использует общий исходный код с обычным Chrome, а старая реализация начиная с Chrome 132 была выделена в отдельный chrome-headless-shell. В результате характеристики, которые раньше считались типичными индикаторами, не обязательно точно отражают работу современных headless-браузеров.

Следующие свойства следует рассматривать как параметры, которые необходимо проверять с учетом соответствующей версии браузера, а не как окончательное доказательство работы браузера в headless-режиме.

Для более точной оценки проведите один и тот же тест в обычном Chrome и в используемой вами headless-конфигурации. Результаты будут полезнее, если указать версию Chrome, операционную систему и конкретный фреймворк. Также можно воспользоваться процедурой самостоятельной проверки из раздела 5.2.

Обратите внимание, что navigator.webdriver и User-Agent, содержащий HeadlessChrome, — это независимые сигналы. Их не следует объединять со старыми методами обнаружения, которые требуют пересмотра. Оба индикатора по-прежнему необходимо оценивать с учетом конкретной конфигурации и версии браузера.

3. Как веб-сайты обнаруживают Puppeteer, Playwright и Selenium?

Каждый фреймворк автоматизации браузера имеет собственный механизм работы и технические особенности. Puppeteer и Playwright обычно используют Chrome DevTools Protocol для управления Chromium, тогда как Selenium работает через WebDriver. Эти различия могут создавать сигналы, которые веб-сайты используют для выявления автоматизированной активности.

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

3.1. Обнаружение Puppeteer

Puppeteer — это библиотека Node.js, позволяющая управлять Chrome или Chromium с помощью кода. Ее часто используют для тестирования интерфейсов, создания снимков веб-страниц, сбора данных и автоматизации задач в браузере.

При работе Puppeteer может оставлять несколько сигналов, в том числе:

• Подключения CDP: Puppeteer использует Chrome DevTools Protocol для отправки команд и получения данных от браузера. Некоторые действия, связанные с этим протоколом, могут создавать следы, доступные для наблюдения веб-сайтами.
• Скрипты, внедряемые в страницы: Puppeteer может внедрять скрипты в окружение веб-страницы для управления браузером и отслеживания действий. В некоторых случаях следы этих скриптов могут появляться в трассировках стека, например в виде строки pptr:. Однако этот индикатор не является постоянным для всех версий.
• Режим headless по умолчанию: В настоящее время Puppeteer по умолчанию использует новый headless-режим. Чтобы запустить Chrome с видимым интерфейсом, можно установить headless: false. Изменение режима отображения не меняет автоматизированную природу фреймворка.
  Puppeteer+1

Например, с помощью Puppeteer можно автоматически открыть страницу товара и сделать снимки экрана на персональном компьютере. Если перенести тот же скрипт на VPS, сайт может начать запрашивать CAPTCHA или ограничивать доступ. Причина может быть связана с различиями в IP-адресе, окружении браузера или сигналах автоматизации, которые обнаруживает сайт.

3.2. Обнаружение Playwright

Playwright — это фреймворк автоматизации браузеров, совместимый с Chromium, Firefox и WebKit. Его часто используют для тестирования интерфейсов, проверки пользовательских сценариев и автоматизации задач на веб-сайтах.

При анализе активности Playwright веб-сайты могут проверять несколько индикаторов:

• Встроенная версия Chromium: Согласно документации Playwright, каждая версия фреймворка использует соответствующие версии браузера. По умолчанию Playwright может запускать собственную встроенную версию Chromium вместо Google Chrome с официальным брендом. Различия в версиях и сведениях о браузере могут привести к несоответствию Client Hints обычной конфигурации Chrome.
• Скрипты инициализации и глобальные переменные: Playwright может внедрять скрипты на страницы при создании контекста или инициализации окружения. Некоторые следы, связанные с этим процессом, можно проверить с помощью JavaScript.

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

3.3. Обнаружение Selenium

Selenium — это широко используемый набор инструментов автоматизации браузеров для тестирования программного обеспечения. В отличие от Puppeteer и Playwright, Selenium работает через WebDriver — стандарт, позволяющий внешним программам управлять браузерами.

Веб-сайты могут обращать внимание на несколько связанных индикаторов:

• WebDriver: Selenium использует механизм WebDriver для отправки команд управления браузером. Свойство navigator.webdriver может указывать на то, что браузер автоматически управляется через этот механизм.
• Следы ChromeDriver: В некоторых конфигурациях ChromeDriver переменные с префиксом cdc_ исторически определялись как индикаторы, связанные с Selenium. Однако их появление зависит от версии и реализации, поэтому их нельзя считать признаками, которые присутствуют всегда.

Таким образом, Selenium может оставлять следы, отличающиеся от Puppeteer и Playwright, поскольку использует канал управления WebDriver. Чтобы лучше понять этот механизм, можно обратиться к стандарту W3C WebDriver.

Сравнение фреймворков

Чтобы лучше понять различия, ознакомьтесь со следующей таблицей:

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

4. Как Chrome Remote Debugging связан с обнаружением автоматизации?

Chrome Remote Debugging — это механизм, который позволяет внешним инструментам подключаться к Chrome для проверки и управления браузером. В свою очередь, Chrome DevTools Protocol (CDP) — это протокол, используемый для такой связи.

Важно четко различать три понятия:

• Порт удаленной отладки: Порт подключения, который открывается при запуске Chrome с параметром --remote-debugging-port.
• Chrome DevTools Protocol (CDP): Протокол, позволяющий инструментам отправлять команды в Chrome и получать данные от браузера.
• Следы CDP: Изменения или побочные эффекты, которые могут появляться в окружении страницы, когда инструмент использует CDP для управления браузером.

Важно понимать, что обнаружение следов CDP внутри страницы не означает, что веб-сайт может напрямую получить доступ к порту отладки на вашем компьютере.

Начиная с версии 136 Chrome также изменил работу параметров удаленной отладки. Согласно объявлению Google от 17 марта 2025 года, параметры --remote-debugging-port и --remote-debugging-pipe больше не принимаются при использовании стандартного каталога данных Chrome. Чтобы продолжить использовать этот механизм, необходимо указать отдельный каталог с помощью --user-data-dir. Изменение было введено для усиления защиты файлов cookie и данных для входа. На Chrome for Testing это ограничение не распространяется.

Если вы используете удаленную отладку для разработки или тестирования, придерживайтесь нескольких принципов безопасности:

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

5. Как проверить, какие сигналы раскрывает ваш автоматизированный браузер

Для проверки информации, которую раскрывает браузер, можно использовать несколько веб-сайтов для тестирования цифровых отпечатков. Такой подход помогает выявить различия между обычным Chrome и конфигурациями, работающими через Puppeteer, Playwright или Selenium.

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

5.1. Рекомендуемые сайты для тестирования

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

• bot.sannysoft.com: Bot Sannysoft предлагает несколько тестов, связанных с navigator.webdriver, плагинами, разрешениями и другими свойствами браузера. Результаты отображаются непосредственно на странице, что позволяет определить, какие проверки выявляют необычные признаки.

• CreepJS: CreepJS анализирует множество свойств браузера, чтобы выявлять несоответствия или признаки изменения окружения. Инструмент также проводит проверки, связанные с headless-браузерами и идентификацией цифровых отпечатков, помогая лучше понять, какие данные раскрывает браузер.

• BrowserLeaks: BrowserLeaks предлагает отдельные тесты для WebGL, Canvas, WebRTC и других свойств. Вместо общего заключения об автоматизации сайт позволяет проверять каждый компонент информации, которую раскрывает браузер.

• Pixelscan: Pixelscan проверяет информацию, связанную с цифровыми отпечатками браузера, IP-адресами и согласованностью этих данных. Результаты помогают выявить определенные несоответствия в настройках браузера.

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

5.2. Процесс самостоятельной проверки за пять шагов

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

1. Зафиксируйте конфигурацию: Определите версию Chrome, используемый фреймворк, операционную систему и параметры запуска браузера.
2. Проверьте обычный Chrome: Откройте сайты для тестирования цифровых отпечатков в Chrome без автоматизации, чтобы собрать исходные результаты.
3. Запустите автоматизированную конфигурацию: Используйте свой скрипт для посещения тех же сайтов как в headless-, так и в headful-режиме и соберите результаты.
4. Сравните данные: Сопоставьте отдельные свойства в разных тестовых сессиях и зафиксируйте все различия.
5. Сохраните результаты: Сделайте снимки экрана, запишите дату тестирования и сохраните версию браузера, чтобы сравнивать результаты после каждого обновления.

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

5.3. Что может Hidemyacc и каковы его ограничения?

Hidemyacc, антидетект-браузер, — это инструмент для создания и управления профилями браузера с отдельными цифровыми отпечатками, которые можно использовать вместе с прокси для управления окружением браузера. При использовании Hidemyacc у каждого профиля есть собственные файлы cookie, прокси и цифровой отпечаток. Это помогает поддерживать согласованность данных окружения, описанных в разделе 2.4. Однако Hidemyacc не меняет саму природу автоматизации. Сигналы, связанные со способом управления браузером через CDP или взаимодействием пользователей с сайтами, по-прежнему могут обнаруживаться.

Если вам необходимо интегрировать инструменты автоматизации, обратитесь к официальной документации Hidemyacc, чтобы узнать больше о Profile API.

6. Заключение

Веб-сайты обнаруживают headless-браузеры не просто проверяя, есть ли у браузера видимый интерфейс. Вместо этого антибот-системы могут объединять информацию из HTTP-заголовков, JavaScript, CDP, цифровых отпечатков браузера, сетевых подключений и поведения пользователя, чтобы оценить посещение.

Это также объясняет, почему переход из headless-режима в headful-режим или простое изменение User-Agent не всегда решает проблему. Браузер все еще может раскрывать признаки автоматизации через способ управления им или несоответствия в его окружении.

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

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

Читайте также: Антидетект-браузеры для веб-скрейпинга: лучшие инструменты 2026 года

7. FAQ

1. Означает ли значение true у navigator.webdriver, что аккаунт будет заблокирован?

Не обязательно. navigator.webdriver — это лишь индикатор того, что браузер автоматически управляется через механизм WebDriver. Веб-сайты могут объединять эту информацию с цифровыми отпечатками, поведением пользователя и историей доступа для оценки риска. Необходимость проверки личности или ограничения аккаунта зависит от правил конкретной платформы.

2. Может ли открытие DevTools во время просмотра сайта привести к ошибочному распознаванию пользователя как бота?

Да, такая вероятность существует. Некоторые методы обнаружения автоматизации на основе CDP могут фиксировать побочные эффекты, когда Chrome DevTools открыт. Однако этого недостаточно, чтобы сделать вывод, что пользователь является ботом. Как правило, антибот-системам необходимо проверить дополнительные сигналы, прежде чем принимать решение.

3. Считается ли запуск Puppeteer в headful-режиме автоматизацией?

Да. Headless- и headful-режимы лишь указывают, отображает ли браузер видимое окно, тогда как автоматизация означает управление браузером с помощью скриптов. Поэтому Puppeteer, запущенный в headful-режиме, все еще может раскрывать сигналы, связанные с CDP или автоматизированным управлением браузером.

4. Могут ли веб-сайты увидеть, что Chrome открыл порт удаленной отладки?

Как правило, веб-сайты могут наблюдать эффекты, возникающие внутри страницы при управлении браузером, но не сам порт удаленной отладки. Следы CDP не означают, что сайт может получить доступ к порту отладки на вашем компьютере. Возможность проверки локального порта веб-страницей необходимо отдельно оценивать в каждом конкретном случае.

5. Может ли Hidemyacc предотвратить обнаружение автоматизированных скриптов?

Нельзя гарантировать, что Hidemyacc предотвратит обнаружение автоматизированных скриптов. Инструмент позволяет управлять профилями с отдельными цифровыми отпечатками, файлами cookie и прокси, что помогает поддерживать согласованность окружения браузера. Однако веб-сайты по-прежнему могут обнаруживать сигналы, связанные с CDP, способом управления браузером через скрипты и поведением пользователя.