Аутентификация прокси в Selenium: 4 настройки, которые действительно работают

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

Аутентификация прокси в Selenium — это ловушка, замаскированная под однострочник. Флаг Chrome --proxy-server принимает адрес прокси с удовольствием — и тихо игнорирует любые имя пользователя и пароль, которые вы в него встраиваете. Затем Chrome вызывает нативный диалог аутентификации, который WebDriver не видит, ваш скрипт зависает, а лучший ответ на Stack Overflow (113+ голосов) решает это с помощью расширения Manifest V2, которое современный Chrome больше не загружает. Это руководство охватывает четыре настройки, которые аутентифицируют прокси в Selenium сегодня — IP-белый список, расширение Manifest V3, selenium-wire и знание, когда передать всю проблему браузера API.

Почему базовая аутентификация прокси в Selenium не работает

Три факта объясняют каждую неудачную попытку. Во-первых, Chromium удаляет учетные данные из --proxy-server=http://user:pass@host:port — формат флага просто не поддерживает учетные данные. Во-вторых, вызов прокси 407 Proxy Authentication Required появляется как нативный диалог, вне DOM, куда send_keys не может добраться. В-третьих, старый маршрут DesiredCapabilities (socksUsername / socksPassword) применялся только к SOCKS-прокси и никогда не работал для HTTP — конфигурация, которая 'выглядит правильно' и ничего не делает. Поэтому реальные варианты полностью избегают диалога.

Метод 1: IP-белый список — ноль кода, ноль диалогов

Если ваш скраппер работает с машины со стабильным публичным IP, пропустите учетные данные: зарегистрируйте этот IP в панели управления вашего провайдера прокси, и шлюз аутентифицирует вас по адресу источника. Каждый план QuantumProxies поддерживает IP-белый список наряду с user:pass. Сторона Selenium становится простым флагом — который всегда работал хорошо без аутентификации:

from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_argument("--proxy-server=http://gate.quantumproxies.io:PORT")
options.add_argument("--headless=new")

driver = webdriver.Chrome(options=options)
driver.get("https://httpbin.org/ip")
print(driver.find_element("tag name", "body").text)  # proxy exit IP
driver.quit()

Всегда проверяйте выход перед тем, как доверять запуску: загрузите конечную точку эха IP и подтвердите, что адрес принадлежит прокси, потому что неправильно настроенный флаг тихо проваливается, и Chrome просто подключается напрямую. Ограничение белого списка топологическое: он аутентифицирует машину, а не скрипт. Эфемерные облачные раннеры, контейнеры за NAT и CI-машины с меняющимися IP нуждаются в одном из методов ниже.

Метод 2: расширение Chrome Manifest V3

Классическое исправление генерирует небольшое расширение Chrome, которое устанавливает прокси и отвечает на вызов аутентификации через chrome.webRequest.onAuthRequired. Известный фрагмент 2019 года использует Manifest V2, который Chrome теперь снял с поддержки — современная версия требует manifest_version: 3, рабочего сервиса и разрешения webRequestAuthProvider. Это строит и загружает одно во время выполнения:

import json, os, tempfile
from selenium import webdriver

HOST, PORT = "gate.quantumproxies.io", "PORT"
USER, PASS = "USER", "PASS"

manifest = {
    "name": "Proxy Auth", "version": "1.0", "manifest_version": 3,
    "permissions": ["proxy", "webRequest", "webRequestAuthProvider"],
    "host_permissions": ["<all_urls>"],
    "background": {"service_worker": "worker.js"},
}

worker = """
chrome.proxy.settings.set({
  value: { mode: "fixed_servers", rules: {
    singleProxy: { scheme: "http", host: "%s", port: parseInt("%s") },
    bypassList: ["localhost"] } },
  scope: "regular"
}, function() {});
chrome.webRequest.onAuthRequired.addListener(
  function(details) {
    return { authCredentials: { username: "%s", password: "%s" } };
  },
  { urls: ["<all_urls>"] },
  ["blocking"]
);
""" % (HOST, PORT, USER, PASS)

ext_dir = tempfile.mkdtemp()
with open(os.path.join(ext_dir, "manifest.json"), "w") as f:
    json.dump(manifest, f)
with open(os.path.join(ext_dir, "worker.js"), "w") as f:
    f.write(worker)

options = webdriver.ChromeOptions()
options.add_argument("--load-extension=" + ext_dir)
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)
driver.get("https://httpbin.org/ip")

Две ловушки. Расширения загружаются только в новом режиме без головы — простой --headless выдает загадочную ошибку 'failed to wait for extension background page', так что --headless=new обязателен. И загрузка распакованной директории через --load-extension более надежна в разных версиях Chrome, чем упаковка в zip. Если вы предпочитаете не поддерживать это, пакет selenium-authenticated-proxy на PyPI генерирует расширение для вас из одного URL прокси.

Метод 3: selenium-wire и его компромиссы

selenium-wire оборачивает WebDriver локальным прокси типа 'человек посередине', что делает аутентифицированные восходящие прокси — включая SOCKS5 — простым словарем опций:

