Автоматизация ChatGPT и Claude через веб-интерфейс: как работают антибот-защита и антидетект-браузеры

Хотите попробовать Octo Browser со скидкой?
По промокоду OCTOBLOG получите 30% скидку на любую подписку. Предложение действительно только для новых пользователей.

Зачем автоматизировать веб-интерфейс, если есть API

У OpenAI и Anthropic есть официальные API с подробной документацией. Зачем тогда строить сложную инфраструктуру и бороться с защитой? Причин три.

1. Экономия на масштабе. В API вы платите за каждый обработанный фрагмент текста. При массовой генерации, переводе больших баз или работе агентов счета доходят до тысяч долларов. Подписки ChatGPT Plus и Claude Pro стоят по 20 $ в месяц, старшие тарифы — 200 $ ChatGPT Pro и от 100 $ Claude Max. Даже с учетом лимитов на число сообщений работа через сайт может обходиться в разы дешевле.

2. Возможности, которых нет в API. Сайты нейросетей — их главные продукты. Поиск по интернету, запуск кода, отдельные модели и инструменты либо не доступны через API, либо появляются там позже и с ограничениями.

3. Теневой API. Большая часть серого рынка — неофициальные API на основе сайтов нейросетей. Разработчики запускают сотни браузерных сессий, превращают сайт в привычный REST API и продают доступ в 10 раз дешевле официальных тарифов. Так, например, работают многие телеграм-боты, которые дают доступ к нейросетям без VPN.

Типичный сценарий: у вас таблица на тысячи строк, и для каждой нужен ответ модели. Вручную это не сделать, через API дорого или нужной модели там просто нет. В этот момент автоматизация сайта и становится выгодной.

Почему бы тогда не взять Selenium или Puppeteer и не написать простой скрипт? Проблема в том, что ИИ-компании тоже считают деньги. Им важно не только продать подписку, но и перевести бизнес-клиентов на платный API. Поэтому сайты нейросетей защищены серьезно, и простой скрипт с браузером без интерфейса здесь не справится. Впрочем, сейчас он мало где справляется.

Почему стандартные инструменты автоматизации не работают

Прежде чем говорить о решении, разберемся, в чем проблема. Что будет, если обратиться к сайту ChatGPT или Claude напрямую, простым скриптом?

Современная защита давно не ограничивается блокировкой по IP-адресу. Она проверяет запрос на нескольких уровнях и останавливает автоматизацию в трех основных случаях.

Уровень 1. Соединение: скрипты без браузера (requests, axios)

В теории запрос от обычного скрипта должен получить отказ — ошибку 403 или 429 — еще до того, как начнется обмен данными. Защита смотрит на то, как клиент устанавливает защищенное соединение, то есть на TLS-отпечаток. У каждого браузера свой узнаваемый почерк: набор и порядок параметров, которые он отправляет серверу в первом пакете (Client Hello). На этом построены отпечатки JA3 и JA4. У сетевых библиотек вроде OpenSSL или urllib этот почерк другой. Если скрипт представляется десктопным Chrome, а соединение устанавливает как библиотека, сервер заметит несоответствие и может оборвать связь.

На практике защита действует тоньше. Если IP-адрес не в черных списках, сервер может ответить 200 OK, но вместо рабочего сайта отдаст пустую страницу или страницу проверки Cloudflare Challenge. Чтобы пройти дальше, нужно выполнить обфусцированный JavaScript-код. У скрипта без браузера нет JS-движка, поэтому на этом его работа и заканчивается.

Пример работы простого скрипта

Уровень 2. Браузер: Puppeteer или Selenium без доработок

Раз без выполнения JavaScript не обойтись, следующий логичный шаг — headless-браузер, то есть браузер без интерфейса. Такой браузер спокойно установит соединение, загрузит страницу и начнет выполнять скрипты, но застрянет на невидимой проверке Cloudflare Turnstile. Со стороны это выглядит как страница Just a moment… или бесконечно крутящийся чекбокс.

Если посмотреть на сетевые запросы, видно, что браузер отправляет телеметрию на эндпойнты challenge-platform и получает ответ, но система раз за разом не выдает cookie-токен cf_clearance, открывающий доступ к сайту.

Дело не в том, как скрипт кликает, — до кликов мы еще не дошли. Браузер сам сообщает защите признаки автоматизации:

• Флаг автоматизации. Браузер под управлением скрипта помечает себя свойством navigator.webdriver = true. Selenium работает через WebDriver, Puppeteer — через протокол CDP, но оба запускают браузер с этой пометкой. Защита легко ее находит, даже если попытаться скрыть ее простыми JS-инъекциями.

• Графика без видеокарты (WebGL/Canvas). На сервере или в Docker-контейнере видеокарты нет, и браузер рисует графику силами процессора. Защита запрашивает данные о графической системе и видит в WebGL Renderer типичную серверную программную отрисовку — ANGLE поверх SwiftShader. Дополнительно она незаметно рисует картинку в скрытом Canvas-элементе и сравнивает ее хеш с ожидаемым.

Увидев пометку автоматизации и отрисовку без видеокарты, система понимает, что перед ней серверный бот. 

Вас не блокируют, а отправляют на бесконечные проверки, так и не пустив к нейросети

Уровень 3. Поведение: обрыв ответа

Главная трудность ждет дальше. Ответ нейросети приходит по частям через постоянное соединение с сервером — Server-Sent Events (SSE) или WebSocket. Все это время система продолжает оценивать сессию.

