Мобильный прокси с использованием Selenium и Playwright

Используйте настоящий браузер только в тех случаях, когда без него данные получить невозможно. Если разметка поступает в первоначальном ответе, HTTP-клиент работает на порядок эффективнее — этот подход описан в руководстве по Python. Ниже приведены рекомендации для тех случаев, когда необходимо запустить JavaScript и когда прокси должен выдержать взаимодействие с браузером.

Автор пьесы: «Прокси при запуске», «Прокси в зависимости от контекста»

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

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        "server": "http://proxy.pxm2.io:8000",
        "username": "user",
        "password": "pass",
    })
    ctx = browser.new_context(
        locale="en-GB",
        timezone_id="Europe/London",
        viewport={"width": 390, "height": 844},
        is_mobile=True,
    )
    page = ctx.new_page()
    page.goto("https://example.com/listings", wait_until="domcontentloaded")
    page.wait_for_selector(".result-card")
    html = page.content()
    browser.close()

Если вы запускаете несколько идентичностей в одном процессе, настраивайте прокси на уровне контекста, а не на уровне браузера — функция `new_context` принимает один и тот же словарь прокси, благодаря чему каждый контекст получает собственный IP-адрес выхода, собственную хранилище файлов cookie и собственное хранилище данных, что исключает перекрестное взаимодействие между ними. Вкладки внутри одного контекста используют общий сетевой стек, поэтому, если вам нужны отдельные идентичности, вам потребуются отдельные контексты, а не отдельные вкладки.

Обратите внимание на то, что параметры контекста в этом фрагменте кода выполняют еще одну функцию. Мобильный окно просмотра с установленным флагом `is_mobile`, языковая локаль и часовой пояс — это не просто «украшение», а часть проверки, осуществляемой браузером, в то время как сетевая часть этой проверки — IP-адрес мобильного устройства. Если один из этих параметров указан верно, а другой — нет, это хуже, чем если бы ни один из них не был указан правильно, поскольку само несоответствие является сигналом.

Селен и ловушка «Authenticated-Proxy»

Selenium — более старый вариант, и у него есть один существенный недостаток, о котором стоит знать, прежде чем приступить к работе: параметр Chrome --proxy-server не принимает имя пользователя и пароль. Их передача в URL-адресе незаметно игнорируется, после чего браузер застревает в системном диалоговом окне аутентификации, которое WebDriver не может закрыть. Симптомом этого является зависание скрипта при первом переходе на другую страницу без каких-либо ошибок.

from selenium import webdriver

opts = webdriver.ChromeOptions()
opts.add_argument("--proxy-server=http://proxy.pxm2.io:8000")

# NOTE: user:pass in the URL above is IGNORED by Chrome.
# Pick one of:
#   1. IP authorisation  - allow-list your server IP, use no credentials
#   2. selenium-wire-lw  - injects the Proxy-Authorization header
#   3. a small MV3 extension that answers onAuthRequired

driver = webdriver.Chrome(options=opts)
driver.get("https://example.com/listings")

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

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

Устранение ошибок 407 и сбоев при аутентификации через прокси

Ошибка «407 Proxy Authentication Required» означает, что прокси-сервер получил ваш запрос и отклонил его, поскольку не смог пройти аутентификацию. При автоматизации работы браузера это почти всегда означает, что учетные данные так и не были переданы, а не то, что они были указаны неверно. Выполните следующие действия в указанном порядке, и, как правило, причина будет обнаружена на первых двух шагах:

1. Сначала наладьте работу формы без аутентификации

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

2. Лучше бежать с головой, чем без головы

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

3. Проверьте IP-адрес выхода в том же браузере

   Перейдите на сайт службы IP-echo и посмотрите адрес. Если это ваш собственный адрес, значит настройка прокси полностью игнорируется — это типичный результат некорректной строки конечной точки, поскольку большинство стеков работают в режиме «open» (пропускают запрос), а не генерируют ошибку.

4. Только после этого добавьте аутентификацию

   Если маршрут к цели известен и исправен, то у сбоя аутентификации теперь есть ровно одна вероятная причина вместо четырёх.

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

«Безголовая» утечка: сопоставление браузера и IP-адреса

Чистый Mobile IP в сочетании со стандартным браузером без графического интерфейса по-прежнему явно указывает на бота. Прокси устраняет один из уровней оценки, состоящей из нескольких уровней, и вот те уровни, на которые он не влияет:

• Флаги автоматизации — Наличие `navigator.webdriver`, отсутствующих плагинов и кодеков, а также рендерера WebGL с именем SwiftShader — все это указывает на автоматизированный браузер. Запустите Headful в виртуальной среде или воспользуйтесь плагином-стелсом, а затем проверьте результат на странице тестирования отпечатков, а не полагайтесь на догадки.
• Географическая согласованность — IP-адрес, с которого осуществляется выход из Великобритании, в сочетании с браузером, указывающим локаль «America/New_York» и язык «en-US», считается несоответствием, которое проверяется в автоматическом режиме. Укажите в контексте значения локали и timezone_id, соответствующие стране, из которой вы выходите.
• Согласованность устройств — Если вы задали размеры окна просмотра для мобильного устройства и флаг `is_mobile`, то IP-адрес, с которого осуществляется выход, должен быть мобильным, а строка User-Agent должна соответствовать обоим параметрам. Даже частичная идентификация мобильного устройства вызывает больше подозрений, чем её полное отсутствие.
• Поведение — Измеряются идеально равные интервалы, отсутствие движений мыши и мгновенное заполнение форм. Никакой прокси не скрывает схему доступа; это может сделать только изменение самой схемы.

Получите выделенный браузерный прокси-сервер

Активные локации PXM2 — выберите страну, из которой, по вашему замыслу, должен поступать запрос, и получите выделенный IP-адрес с поддержкой 4G/5G, неограниченной пропускной способностью и возможностью смены адреса:

Часто задаваемые вопросы

Связанные руководства по мобильным прокси-серверам

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

Руководства по веб-парсингу

Основные руководства по мобильным прокси-серверам