Эта статья была полезной?
Как выбрать между API-солвером и браузерным расширением
Технический специалист
Если капчи попадаются вам регулярно, есть по сути два способа с ними справляться: поставить расширение и дать ему решать всё автоматически по ходу браузинга, либо обратиться к API и получить обратно решённый токен, который нужно вставить самому. Часто спрашивают, какой способ "лучше" — но вопрос сформулирован неверно, потому что они решают разные задачи. Попробуйте заскрапить сайт headless-браузером с расширением — оно там просто не запустится. Попробуйте настроить API-вызов для обычного ручного просмотра страниц — и вы потратите полдня на код там, где хватило бы установки в два клика.
Разберём, как каждый способ работает на самом деле, и как понять, какой подходит именно вам.
Что происходит внутри
Расширение сидит внутри реального окна браузера и следит за страницей. Как только оно замечает капчу, оно забирает параметры, отправляет их сервису решения в фоне и подставляет готовый токен обратно на страницу — без единой строчки кода с вашей стороны. Со стороны выглядит так, будто капча просто... исчезает.
API за вас ничего этого не делает. Sitekey и URL страницы нужно достать самому (иногда есть и дополнительные поля, вроде action или data), отправить запрос, дождаться токена и вставить его на страницу собственным кодом. Каждый шаг лежит на вас — но зато каждый шаг под вашим контролем.
Сравнение
| Критерий | Браузерное расширение | API |
|---|---|---|
| Настройка | Установили один раз — и всё | Пишете интеграцию сами |
| Работает в headless | Нет | Да |
| Хорошо подходит для | Ручного браузинга, QA-проверок | Скрапинга, автоматизации, массовых задач |
| Масштаб | Одна сессия за раз | Тысячи запросов параллельно |
| Контроль над retry/таймаутами | Как решит расширение | Полностью на вас |
| Нужен код | Нет | Базовые навыки скриптинга |
| Встраивается в существующий пайплайн | Практически нет | Да |
Расширение: когда это правильный выбор
Если за браузером реально сидит человек, расширение обычно проще:
- Обычный браузинг, где капчи то и дело всплывают и мешают
- Ручное тестирование формы, на которой случайно оказалась капча
- Разовая задача, которой не нужен масштаб
- Просто не хочется писать код под это
Оно само извлекает sitekey, само обращается к API и само вставляет токен — установили, залогинились, работает. Но стоит держать в голове: оно не покрывает вообще все типы капч, и даже для поддерживаемых типов иногда может дать сбой на сайте с нестандартной верстой. Прежде чем рассчитывать на него для конкретной задачи, стоит проверить список поддерживаемых типов.
API: когда это правильный выбор
API оправдывает себя в тот момент, когда в цепочке нет человека, либо когда одного решённого токена мало:
- Скрапинг или автоматизация в headless-режиме — расширение там просто не загрузится
- Решение сотен или тысяч капч в рамках более крупного пайплайна
- Встраивание решения капчи прямо в скрипт на Selenium, Playwright или Puppeteer
- Своя логика повторных попыток и таймаутов вместо того, что делает расширение по умолчанию
- Backend-сервисы, которым нужен решённый токен вообще без интерфейса браузера
Расплата — интеграцию нужно собрать самостоятельно: достать sitekey, отправить запрос, опросить результат, вставить токен. Туториалы по конкретным типам капч в этом разделе разбирают именно эти шаги для каждого типа отдельно.
Использовать оба сразу
Большинство команд, которые хоть что-то скрапят или автоматизируют, в итоге пользуются обоими способами — просто на разных этапах. Расширение реально удобно во время разработки и отладки: можно смотреть, как капча решается в реальном времени, и проверять, что селекторы действительно работают. Когда скрипт стабилизировался и готов к запуску на сервере, расширение убирают и заменяют прямым вызовом API — потому что продакшен обычно работает headless, и расширению там всё равно негде находиться.
Где у каждого способа проблемы
Расширение поддерживает не все типы капч, и даже для поддерживаемого типа покрытие на конкретном сайте не гарантировано — структура страницы, кастомные callback-функции или нестандартное расположение виджета легко могут его сбить. Ему также нужна реальная видимая сессия браузера, поэтому масштабирование дальше нескольких параллельных запусков не работает, а если капча не решилась — остаётся полагаться на то, что заложено внутри самого расширения.
У API таких ограничений нет — он покрывает все типы капч из документации независимо от сайта. Но параметры конкретного типа нужно знать самому, код запроса и опроса результата — писать самому, а вставку токена реализовывать так, как этого ожидает конкретный виджет — и это выглядит по-разному для reCAPTCHA, Turnstile, GeeTest и всего остального.
Как быстро определиться
- За браузером сидит живой человек и просматривает страницы вручную? Берите расширение.
- Скрипт работает headless или на сервере? API.
- Нужно решать больше нескольких капч подряд? API.
- Всё ещё тестируете и отлаживаете перед деплоем? Расширение на этапе разработки, API — когда всё готово к запуску.
- Нужна своя логика retry/таймаутов/прокси? API.
- Тип капчи не поддерживается расширением, или оно ведёт себя нестабильно именно на этом сайте? API.