Динамическое переключение прокси для отдельных контекстов браузера

Смена прокси после того, как сеанс уже накопил cookie и открытые страницы, может сохранить полезное состояние, но также позволяет спутать старый запрос с новым маршрутом. Используйте прокси на контекст, когда задача остается в одном регионе, а переключение во время работы оставляйте для разрешенной работы, где новый выход можно проверить до продолжения.

TL;DR

• Контекст - наименьшая полезная единица, которая держит вместе маршрут и сохраненное состояние сеанса.
• BotBrowser.setBrowserContextProxy меняет один существующий контекст; уже начатые запросы могут завершиться через прежний маршрут.
• После каждой смены записывайте и сравнивайте IP выхода, часовой пояс, локаль и язык каждого контекста.

Contents

• Определите, кто владеет маршрутом
• Назначайте прокси при создании контекста
• Переключайте прокси живого контекста
• Проверяйте каждый контекст отдельно
• Ограничения, которые нужно учесть
• Итог

Определите, кто владеет маршрутом

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

Контекст браузера - это изолированный сеанс внутри одного экземпляра браузера. У него свои cookie, свое локальное хранилище и свой кеш, а создать и выбросить его дешевле, чем запускать еще один браузер. Playwright описывает контексты как изолированные профили браузера, а Puppeteer выражает ту же идею через собственный API контекстов. Поскольку контекст уже является границей сохраненного состояния, он естественно подходит и как граница сетевого маршрута: работа, которая должна оставаться раздельной, не должна делить ни хранилище, ни адрес выхода.

Таблица сравнивает три варианта. Обычно выбор определяют расход памяти и изоляция состояния, а уровень лицензии решает, какие варианты вам вообще доступны.

Вариант	Когда подходит	Стоимость и изоляция	Требование из документации
Один прокси на контекст, задается при создании	Каждая учетная запись или регион сохраняет один маршрут на всю жизнь своего контекста	Контексты делят один экземпляр браузера, поэтому расходуют меньше памяти, чем отдельные экземпляры, и у каждого свои cookie и хранилище	Лицензия ENT Tier3 для прокси на контекст в BotBrowser
Переключение существующего контекста во время работы	Один рабочий процесс переходит между регионами, либо маршрут нужно заменить, не выбрасывая открытый контекст	Контекст сохраняет страницы и накопленное состояние, пока меняется маршрут	Лицензия ENT Tier3 и команда BotBrowser.setBrowserContextProxy
Отдельный экземпляр браузера на каждый прокси	Нужно самое широкое разделение, либо маршрутизация по контекстам не входит в ваш уровень	Каждый экземпляр несет собственный полный набор ресурсов браузера и собственный каталог пользовательских данных	Значение --proxy-server при запуске, описанное в руководстве по настройке прокси

Обычно выбор определяют три вопроса. Если маршрут должен меняться, пока тот же контекст остается открытым, используйте переключение во время работы. Если каждая учетная запись сохраняет один маршрут на всю жизнь, назначайте прокси при создании контекста: маршрут, который никогда не меняется, проще проверять и объяснять позже. Если ваша лицензия не включает маршрутизацию по контекстам или вам нужно самое широкое разделение, запускайте по экземпляру браузера на каждый прокси и примите дополнительный расход памяти.

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

Некоторые команды меняют маршруты через перехват запросов внутри фреймворка автоматизации или через локальный прокси-сервис, который перенаправляет трафик к разным внешним прокси. Такие схемы могут работать, но добавляют компоненты, которые нужно запускать и отслеживать. В документации BotBrowser также указано, что согласование часового пояса зависит от прокси, заданного через --proxy-server или от прокси на контекст, а не от параметров прокси, существующих только во фреймворке, поэтому держите маршрут на стороне браузера, когда региональные сигналы важны для вашей задачи. Локальный прокси-сервис также является сервисом на localhost, а в материале Защита от сканирования портов браузером на localhost разобрано, как браузер может опрашивать локальные порты.

Назначайте прокси при создании контекста

Документированный в BotBrowser способ дать контексту собственный маршрут - указать прокси при создании контекста. В Puppeteer это параметр proxyServer у createBrowserContext, с учетными данными, встроенными в URL прокси. Контекст, созданный без собственного прокси, наследует прокси-маршрут и географическую идентичность стартового профиля, поэтому любому контексту, который не должен использовать маршрут уровня браузера, нужен свой прокси.

