navigator.webdriver и следы Selenium: как боты палятся за 1 секунду

Можно купить самые дорогие мобильные прокси, идеально подменить Canvas и аудио, выстроить безупречное поведение — и всё равно спалиться за долю секунды на одном-единственном флаге. navigator.webdriver = true — это как выйти на дело в футболке с надписью «я робот». И это лишь верхушка айсберга: браузер, которым управляет Selenium, Playwright или Puppeteer, оставляет десятки следов автоматизации, по которым антифрод Яндекса вычисляет бота ещё до того, как тот успеет проскроллить первый экран.

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

Главный маркер: navigator.webdriver

Свойство navigator.webdriver введено в стандарт специально, чтобы сайты могли понять: браузером управляет автоматизация, а не человек. Когда Chrome запускается под управлением WebDriver-протокола, этот флаг равен true. У обычного пользователя он всегда false или отсутствует. Проверка занимает одну строчку JavaScript, и её делает буквально каждая серьёзная антибот-система.

Наивные ботоводы даже не знают о его существовании. Те, кто поумнее, пытаются переопределить свойство через Object.defineProperty — но и здесь есть подвох: неаккуратная подмена сама становится следом (об этом ниже). Правильно спрятанный webdriver — это не «затёртый», а такой, которого будто и не было изначально.

Следы конкретных инструментов

ChromeDriver (Selenium)

ChromeDriver впрыскивает в страницу служебные переменные с характерными именами вида cdc_asdjflasutopfhvcZLmcfl_ — их можно найти в объекте document и в свойствах массивов. Это уникальная подпись Selenium: ни один живой Chrome таких переменных не содержит. Антибот-скрипты просто ищут ключи по маске cdc_ — и всё, автоматизация обнаружена.

Puppeteer / Playwright (CDP)

Эти инструменты управляют браузером через Chrome DevTools Protocol. Активная CDP-сессия оставляет свои артефакты: специфическое поведение Runtime.enable, следы в стеке ошибок, аномалии в тайминге исполнения. Плюс headless-режим по умолчанию выдаёт себя десятком косвенных признаков.

Headless-браузер

Запуск «без графической оболочки» — экономно для сервера, но опасно для маскировки. Классические маркеры headless:

• navigator.plugins пустой (у реального Chrome есть встроенные плагины);
• navigator.languages пустой или нестандартный;
• отсутствует объект window.chrome либо он неполный;
• Permissions API даёт противоречивые ответы (например, уведомления «granted», хотя реально «default»);
• нет плавных таймингов рендеринга, характерных для видимого окна.

Почему это смертельно именно для накрутки ПФ

В отличие от отпечатков, которые работают статистически (кластеризация), следы автоматизации — это бинарный приговор. Если антифрод видит cdc_-переменные или webdriver = true, ему не нужна статистика: перед ним стопроцентный бот. Такой визит не просто не учитывается в поведенческих — он помечает весь профиль как автоматизированный, а при массовости подтягивает под подозрение и сайт, на который льётся трафик.

Отпечаток говорит «эти сто визитов подозрительно похожи». Флаг автоматизации говорит «это точно робот». Второе — гораздо хуже.

Именно поэтому дешёвые сервисы накрутки, работающие на «голом» Selenium без стелс-обвязки, сливают бюджет заказчика: их трафик Яндекс отсекает ещё на входе. Как отличить такую халтуру при выборе подрядчика, мы разберём в отдельной статье цикла про выбор сервиса.

Таблица: живой Chrome против автоматизации

Как правильно скрывать автоматизацию

1. Убирать флаг «начисто», а не «затирать»

Свойство webdriver нужно не переопределять поверх, а удалять на уровне запуска браузера — так, чтобы его не было в прототипе navigator. Грубая подмена через геттер оставляет след в дескрипторе свойства, который сам детектируется. Хорошие стелс-решения патчат это на нативном уровне.

2. Чистить cdc_-переменные

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

3. Не использовать headless «в лоб»

Либо запускать полноценный видимый браузер (пусть и на виртуальном дисплее), либо применять современный headless-режим с полной эмуляцией плагинов, window.chrome, permissions и языков. Пустой navigator.plugins — это классика палева, которую закрывают в первую очередь.