Если она замечает, что курсор мгновенно перескакивает к нужным кнопкам, а не движется плавно, с ускорением и легким дрожанием, как у человека, ответ может оборваться посреди генерации. В случае WebSocket соединение закроется с кодом 1006 Abnormal Closure. Курсор — лишь пример: защита анализирует гораздо больше сигналов.

В худшем случае аккаунт попадет в теневой бан. Вы остаетесь в аккаунте, скрипт отправляет POST-запросы с промптами, но в ответ приходит пустой JSON или сообщение о «временной ошибке генерации».

Тупик стандартных решений

Если свести три уровня вместе, получается следующее: HTTP-клиенты бесполезны без JS-движка, а стандартные инструменты автоматизации выдают себя флагом navigator.webdriver, программной отрисовкой графики и синтетическими событиями ввода.

Можно пойти по пути наименьшего сопротивления: пропатчить Selenium или Puppeteer парой JS-инъекций и подключить сервис решения капчи. Только стоит сразу заложить на него бюджет, потому что капчи будет много, а стабильности это все равно не даст.

Есть и другой путь: построить устойчивую систему работы с веб-интерфейсами LLM. Она должна обеспечивать три вещи.

1. Полноценную среду. Настоящий браузерный движок, который выполняет обфусцированные проверки так же, как обычный Chrome.

2. Незаметное управление. Протокол управления не должен оставлять следов в объекте window: никаких флагов автоматизации и переменных WebDriver.

3. Согласованность с железом. Хеши Canvas и WebGL, набор шрифтов и другие параметры должны соответствовать заявленной видеокарте и операционной системе, а не выдавать виртуальный сервер.

Как выполнить эти требования, не переписывая ядро Chromium самостоятельно?

Антидетект-браузер как основа инфраструктуры автоматизации

Решение пришло из арбитража трафика и мультиаккаунтинга. Это антидетект-браузеры, в нашем случае Octo Browser. Главное их отличие от пропатченного Puppeteer — в уровне подмены отпечатков. Она происходит не через JS-скрипты, а в исходном коде движка Chromium.

Важно понимать: Puppeteer тоже работает по протоколу CDP, так что разница не в способе управления. Разница в самом браузере, к которому подключается скрипт. Имеет значение, какие отпечатки он отдает и есть ли в нем маркеры автоматизации.

Что это дает на практике:

• Правдоподобные параметры видеокарты. Вместо программной отрисовки через SwiftShader браузер отдает параметры реального железа — Nvidia, AMD или Apple Silicon. Хеши Canvas и WebGL при этом согласованы с заявленной видеокартой.

• Изоляция профилей. Каждый аккаунт ChatGPT или Claude работает в отдельном зашифрованном профиле. У профиля свои шрифты, параметры WebRTC и часовой пояс.

• Управление через локальный API и CDP. Окружение не нужно настраивать в коде. Профиль запускается через локальный REST API браузера, а скрипт подключается к нему по CDP-порту.

В такой схеме скрипт на Python или Node.js отвечает только за логику. Он берет исходные данные, формирует промпт, отправляет его в веб-интерфейс нейросети, запущенный в антидетект-браузере, и забирает результат. Соответствие требованиям антифрод-систем обеспечивает подготовленная среда.

Архитектура решения: сохраненные профили и подключение по CDP

В итоге работа с веб-интерфейсом нейросети превращается в стабильный конвейер, в котором антидетект-браузер выполняет две роли.

1. Среда первичной подготовки. Вы один раз открываете интерфейс в обычном окне профиля и работаете как обычный пользователь: вручную входите в аккаунт и проходите капчу, если она появится. Браузер сохраняет куки, кэш и токены авторизации в изолированном профиле. Для сервера это обычный человек, который просто закрыл вкладку.

2. Узел инфраструктуры. Когда нужно запустить автоматизацию, скрипт через локальный API запускает уже подготовленный профиль и подключается к нему по CDP.

Профиль уже авторизован, поэтому при переходе на chatgpt.com или claude.ai сразу открывается окно чата. Повторный вход и капча не нужны: для Cloudflare это продолжение ранее проверенной сессии доверенного устройства. Таких профилей-устройств может быть несколько.

Роли в этой схеме распределены так: антидетект-браузер подменяет параметры железа на уровне ядра, подключает прокси и хранит куки, скрипт отправляет промпты и забирает ответы, а CDP связывает их между собой. По сути, браузер используется по прямому назначению, просто вместо человека им управляет код.

Заключение

Защита веб-интерфейсов LLM проверяет клиента на трех уровнях: как он устанавливает соединение, в какой среде выполняется и как ведет себя в сессии. Поэтому точечные решения вроде stealth-плагинов, JS-патчей или смены прокси дают в лучшем случае временный результат. Они закрывают одну проверку и оставляют открытыми остальные.

Устойчивая автоматизация строится от среды, а не от скрипта. Браузер с согласованными отпечатками на уровне ядра, заранее подготовленные профили и управление по CDP снимают с кода задачу маскировки. Скрипту остается только его прямая работа: отправлять промпты и обрабатывать ответы.

При этом стоит трезво оценивать риски. Системы защиты продолжают развиваться, а автоматизированный доступ к веб-интерфейсам противоречит условиям OpenAI и Anthropic. Любая подобная схема требует поддержки, и важно понимать, как устроена защита, с которой вы работаете.