Интеграция анти-капчи в Selenium, Puppeteer и Playwright без лишнего флага

Интеграция анти-капчи в Selenium, Puppeteer и Playwright без лишнего флага

У всех трёх стеков одна задача: не ломать тайминги, не рвать flow и не плодить лишние запросы к анти-капча API. Разница не в самой “разгадке”, а в том, где вы встраиваете ожидание: до перехода, после submit или на этапе JS-челленджа.

Selenium чаще всего упирается в явные ожидания: ловите появление iframe/textarea, забираете sitekey, отправляете задачу, затем прокидываете token через executeScript. Важный момент — не триггерить повторный рендер формы без нужды. Если страница чувствительна к смене DOM, лучше вставлять токен точечно, а не перезагружать узел целиком.

Puppeteer и Playwright удобнее на уровне событий: можно ждать networkidle, перехватывать запросы и подставлять решение до сабмита. Для JS-челленджей полезно хранить state одной сессии: cookies, localStorage, UA и viewport должны совпадать с тем, в чём вы получили токен. Иначе защита увидит не “решение”, а рассинхрон 🌐

Базовый чек-лист одинаковый: — не смешивать разные прокси в одной цепочке; — не менять отпечаток браузера между получением и применением токена; — проверять, что ответ сервиса реально вставился в нужное поле, а не только вернулся из API; — делать fallback на повторную задачу, если капча живёт дольше обычного.

Снижаем косты на распознавание: сначала стабилизируйте ожидания и контекст, потом уже добавляйте сервис. Когда интеграция привязана к событиям браузера, а не к “магическим” sleep, парсинг становится заметно ровнее.