Настройка прокси в Selenium: проверяем capabilities

Основная идея

Selenium передаёт настройки прокси браузерному драйверу через capabilities, но поддерживаемые поля и авторизация различаются между Chrome, Firefox и Grid. Неверная capability может быть молча проигнорирована.

В автоматизации тема «Настройка прокси в Selenium: проверяем capabilities» должна стать воспроизводимым сценарием, а не набором бесконечных повторов. Заранее задайте входные данные, ожидаемое состояние, общий таймаут, лимит параллельности и условие остановки. Прокси является одной зависимостью сценария; ошибку страницы, браузера или тестовых данных нужно отличать от ошибки канала.

Что подтверждает первичный источник

Начинаем с минимального теста своего стенда и подтверждаем поддержку конкретного браузера и драйвера.

Первичный источник «Selenium Browser Options» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

Начните с минимального Selenium-теста своего /whoami: создайте Options нужного браузера, задайте Proxy через поддерживаемые capabilities и откройте одну страницу. Проверьте версии браузера, driver и Grid. Затем добавьте HTTPS и авторизацию тем способом, который документирован для этой связки; расширение Chrome, системная настройка и стандартная capability — разные механизмы.

Проверка шаг за шагом

Запустите минимальную сессию без расширений, откройте собственный endpoint IP и сравните фактический адрес с ожидаемым. Затем добавляйте bypass, SOCKS-версию и реквизиты по одному, сохраняя capabilities без секретов.

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

Повторы разрешайте лишь для доказанно безопасных чтений. Уважайте Retry-After и увеличивайте паузу после 429 или сетевой серии. Мутации — покупка, смена реквизитов, продление — требуют идемпотентного ключа и проверки результата перед новой попыткой. Таймаут не доказывает отказ: команда могла завершиться у внешней системы.

• Сверить browser и driver
• Открыть /whoami
• Проверить capability на Grid
• Добавить авторизацию документированным способом

Какие данные сохранить

Отчёт хранит browserName/version, driver, platform, Grid node, тип proxy capability, masked endpoint, выходной IP и точный exception class. Пароль и сериализованные capabilities с секретом удаляются.

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

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

Как читать результат

Успешное создание WebDriver не доказывает применение прокси. Поведение браузерных расширений и системного диалога авторизации требует отдельной проверки на конкретной версии драйвера.

Поддержка SOCKS-аутентификации и per-session proxy различается между браузерами и драйверами. Успех локального Chrome не доказывает поведение удалённого Firefox Grid.

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

Разбор рабочего решения

Для «Настройка прокси в Selenium: проверяем capabilities» опишите конечный автомат состояний до написания цикла. Минимальный набор включает ожидающую, выполняющуюся, успешную, окончательно ошибочную и неопределённую операции. Таймаут внешнего запроса переводит изменение в неопределённое состояние, потому что поставщик мог завершить его после разрыва связи. В таком случае сначала выполняется чтение и сверка, а повтор разрешается только после доказательства, что изменения не было.

Нагрузка ограничивается на нескольких уровнях: общий размер очереди, число задач на один домен, число задач на один аккаунт и частота повторов. Добавьте случайный небольшой сдвиг расписания, чтобы процессы не стартовали одновременно. Уважайте Retry-After и увеличивайте паузу после серии сетевых ошибок. Эти правила нужны даже при большом пуле IP: адреса не отменяют лимиты конечного сервиса и стоимость собственных ресурсов.

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

Типичные ошибки

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

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

Критерии внедрения и сопровождение

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

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

Рабочий регламент

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

• Есть условие успеха и остановки
• Проверен выходной IP
• Ожидание связано с событием
• Повторы ограничены
• Мутации идемпотентны
• Секреты удалены из артефактов