Браузерная автоматизация — headless Chrome, Playwright, Puppeteer, Selenium — подключается к прокси не так, как обычный HTTP-клиент: адрес прописывается в параметрах запуска драйвера, а не в системных настройках ОС. Ошибка в этой связке выдаёт бота раньше, чем сработает любая антидетект-настройка, а сама автоматизация тратит трафика в разы больше, чем кажется на старте. Разберём, как канал встраивается в цепочку браузер—драйвер—сеть, откуда берётся лишний расход гигабайт и что реально его снижает.

Как прокси подключается к headless-браузеру и драйверу

У headless-браузера адрес не «системный», а прописан в параметрах запуска: у Chromium — флаг «--proxy-server=host:port», у Playwright и Puppeteer — поле proxy в опциях контекста, у Selenium — объект Proxy в capabilities драйвера. Системная настройка заворачивает весь трафик машины, включая фоновые процессы; настройка на уровне драйвера действует только внутри сессии браузера — это и нужно, когда на одной машине параллельно живут десятки профилей с разными адресами.

Авторизация — логином и паролем в URL (работает в Playwright и Puppeteer через параметры контекста, но не при запуске Chromium одним флагом) или привязкой к белому IP сервера автоматизации. Второй способ надёжнее для CI-раннера с фиксированным исходящим адресом: пароль прокси не нужно хранить в переменных окружения.

Почему автоматизация ест трафика больше, чем кажется

Человек, листая страницу, видит только верхнюю часть экрана. Драйвер по умолчанию грузит страницу целиком: шрифты (сотни килобайт на семейство), скрипты аналитики и рекламных сетей, пиксели ретаргетинга, вебсокеты чатов поддержки. Ни один из этих элементов не нужен для проверки цены или текста, но загружается вместе с целевым контентом.

На карточке товара полезные данные — HTML с ценой и характеристиками — весят десятки килобайт, а остальные 2–5 МБ страницы — картинки, шрифты и сторонние скрипты, о которых задача ничего не знает. Это и есть переплата за трафик, который никогда не попадёт в результат. Подробный разбор, что отключать и как считать экономию по шагам, — в статье как сократить расход ГБ на прокси.

Отключение медиа — основной способ экономии

Главный рычаг экономии — блокировка того, что не идёт в результат парсинга, на уровне драйвера, а не выбор более дешёвого канала. У Playwright и Puppeteer это перехват запросов с отменой типов image, media, font, иногда stylesheet. У Selenium с Chrome тот же эффект даёт профильная настройка с отключением загрузки изображений.

Эффект — снижение веса страницы в 3–10 раз в зависимости от исходного числа картинок и видео. Для задач, где нужен только текст — цена, наличие, статус заказа, — блокировка медиа не влияет на результат: данные лежат в HTML, а не в самих изображениях. Погоня за самым дешёвым каналом вместо отключения медиа часто даёт обратный эффект — разница разобрана в статье дешёвые против дорогих прокси.

Согласованность locale, часового пояса и языка запроса с гео адреса

Смена IP не меняет автоматически ни locale браузера, ни системный часовой пояс, ни заголовок Accept-Language. Если адрес выдан как американский, а контекст сообщает часовой пояс Europe/Moscow и русский язык, площадка получает противоречивые сигналы. Часть площадок отдаёт контент по языку заголовка, а не по IP, так что рассинхрон меняет саму выдачу, а не только повышает подозрительность сессии.

У Playwright и Puppeteer locale, timezoneId и заголовки задаются в опциях контекста при создании страницы и должны синхронизироваться с гео адреса при каждом запуске, а не один раз для всех профилей разом. Чек-лист связки «профиль плюс канал», включая проверку WebRTC и DNS, — в статье прокси для антидетект-браузера пошагово.

Параллельные профили и отдельный порт на профиль

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

Правило простое: отдельный порт и устойчивый на время сессии адрес — на каждый параллельный профиль. Это увеличивает число закупаемых каналов, но убирает оба источника повторов. Управлять сменой адреса на каждом порту программно, без ручной пересборки конфигурации перед запуском, позволяет ротация по API — она разобрана в статье как настроить ротацию IP по API.

Частые вопросы

Можно ли использовать один прокси для нескольких headless-профилей одновременно?

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

Отключение картинок и шрифтов не сломает ли парсинг данных?

Нет, если нужные данные лежат в HTML, а не рендерятся картинкой или canvas-элементом. Перед массовым запуском стоит прогнать задачу с включёнными и выключенными медиа и сравнить результат — для цен, наличия и текстовых полей разницы обычно нет.

Как проверить, что locale и часовой пояс браузера совпадают с гео прокси?

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

Отдельный порт под каждый профиль автоматизации, авторизация по белому IP для CI и выбор канала под задачу — резидентные и мобильные адреса по трафику или датацентровые помесячно — в разделе прокси.