4. Проверять согласованность стелса

Парадокс: избыточная или неаккуратная маскировка сама создаёт аномалию. Например, если permissions отвечает идеально «по учебнику», но при этом объект chrome кривой — это несогласованность, которую антибот ловит. Стелс должен быть цельным, а не набором заплаток. Тот же принцип согласованности мы описывали для user-agent и cookie и для JA3/TLS-отпечатка.

5. Реалистичный ввод

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

Гонка вооружений: почему стелс всегда догоняет, а не опережает

Важно понимать природу этой борьбы. Детекторы автоматизации и стелс-обвязки находятся в бесконечной гонке. Google выпускает «новый headless» (режим, который сложнее отличить от обычного Chrome) — детекторы придумывают новые проверки. Появляется свежий стелс-плагин — антибот-вендоры добавляют тесты, которые его вскрывают. Ключевой вывод для ботовода: стелс всегда реактивен. Он закрывает уже известные проверки, но отстаёт от свежих методов детекта на недели и месяцы.

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

Какие именно проверки делают бот-детекторы

Открытые тестеры вроде bot.sannysoft и движки класса CreepFP проверяют десятки признаков. Вот основные группы, чтобы вы понимали масштаб:

• Прямые флаги: navigator.webdriver, наличие window.cdc_*, следы __nightmare, _phantom, __selenium_*.
• Целостность окружения: непустые navigator.plugins и mimeTypes, корректный window.chrome.runtime, наличие chrome.loadTimes.
• Согласованность API: Permissions API не противоречит уведомлениям, Notification.permission согласован, WebGL-вендор соответствует платформе.
• Поведение движка: тайминги исполнения, порядок срабатывания событий, особенности отрисовки, характерные для видимого окна.
• Целостность прототипов: проверка, не переопределены ли нативные функции (грубая подмена через toString геттера выдаёт себя).

Обратите внимание на последний пункт: он объясняет, почему «затирание» флагов через Object.defineProperty опаснее, чем кажется. Детектор проверяет не только значение свойства, но и то, как оно определено. Родное свойство и подделанное геттером различаются на уровне дескриптора — и это ловится.

Почему это фундамент, а не деталь

В цикле про отпечатки мы разбирали железо, аудио, Canvas/WebGL — все они работают статистически. Следы автоматизации стоят особняком: это не «подозрительное сходство», а прямое доказательство робота. Поэтому в правильной последовательности работы они закрываются первыми. Нет смысла шлифовать аудио-шум и покупать мобильные прокси, если navigator.webdriver кричит «я бот» на входе. Сначала — чистота от автоматизации, потом — отпечатки, и только потом — поведение и объёмы визитов.

Чек-лист проверки на следы автоматизации

1. Проверьте navigator.webdriver — должно быть false или undefined.
2. Просканируйте объекты страницы на ключи по маске cdc_ — их не должно быть.
3. Убедитесь, что navigator.plugins и navigator.languages непустые и правдоподобные.
4. Проверьте наличие полноценного window.chrome.
5. Прогоните профиль через открытые бот-детекторы (bot.sannysoft, CreepJS-подобные) — не должно быть красных флагов.
6. Сверьте permissions: ответы не должны противоречить реальному состоянию.

Частые вопросы

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

Реально ли Яндекс проверяет webdriver, или это только облачные защиты? Проверить navigator.webdriver — одна строка JS, и это делают все, кому важно качество трафика, включая аналитические системы. Полагаться на то, что «Яндекс не смотрит», — наивно. Считайте, что смотрят все.

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

Вывод

Следы автоматизации — это не «одна из проблем», а первый барьер, о который разбивается некачественная накрутка. Пока navigator.webdriver равен true, а в странице живут cdc_-переменные, никакие прокси и отпечатки не спасут: Яндекс видит робота напрямую и не засчитывает поведение. Правильная работа — это чистое удаление флага автоматизации, вычистка следов драйвера, отказ от «голого» headless, цельный согласованный стелс и реалистичный ввод. Только когда автоматизированный браузер неотличим от живого Chrome, накрутка начинает работать на позиции, а не против них.

Больше о поведенческом продвижении и других услугах — на главной странице ProfSEO24.