Прокси-стек для AI-агентов — browser-use, Computer Use, MCP, Operator

За последние двенадцать месяцев мы увидели больше агентного трафика от нашей клиентской базы, чем за предыдущие пять лет вместе взятые. И сама его форма изменилась. Если типичный клиент 2023 года гонял воркеров на Playwright, скрейпивших одни и те же пять доменов, то типичный клиент 2026 года запускает агента на базе LLM, который идёт туда, куда ему велит его план: сравнение цен по десятку ритейлеров, ресёрч, прыгающий между отчётами SEC и стенограммами квартальных звонков, автоматизация оформления заказа на длинном хвосте мелких сайтов. Прокси-решения под такую нагрузку — это совсем не те решения, что вы приняли бы для скрейпера 2023 года, и многие создатели агентов принимают их неправильно.

Этот пост — практическая версия того, что мы рассказываем клиентам, когда они приходят с жалобой: «агент работает локально, но ломается в проде». Разберём, почему агентный трафик кажется антибот-стекам подозрительным, какая стратегия сессий реально работает, как подбирать пул под класс цели и какие схемы обвязки чаще всего выбирают клиенты для browser-use, Anthropic Computer Use, OpenAI Operator и tool-серверов в стиле MCP. Это не теория — это выжимка паттернов из нашей очереди поддержки со ссылками на резидентные, ISP-статические, мобильные и дата-центр продукты там, где они уместны.

Почему агентный трафик — приманка для антиботов

Посадите свежего LLM-агента на сайт под защитой Cloudflare с чистым резидентным IP и посмотрите, как он провалится. С IP всё в порядке. Проблема в агенте. Причина та же, по которой ранние скрипты на Selenium проваливались в 2010-х: трафик не похож на человеческий, даже когда IP похож.

Три паттерна стабильно выдают агентов.

Слишком ровный тайминг. У человека время задержки переменное: посмотрел две секунды, кликнул, посмотрел восемь, проскроллил, отвлёкся, вернулся. У LLM-агента детерминированный цикл: получить скриншот или DOM, подумать сколько-то миллисекунд, кликнуть, дождаться загрузки страницы, повторить. Интервалы между действиями плотно группируются вокруг латентности ответа модели. Поведенческие модели улавливают это в рамках сессии — после десяти взаимодействий гистограмма таймингов перестаёт выглядеть человеческой.

Вьюпорт выдаёт с потрохами. browser-use, библиотека на базе Playwright, ставшая де-факто опенсорсным агентным стеком, по умолчанию использует headless Chromium с фиксированным вьюпортом. Anthropic Computer Use снимает скриншоты с виртуального дисплея, обычно 1024x768. OpenAI Operator работает на удалённой инфраструктуре с отпечатком OpenAI. Ни один из них не попадает в распределение вьюпортов, которое антибот видит у реальных пользователей.

Траектории мыши линейны. Когда агент на Playwright кликает по координате, курсор прыгает к ней по прямой. Реальные курсоры людей выписывают дугу, проскакивают цель, корректируются, дрожат. PerimeterX и сенсорный слой Akamai особенно тщательно собирают движение мыши и плохо оценивают линейные «телепорты».

User-agent — дефолтный из фреймворка. browser-use поставляется с UA от Playwright. У Computer Use свой дефолт. Агенты, которые не переопределяют эти значения, делят отпечаток с тысячами других агентов на тех же фидах threat-intel. К моменту, когда вы направите такого на реальный сайт, дефолтный UA уже в чёрном списке.

Отсюда разделение режимов отказа. Премиальный резидентный IP не спасёт агента, чьи тайминг и вьюпорт кричат об автоматизации. Хорошо настроенному агенту с правильным стелсом всё равно нужен чистый IP. Оба слоя усиливают друг друга. Создатели, которые вкладываются только в один, недоумевают, почему их success rate посредственный.

Трёхслойная проблема детекции

Прокси — лишь один из трёх слоёв, и клиенты, которые думают только о прокси, неверно распределяют бюджет.