const client = await browser.target().createCDPSession();

const ctx = await browser.createBrowserContext({
  proxyServer: 'socks5://user:[email protected]:1080',
});

await client.send('BotBrowser.setBrowserContextFlags', {
  browserContextId: ctx._contextId,
  botbrowserFlags: ['--bot-profile=path/to/profile.enc', '--proxy-ip=203.0.113.1'],
});

const page = await ctx.newPage();

После создания BotBrowser определяет IP выхода прокси этого контекста и по нему задает часовой пояс, локаль и язык контекста. Если IP выхода вам уже известен, передайте его через --proxy-ip, и поиск будет пропущен. Когда у контекста собственный маршрут и вы дополнительно объявляете IP выхода, передавайте оба значения при создании: в документации предупреждается, что применение --proxy-ip только после создания может позволить географическому определению начаться раньше, чем станет доступно объявление адреса. Отправляйте обновление флагов до создания первой страницы контекста, как в примере выше.

Параметры, оставленные в auto, следуют за прокси контекста, а явные значения определяются независимо для каждого контекста и каждого параметра. Это удобно, когда команда намеренно фиксирует одно значение, например язык интерфейса, которого требует план тестирования, а остальные пусть следуют за маршрутом. Относитесь к каждому зафиксированному значению как к решению, у которого есть ответственный. Старое переопределение после смены маршрута продолжает выглядеть допустимым, и о нем легко забыть.

Playwright документирует собственный параметр proxy для новых контекстов, и именно эта документация описывает, что делает параметр внутри Playwright. Документация BotBrowser по прокси на контекст написана вокруг параметра создания контекста и показанных выше флагов, поэтому проверяйте региональные значения на собственной тестовой странице, прежде чем полагаться на автоматическое согласование в конфигурации с Playwright. Страница Playwright из списка источников служит первоисточником для поведения самого фреймворка.

Учетные данные требуют такой же аккуратности, как и маршрут. Документированная команда и параметр создания принимают URL прокси со встроенными учетными данными, поэтому оставляйте их там, а не заменяйте отдельным вызовом page.authenticate(). Получайте их из хранилища секретов при запуске задачи, держите вне исходных файлов, тикетов и записей о запусках и обновляйте через их владельца. Статья о проверке подлинности прокси и гигиене учетных данных подробнее описывает этот процесс.

Закрытие контекста удаляет его cookie, локальное хранилище и кеш, а следующий контекст начинается с чистого листа. Это нужное поведение, когда каждая задача должна стартовать с нуля, и проблема, когда сеанс учетной записи должен пережить контекст. Если сеанс должен продолжаться, до закрытия решите, что вы экспортируете, где это хранится и кто может это читать. Руководство по прокси на контекст описывает, как держать вместе одну цель, один контекст и один маршрут.

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

Переключайте прокси живого контекста

Переключение во время работы нужно для процессов, в которых тому же контексту позже требуется другой маршрут. При наличии лицензии ENT Tier3 BotBrowser документирует CDP-команду BotBrowser.setBrowserContextProxy, которая меняет прокси существующего контекста браузера. Команда принимает browserContextId и URL proxyServer со встроенными учетными данными, а также, по желанию, proxyIp, proxyBypassList и proxyBypassRgx.

const client = await browser.target().createCDPSession();

await client.send('BotBrowser.setBrowserContextProxy', {
  browserContextId: ctx._contextId,
  proxyServer: 'socks5://user:[email protected]:1080',
  proxyIp: '198.51.100.1',
});

await page.goto(nextUrl);

Команду нужно отправлять в сеансе уровня браузера. В Puppeteer это browser.target().createCDPSession(), а в Playwright это browser.newBrowserCDPSession(). Сеанс уровня страницы не предоставляет домен BotBrowser, и ошибка «команда не найдена» - обычный признак неверного сеанса. Та же ошибка может появиться, если лицензия не включает эту функцию.

