curl_cffi или настоящий браузер, и как понять, что нужно конкретному сайту

Скрипт на requests блокируют мгновенно, вы ставите curl_cffi с impersonate="chrome", и половина сайтов начинает отвечать. Вторая половина по-прежнему отдаёт страницу с проверкой. Оба результата закономерны. Имитация починила один слой, а сайты, которые всё ещё блокируют, смотрят на что-то выше.

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

curl_cffi - HTTP-клиент для Python на основе форка curl-impersonate. В README сказано, что он умеет имитировать отпечатки TLS/JA3 и HTTP/2 браузеров; профиль выбирается аргументом impersonate, например "chrome" или "safari", а для нестандартных целей можно передать собственные строки ja3 и akamai. tls-client делает то же самое на Go: профили для распространённых браузеров, управление порядком заголовков и FFI-обвязки для Python, Node.js и C#.

Они воспроизводят ту часть запроса, которую обычная библиотека неизбежно делает неправильно:

• ClientHello: шифронаборы, расширения и их порядок, то есть то, что хешируют JA3 и JA4;
• начальные фреймы HTTP/2 и порядок псевдозаголовков, то есть то, что кодирует отпечаток HTTP/2 Akamai;
• порядок заголовков, если библиотека позволяет его задать.

Если антибот-проверка сайта работает на сетевой границе и дальше не идёт, это и есть вся проверка.

Чего она воспроизвести не может

Всего, что требует выполнить страницу.

JavaScript-проверки. Многие антибот-продукты отвечают на подозрительный первый запрос страницей со скриптом: он собирает сигналы и отправляет результат обратно, и только после этого выдаётся cookie допуска. HTTP-библиотека получает эту страницу как текст. README curl_cffi сам отсылает за JavaScript-проверками к отдельному проекту, и это честное описание границы.

Canvas, WebGL, аудио и шрифты. Эти сигналы существуют только внутри движка рендеринга. Детектор, который запрашивает хеш canvas, не получает от клиента без canvas ничего, а отсутствие ответа - тоже очень внятный ответ.

Поведение. Движения указателя, прокрутку, фокус и интервалы между событиями собирают скрипты страницы. Библиотека не порождает событий вовсе.

Сама картина запросов. Браузер, загружая страницу, тянет её скрипты, стили, шрифты и картинки в порядке, который задаёт страница. Клиент, который запросил HTML и сразу пошёл во внутренний API, создаёт трафик, какого не создаёт ни один браузер, даже если каждый отдельный запрос сымитирован идеально.

Состояние сессии помимо cookie. Сайты, которые держат состояние в localStorage, IndexedDB или в passkey, не обслужить одной банкой cookie.

Гибридная схема и где она ломается

Распространённый приём: один раз пройти проверку в настоящем браузере, перенести cookie допуска в curl_cffi и гнать основной объём уже там. Это может работать, но с условиями. Cookie допуска часто привязаны к клиенту, который их получил, поэтому профиль имитации должен совпадать с браузером, прошедшим проверку, выходной IP должен остаться тем же, а User-Agent должен называть ту же версию браузера, которую имитирует профиль TLS. Рукопожатие одного релиза Chrome при заголовке, заявляющем другой, - противоречие, которое вы создали сами.

Когда библиотека - лучший выбор

Браузер - дорогой вариант. Полноценный процесс браузера стоит сотни мегабайт и секунды на страницу. HTTP-клиент с имитацией стоит малую долю этого и выполняет тысячи запросов в минуту с одной машины.

Берите библиотеку, если:

• цель - JSON API или серверная страница, которая работает с выключенным JavaScript;
• блокировка срабатывает на границе, мгновенно, без страницы проверки;
• вам не нужно оставаться залогиненным в аккаунте несколько дней подряд;
• объём важнее любого отдельного запроса.

Браузерный инструмент, включая AntiBrow, для такой нагрузки - неверная покупка. Вы заплатите памятью и скоростью за слои, на которые сайт даже не смотрит.

Когда нужен настоящий браузер

Браузер нужен, если сайт отдаёт JavaScript-проверку, если данные появляются только после рендеринга на клиенте, если работа идёт с аккаунтами и сессия должна переживать перезапуски, или если сайт читает canvas, WebGL и поведение. Тогда имитация - не дешёвая версия того же самого. В ней просто нет проверяемого слоя.

Если вы здесь, AntiBrow даёт каждому профилю собственный отпечаток, который применяется в движке браузера ниже уровня JS и сохраняется вместе с профилем, а управлять им можно через настоящий Playwright Page. Локальные профили не ограничены ни на одном тарифе, так что попробовать ничего не стоит. Вызов launch() описан в документации SDK.

Десятиминутный тест для вашего сайта

1. Откройте нужную страницу в обычном Chrome с выключенным JavaScript в настройках сайта. Если нужные данные на месте, библиотека, скорее всего, справится.
2. Запросите https://tls.browserleaks.com/json своей библиотекой и из Chrome и сравните поля JA3, JA4 и Akamai. Устраните расхождения, прежде чем искать причину в другом месте.
3. Запросите сайт библиотекой. Мгновенный 403 без тела указывает на сетевой слой или IP. Ответ 200 со скриптом проверки указывает на слой JavaScript, и никакая настройка имитации его не исправит.
4. Повторите с того же выходного IP, что и в проде: репутация IP сама по себе может дать любой из этих результатов. Об этой стороне - в статье резидентные и серверные прокси.