Слой 1: TLS-отпечаток. JA3 и JA4 — это хэши TLS ClientHello: список cipher suite, порядок расширений, поддерживаемые группы. Настоящий Chrome выдаёт конкретный JA4. Python requests с дефолтным urllib3 выдаёт другой, аккуратно ложащийся на любой другой Python-скрипт в мире. TLS-отпечаток, не совпадающий с заголовком user-agent, — это сильный сигнал автоматизации. Прокси не меняют ваш TLS-отпечаток — прокси прозрачен, ваш клиент по-прежнему формирует ClientHello, — так что это зона ответственности агента.

Слой 2: класс IP. Вот здесь и живёт прокси. ASN дата-центров (AWS, GCP, крупные колокейшены) по умолчанию помечены как повышенный риск. Резидентные ASN от настоящих ISP оцениваются выше. Мобильные операторы оцениваются выше всех, потому что цена ложного срабатывания при блокировке IP оператора слишком высока для сайта. ISP-прокси — размещённые в дата-центре, но на резидентных ASN — находятся посередине.

Слой 3: поведение. Как только запрос прошёл, сессия оценивается во времени. Движение мыши, ритм кликов, паттерны скролла, время на странице. Агенты по умолчанию плохи на этом слое.

Ловушка: исправите только один слой — два других вас пометят. Премиальный резидентный с Python-овским TLS-отпечатком провалится. Настроенный headless Chrome на IP из AWS провалится. Прокси — часть ответа, а не весь ответ.

Липкие vs ротируемые: проблема сессий агента

Это самая частая ошибка конфигурации, что мы видим. Клиенты приходят из мира скрейпинга, где ротация-на-каждый-запрос — это дефолт, настраивают агента так же и тут же ломают сохранение состояния.

Агенты сохраняют состояние. У агента, оформляющего заказ, есть корзина, сессионная cookie, CSRF-токен и состояние UI, и всё это исходит из того, что с сервером через несколько запросов разговаривает один и тот же браузер. Сротируйте IP между «добавить в корзину» и «перейти к оформлению» — и сайт инвалидирует сессию: иногда молча, иногда пометив смену IP как попытку угона. В любом случае агент теряет прогресс и идёт на повтор, а это жжёт трафик и нагнетает подозрения антибота.

Правильная настройка почти для любой агентной нагрузки — липкие сессии. На резидентных Hell World sticky задаётся через имя пользователя — суффикс-токен сессии вида username-session-abc123 — и держится примерно до 30 минут, прежде чем апстрим-IP сротируется. ISP-статика липкая по определению. Мобильный sticky обычно 10-30 минут в зависимости от пула.

Окно имеет значение. Слишком короткий sticky — потеряете состояние посреди флоу. Слишком длинный sticky на резидентных — нижележащий IP всё равно сротируется на апстриме, потому что резидентные IP — это реальные подключения ISP, которые цикличны. Те, у кого получается, выбирают окно чуть длиннее самой долгой задачи: для 5-минутного оформления заказа комфортен 10-минутный sticky. Для многочасовых ресёрч-сессий безопаснее ISP-статика, потому что под ней ничего не ротируется.

Для дольше живущих агентов работает второй паттерн: ротировать на каждую задачу, sticky внутри задачи. Агент берёт задачу из очереди, получает свежую липкую сессию, доводит до конца, сбрасывает сессию. Следующая задача получает новую. Это правильная форма для ферм агентов, где задачи независимы — ресёрч, проверка цен, мониторинг.

Подбор пула под класс цели

Не каждой цели нужен один и тот же прокси. Разница в цене между дата-центром и мобильными — примерно 30x в рознице, и клиенты, которые по умолчанию берут резидентные на всё, переплачивают на низкофрикционных целях.

Класс цели	Примеры	Рекомендуемый пул	Окно sticky
Tier 1 — слабый антибот	Публичная документация, новостные сайты, страницы выдачи поиска, открытые госданные, Wikipedia	Дата-центр или residential-lite	Короткое или на каждый запрос
Tier 2 — SaaS/B2B под защитой Cloudflare	Большинство SaaS-дашбордов, B2B-порталы, e-commerce среднего звена, доски объявлений	Резидентные	5-10 мин
Tier 3 — высокофрикционные, высокоценные	Банки, тикетинг, сникер-сайты, соцплатформы, премиальный стриминг, флоу с упором на аккаунты	ISP-статика выделенная или 4G-мобильные	На весь жизненный цикл сессии