Когда вы вызываете команду, BotBrowser обновляет конфигурацию прокси этого контекста, заново определяет IP выхода, если вы не передали proxyIp, и перенастраивает часовой пояс, локаль и язык под новое местоположение. Команда завершается после применения обновленного географического состояния, а последующие запросы этого контекста идут через новый прокси. Поэтому дождитесь завершения команды (await), прежде чем начинать любую навигацию, зависящую от нового местоположения. Выполняйте смену прокси, обновление флагов и сброс прокси для одного контекста последовательно и ждите завершения каждой команды, прежде чем отправлять следующую.

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

Передача proxyIp убирает однократный поиск перед первой навигацией после переключения. Используйте ее, когда у вас уже есть адрес выхода от провайдера, и убедитесь, что это действительный адрес выхода именно этого прокси, поскольку географические параметры выводятся из переданного значения. Для прокси, у которого есть адрес только одного семейства, документация допускает ipv4_none или ipv6_none, чтобы объявить отсутствующее семейство. Без proxyIp ожидайте, что первая загрузка после переключения займет немного больше времени, это нормально и само по себе не является сбоем.

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

Параметр proxyBypassList принимает список хостов через точку с запятой, к которым подключаются напрямую, а proxyBypassRgx принимает шаблон RE2 для URL, которые должны вести себя так же. Эти запросы вообще не используют прокси. Держите список коротким, фиксируйте его как часть назначения маршрута и проверяйте один хост, который должен подключаться напрямую, и один, который не должен.

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

Проверяйте каждый контекст отдельно

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

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

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

После переключения дождитесь завершения команды, затем откройте новую страницу или перезагрузите существующую, прежде чем проверять снова. Считайте страницы, загруженные до переключения, устаревшими. Затем проверьте обратное направление: контексты, которые вы не переключали, должны по-прежнему показывать исходные адреса. Эта проверка подтверждает, что переключение одного контекста не изменило маршрут другого.

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

Используйте постоянный набор полей: contextId, routeLabel, observedIp, timezone, locale, language и checkedAt. Тогда записи до и после BotBrowser.setBrowserContextProxy можно сравнить, не сохраняя URL прокси и его учетные данные.

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

Ограничения, которые нужно учесть

Переключение прокси меняет сетевой путь одного контекста и ничего больше. Качество этого пути принадлежит провайдеру прокси: репутация адреса выхода, его скорость и стабильность, а также точность регистрации его местоположения. Переход на плохой прокси дает контексту плохой маршрут, поэтому проверьте провайдера собственными тестами, прежде чем строить на нем рабочий процесс.

Общий адрес выхода - один из нескольких сигналов связи. Разные адреса уменьшают один вид связи между учетными записями, но не управляют тем, как сайт связывает идентичности через данные учетной записи, платежные данные, поведение, значения, связанные с устройством, или людей, которые ими управляют. Ничто здесь не гарантирует, что сайт примет, проигнорирует или не станет сопоставлять ваши контексты. Используйте маршрутизацию по контекстам для разрешенной работы, например для собственных учетных записей, региональных проверок качества и исследований приватности, и соблюдайте условия каждого сервиса.

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

BotBrowser поддерживает прокси на контекст и, при наличии лицензии ENT Tier3, CDP-команду BotBrowser.setBrowserContextProxy, которая во время работы меняет прокси существующего контекста браузера и заново определяет IP выхода, чтобы обновить часовой пояс, локаль и язык этого контекста. Это помогает, когда одному процессу нужно переходить между регионами или когда маршрут нужно заменить, не выбрасывая открытый контекст. BotBrowser не может поставлять или проверять прокси, улучшать репутацию IP или скорость прокси, переносить с прежнего прокси запросы, которые уже в пути, а также не может гарантировать, как сайт сопоставляет или принимает идентичности за пределами сетевого пути.

Итог

Дайте каждой разрешенной задаче именованный контекст и назначение маршрута. При переключении дождитесь BotBrowser.setBrowserContextProxy, загрузите новую страницу, сравните observedIp и региональные значения с ожидаемым маршрутом и остановите задачу при расхождении. Не берите для такого сравнения страницы, открытые до смены: их запросы могли завершиться раньше.

Открытые источники

• Документация BotBrowser по динамическому переключению прокси
• Документация BotBrowser по прокси на контекст
• Документация BotBrowser по прокси и геолокации
• Сетевая документация Playwright: HTTP-прокси
• Документация Playwright по контекстам браузера