# pip install selenium-wire
from seleniumwire import webdriver

options = {
    "proxy": {
        "http": "http://USER:PASS@gate.quantumproxies.io:PORT",
        "https": "http://USER:PASS@gate.quantumproxies.io:PORT",
        "no_proxy": "localhost,127.0.0.1",
    }
}

driver = webdriver.Chrome(seleniumwire_options=options)
driver.get("https://httpbin.org/ip")

Знайте, что вы покупаете. Проект был архивирован его поддерживающим в начале 2024 года и не получает обновлений, и поскольку он расшифровывает трафик локально, цель видит рукопожатие TLS selenium-wire, а не Chrome — несоответствие, которое системы JA3/JA4 отпечатков отмечают, даже если ваш IP безупречен. Он остается действительно полезным для инспекции запросов во время разработки и для Firefox, где трюк с расширением не существует. Для производственного скрапинга на защищенных сайтах предпочтительны методы 1-2 или переход на уровень выше.

Firefox и разрыв в аутентификации

Firefox принимает неаутентифицированный прокси чисто через настройки профиля (network.proxy.type = 1 плюс настройки хоста и порта), но не имеет эквивалента трюка с расширением Chrome для ответа на диалог учетных данных из WebDriver. На практике пользователи Firefox выбирают IP-белый список или selenium-wire. Если вашей единственной причиной для использования Firefox была его работа с прокси, эта причина больше не актуальна.

Когда прекратить исправлять Selenium и переключиться на API

Аутентификация — это первый налог, а не последний. Экземпляр Chrome стоит сотни МБ ОЗУ, поэтому несколько десятков одновременных сессий насыщают сервер; версии ChromeDriver догоняют выпуски Chrome; и антиботовые вендоры обнаруживают ванильный Selenium независимо от IP за ним — navigator.webdriver и артефакты CDP выдают его. Два обновления меняют экономику. Во-первых, запускайте ваши браузеры через резидентные прокси, чтобы репутация IP перестала быть причиной, по которой вас блокируют — более 90 миллионов домашних IP с ротацией по запросу или липкими сессиями для потоков с авторизацией. Во-вторых, когда поддержка браузеров перестает быть стоящей, Scraper API сворачивает весь стек в один HTTP-запрос: он рендерит JavaScript по требованию, управляет IP и повторами внутренне и возвращает HTML, markdown или структурированный JSON. Та же компромиссная ситуация применяется к родственникам Selenium — ознакомьтесь с нашими руководствами по интеграции прокси в Playwright и настройке прокси в Puppeteer, прежде чем предполагать, что переключение фреймворка решит проблему обнаружения.

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

Как установить прокси с аутентификацией в Selenium ChromeDriver?

Либо добавьте IP вашей машины в белый список у провайдера прокси и передайте простой флаг --proxy-server, либо загрузите небольшое расширение Manifest V3, которое устанавливает прокси и предоставляет учетные данные через chrome.webRequest.onAuthRequired. Встраивание user:pass@ в флаг не работает — Chromium игнорирует это.

Почему Chrome показывает всплывающее окно входа в прокси с Selenium?

Прокси ответил с 407, и Chrome просит человека ввести учетные данные. Диалог является нативным интерфейсом, невидимым для WebDriver, поэтому ни селектор, ни вызов send_keys не могут его заполнить. Решение — аутентифицироваться до того, как диалог появится: белый список IP, расширение аутентификации или MITM-слой, такой как selenium-wire.

Работает ли selenium-wire в 2026 году?

Он все еще устанавливается и функционирует для многих задач, но проект был архивирован в начале 2024 года и не получает поддержки. Его дизайн MITM также заменяет отпечаток TLS Chrome на Python, который современные антиботовые системы обнаруживают. Рассматривайте его как инструмент отладки, а не основу для производственного скраппера.

Как использовать аутентифицированный прокси с Firefox в Selenium?

Настройки профиля Firefox настраивают адрес прокси, но не могут ответить на запрос учетных данных, и нет обходного пути с расширением, как в Chrome. Используйте белый список IP, чтобы не требовались учетные данные, или направьте Firefox через selenium-wire, который обрабатывает аутентификацию на стороне восходящего потока локально.

Работает ли это так же в Java и C#?

Да — механика находится в Chrome, а не в языковом биндинге. Белый список IP плюс --proxy-server идентичен везде, и подход с расширением Manifest V3 работает из Java или C#, создавая те же два файла и добавляя --load-extension в ChromeOptions. Только selenium-wire специфичен для Python; другие языки заменяют его локальным MITM-прокси, таким как BrowserMob.

Краткая версия: никогда не боритесь с диалогом аутентификации. Используйте белый список, когда ваш IP стабилен, создайте расширение MV3, когда он нестабилен, оставьте selenium-wire для инспекционной работы — и когда поддержка браузеров перерастает данные, которые она производит, передайте задачу API и освободите свои вечера.

Запускайте Selenium на резидентных IP