Tier 1 — это где создатели агентов жгут деньги. Если ваш агент ресёрчит публичную информацию с сайтов без антибота, дата-центр-прокси подойдёт и обойдётся на порядок дешевле. Единственная причина платить больше — гео-покрытие, которого у дата-центра нет.

Tier 2 — основная масса агентного трафика в нашей очереди. Большинство B2B SaaS использует Cloudflare Bot Management на умеренной чувствительности. Резидентные с sticky на 5-10 минут — стандартный ответ. Бюджетные пулы здесь проваливаются даже там, где премиальные справляются — мы разбирали почему в посте про ландшафт антибот-защиты: дешёвые резидентные быстро переиспользуют IP, и свежая история злоупотреблений к ним прилипает.

Tier 3 — это где агенты либо дорого преуспевают, либо дёшево проваливаются. Флоу с упором на аккаунты — всё, что под логином, всё, где есть антифрод-команда, — наказывают за смену IP жестоко. ISP-статика выделенная — выбор по умолчанию. Вы арендуете конкретный IP на месяц, сайт видит, что ваш аккаунт всегда заходит с одного и того же адреса, и вы не триггерите алерты «необычное местоположение входа». Для сникер-дропов или тикетинга паттерн — мобильный sticky, подробно разобран в гайде по сникер-прокси.

Схемы обвязки

Три конфигурации, которые клиенты реально разворачивают, в общих чертах.

browser-use + резидентные sticky

browser-use принимает BrowserConfig, в который кладётся прокси-словарь в стиле Playwright:

proxy_user = "your_account-session-task42"
proxy = {
  "server": "http://gate.hellworld.io:7777",
  "username": proxy_user,
  "password": "your_password"
}

Токен сессии в имени пользователя (-session-task42) удерживает окно sticky. Выбирайте токен на каждую задачу, держите его на время задачи, сбрасывайте по её завершении. Планировщику агента знать о прокси не нужно — он видит страницу, которую загрузил Playwright, а это страница, прошедшая через прокси. Скомбинируйте с UA от Chrome и настроенным вьюпортом — и вы получите рабочий tier-2-стек.

Anthropic Computer Use + ISP выделенный

Computer Use работает в контейнере с виртуальным дисплеем. Исходящий трафик идёт через тот HTTP/HTTPS-прокси, что настроен на уровне ОС, обычно через переданные внутрь переменные окружения HTTP_PROXY и HTTPS_PROXY. Для флоу с упором на аккаунты — агент, управляющий SaaS-дашбордом, банковский флоу — направьте эти переменные на ISP-статический прокси, который вы арендовали на месяц.

Преимущество перед резидентными двойное. IP не ротируется, так что сессия стабильна столько, сколько работает агент. И один и тот же IP на нескольких прогонах против одной цели нарабатывает положительную репутацию, а не стартует с нуля каждый раз. После нескольких недель легитимного трафика с одного ISP-IP в SaaS-аккаунт антибот-стек выучивает, что этот IP плюс этот аккаунт — нормальная пара.

MCP-сервер с резидентными sticky на каждую задачу

MCP (Model Context Protocol) — стандарт Anthropic для tool-серверов: агенты вызывают инструменты вроде fetch_url или search_web, которые выставляет MCP-сервер. Когда эти инструменты делают исходящие HTTP-запросы, конфиг прокси держит MCP-сервер; агент его не видит никогда.

Паттерн: сервер берёт task_id от агента, выводит из него токен сессии и маршрутизирует запросы через username-session-${task_id} на резидентных. Каждая задача получает свой собственный липкий выход; когда задача завершается, сессия сбрасывается. Это самое чистое разделение, что мы видим в продакшен-стеках: агент планирует, слой MCP занимается сетевой идентичностью, а изоляция на каждую задачу ограничивает перекрёстное заражение, если один IP получит флаг.

