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

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

У всех трёх стеков одна задача: вытащить challenge-страницу, отдать её в API решения и аккуратно вернуть токен в нужное поле. Ошибки почти всегда не в распознавании, а в том, как вы ловите момент появления капчи и куда потом подставляете ответ.

— Selenium: чаще всего нужен явный wait на iframe или textarea, а потом работа через execute_script, если инпут скрыт.
— Puppeteer: удобнее перехватывать DOM-сигнал и ставить токен через page.evaluate, чтобы не зависеть от кликов.
— Playwright: стабилен за счёт locator и auto-wait, но всё равно лучше проверять, что token реально записался до submit.

Самая частая поломка — гонка между получением токена и отправкой формы. Если submit уходит раньше, чем JS на странице подхватил значение, анти-фрод видит пустой ответ. Поэтому после вставки токена всегда ждите состояние success, а не просто завершение promise. Это снижает ложные ретраи и экономит баланс на повторных запросах 🔧

Если у вас несколько типов капчи, держите один слой-адаптер: normalize challenge, solve, inject, verify. Тогда смена движка не ломает логику, а меняется только транспорт и селекторы. Снижаем косты на распознавание: сначала стабилизируем пайплайн, потом уже меняем сервисы.