Автоматизация в антидетектах ломается не в коде, а в слое браузерной идентификации

Автоматизация в антидетектах ломается не в коде, а в слое браузерной идентификации

Puppeteer и Playwright управляют Chromium через DevTools Protocol, но антифрод чаще смотрит не на сам факт automation, а на согласованность окружения: navigator.webdriver, график таймеров, WebGL vendor, permissions, media devices, Intl и поведение TLS Client Hello.

Разберем энтропию данного параметра: если вы меняете только User-Agent, а Canvas, AudioContext и timezone остаются из другой «личности», профиль становится токсичным. Схема должна быть цельной:
• единый fingerprint на уровне профиля;
• синхронные locale, timezone, language и geolocation;
• одинаковые шрифты, WebGL и hardwareConcurrency;
• предсказуемая сетка прокси и DNS-резолва.

В Puppeteer слабое место — поверхностные патчи через JS-инъекцию. Их легко вскрывают проверки на property descriptors, toString() у переопределенных функций и аномалии в Permissions API. В Playwright поведение стабильнее на уровне контекста, но без корректной подмены окружения он так же оставляет следы: изоляция storage, рассинхрон заголовков и несоответствие между браузерным профилем и сетевым стеком.

Под капотом Chromium API нужно трогать не отдельные поля, а всю цепочку: профиль, прокси, TLS Client Hello, WebRTC, canvas, audio, idle state. Иначе автоматизация выглядит как «живой» браузер только до первого глубокого чекера.

Практика простая: сначала соберите эталонный профиль, затем прогоните его через Pixelscan, CreepJS и BrowserLeaks, и только потом подключайте сценарии. Иначе вы автоматизируете не действия, а детект.