Гео важнее, чем думают создатели агентов

Удивительно много создателей агентов забывают, что «изучить актуальные цены в Германии» требует выходного IP в Германии. Они запускают агента из американской обвязки на американском резидентном IP, агент ищет в Google, Google возвращает результаты google.com на английском с американскими ценами, и агент послушно докладывает их как немецкие. Агент не знает ничего лучше. Пользователь получает плохой результат и винит модель.

Резидентные Hell World покрывают 210 стран с таргетингом на уровне страны, региона и города. Гео-селектор кладётся в имя пользователя — username-country-de-session-task42 для немецкого резидентного выхода. Для агентов, делающих локализованный ресёрч, заложите гео-осознанность в планировщик: когда задача говорит «в Германии», вызов инструмента указывает гео. Разбивка гео-покрытия по 14 брендам есть на странице сравнения, если нужно знать, что именно мы тестировали.

Математика затрат

Типичная задача агента сжигает 50-300 МБ трафика в час в зависимости от того, скриншото-тяжёлая она (Computer Use) или DOM-тяжёлая (browser-use). По нашей резидентной ставке $0.23/GB час работы агента стоит однозначные центы. На фоне стоимости инференса LLM это пренебрежимо мало.

Цифра, которая растёт быстро, — это повторы. Агент, который упирается в CAPTCHA, проваливается, перепланирует, повторяет, снова проваливается, легко может в 5-10 раз раздуть трафик на одной задаче. Промежуточные страницы-челленджи грузят картинки и JS, и всё это тарифицируется. Оптимизация затрат, которая действительно важна, — избегать повторов: выбрать правильный пул с первого раза, корректно держать липкие сессии, настроить стелс агента так, чтобы он не триггерил челлендж. Экономия $0.05/GB на бюджетном пуле меркнет на фоне потери 30% задач на повторах.

Что мониторить

Метрики, которые ловят проблемы рано, в порядке приоритета:

Success rate по каждой цели. Группируйте задачи по домену назначения. Падение в одной группе означает, что эта цель закрутила гайки или IP вашего пула попали в её чёрный список. Локализованный сигнал каждый раз бьёт общий success rate.

Время жизни сессии до флага. Сколько запросов отрабатывает липкая сессия, прежде чем получить челлендж? Если это значение падает со временем — ваш пул деградирует или ваше поведение протекает. Если оно варьируется по целям — у вас есть тюнинг под конкретную цель.

Состав класса выходных IP. Сэмплируйте выходы и проверяйте распределение ASN. Если вы купили резидентные, а 20% выходов показывают ASN дата-центров — ваш пул мешает классы, поговорите с провайдером.

Чего прокси починить не могут

Мы продаём прокси, так что скажем прямо: никакой прокси не починит плохо инженерно сделанного агента. Если TLS-отпечаток неправильный — IP не имеет значения. Если тайминг роботизированный — IP не имеет значения. Если вьюпорт дефолтный из фреймворка — IP не имеет значения. Стелс и репутация IP — независимые слои, и оба должны быть правильными.

Мы видели, как бюджетные пулы работают для настроенных агентов и как премиальные пулы проваливаются для небрежных. Потратьте первую итерацию на агента — приведите в порядок user-agent, вьюпорт, TLS-отпечаток и тайминг. И только потом добавляйте прокси. Порядок важен, потому что отладка идёт куда быстрее, когда вы знаете, что сам агент чист.

Как только это так, прокси-слой становится осмысленным рычагом. Работа Tier 1 переезжает на дата-центр и экономит деньги. Tier 2 выбирает правильный резидентный бренд и перестаёт спотыкаться о Cloudflare. Tier 3 уходит на ISP или мобильные и перестаёт получать флаги на флоу под логином. Страница сравнения — отправная точка для выбора пула; на страницах резидентных, ISP, мобильных и дата-центр есть конкретика. Подбирайте по классу, корректно настраивайте sticky, гео-таргетируйте там, где требует задача, мониторьте прод. Вот и весь стек.