Останнє оновлення: 31 жовтня 2026 р.

Автентифікація проксі в Selenium: типові помилки та як їх виправити

Selenium може успішно запустити Chrome і при цьому не використовувати проксі. Ви можете побачити відповідь 407 Proxy Authentication Required, помилку з’єднання браузера або тайм-аут завантаження сторінки. Одна й та сама кінцева точка також може поводитися по-різному в Chrome, Firefox або у віддаленій сесії браузера.

Ці помилки виникають на різних етапах, тому зміна облікових даних проксі не завжди правильне рішення. Цей посібник допомагає визначити, чи походить збій від запуску WebDriver, з’єднання або автентифікації проксі, чи від цільового сайту.

Покрокове налаштування див. у статті Як використовувати проксі з Selenium у Python .

Визначте, на якому етапі запит не проходить

Запит Selenium через проксі проходить три етапи:

1. Запуск WebDriver: Selenium запускає або підключається до Chrome чи Firefox.
2. З’єднання з проксі та автентифікація: Браузер досягає кінцевої точки проксі й використовує налаштований метод автентифікації.
3. Доступ до призначення: Проксі пересилає запит, і цільовий сайт повертає відповідь.

Спочатку визначте, на якому етапі стався збій. Помилка запуску WebDriver — це не помилка автентифікації проксі. Відповідь 401 або 403 цільового сайту — це не те саме, що відповідь 407 проксі.

Ці сигнали можуть виглядати по-різному залежно від браузера та драйвера. Selenium може повідомити WebDriverException або тайм-аут, не розкриваючи вихідну HTTP-відповідь проксі. Не називайте помилку 407, доки ви реально не спостерігали відповідь 407.

Перевірте кінцеву точку та метод автентифікації

Перш ніж змінювати код, перевірте значення та середовище, у якому працює браузер.

• Хост і порт: Скопіюйте ім’я хоста шлюзу та порт із панелі провайдера. Перевірте друкарські помилки, застарілі кінцеві точки або порт від іншого продукту проксі.
• Протокол: Використовуйте протокол, який підтримує кінцева точка. Кінцева точка HTTP-проксі може передавати запити до HTTPS-сайтів через HTTP-тунель CONNECT; це не робить саму кінцеву точку HTTPS-проксі. Не сприймайте кінцеву точку SOCKS як HTTP.
• Режим автентифікації: Переконайтеся, чи очікує обліковий запис ім’я користувача та пароль, чи IP-білий список. Це різні методи автентифікації; налаштування одного не задовольняє інший.
• Мережевий шлях: Перевірте, чи не обробляє з’єднання також системний проксі, VPN, файрвол, правило контейнера або корпоративний шлюз.
• Вузол браузера: У Selenium Grid або Remote WebDriver з’єднання з проксі встановлює вузол браузера. Йому може знадобитися мережевий доступ до кінцевої точки, а для білого списку має бути авторизований його власний публічний egress IP.

Якщо значення виглядають правильними, але браузер усе одно не працює, перевіряйте кожен етап окремо замість повторної зміни непов’язаних налаштувань.

Виправте 407 Proxy Authentication Required

HTTP 407 — це запит автентифікації проксі. Проксі не переслав запит на сайт, бо йому потрібна прийнятна автентифікація проксі. Це відрізняється від 401, який зазвичай є відповіддю автентифікації цільового сайту.

1. Перевірте облікові дані

Якщо провайдер використовує автентифікацію за іменем користувача та паролем, переконайтеся, що повне згенероване ім’я користувача та пароль скопійовано правильно. Стежте за початковими або кінцевими пробілами, обрізаними значеннями, проблемами лапок в оболонці, простроченими обліковими даними та спецсимволами, зміненими скриптом або змінною середовища.

Не виводьте облікові дані в діагностичні логи. Якщо ви підозрюєте, що їх було розкрито, замініть їх через елементи керування обліковим записом провайдера.

2. Підтвердьте режим автентифікації облікового запису

Перевірте панель проксі або конфігурацію облікового запису. Якщо задано IP-білий список, переконайтеся, що публічний egress IP машини браузера або вузла Grid є в списку. Якщо задано ім’я користувача та пароль, перевірте, що інтеграція браузера справді може передати ці облікові дані проксі.

Не вважайте, що успішний тест з’єднання з ноутбука доводить авторизацію віддаленого вузла браузера. Клієнт Python і браузер можуть працювати на різних машинах із різними публічними IP-адресами.

3. Зрозумійте обмеження HTTP-автентифікації Selenium

Стандартний об’єкт Proxy у Selenium для Python налаштовує адреси проксі, такі як http_proxy і ssl_proxy. У документованій моделі є властивості імені користувача та пароля для SOCKS, але ці поля не створюють загального механізму імені користувача та пароля для HTTP-проксі. Так само вказівка username:password@ у URL проксі не є універсальним рішенням для всіх браузерів і драйверів.

Див. Selenium Python Proxy API .

Якщо вам потрібна HTTP-автентифікація за іменем користувача та паролем, підтвердьте метод, підтримуваний вашою точною комбінацією браузера, драйвера, версії Selenium і кінцевої точки провайдера. Розширення браузера або локальне проміжне ПЗ проксі можуть бути варіантом, але обидва додають компоненти, яким потрібні власні перевірки безпеки та сумісності. Не переносьте облікові дані в розширення браузера або репозиторій вихідного коду, не враховуючи, як вони зберігаються та розкриваються.

4. Повторно перевірте IP-білий список

Для кінцевої точки з білим списком:

1. Знайдіть публічний egress IP системи, на якій працює браузер.
2. Додайте цю адресу до білого списку провайдера.
3. Переконайтеся, що обліковий запис налаштовано на автентифікацію за whitelist.
4. Перезапустіть сесію браузера й знову виконайте невеликий тест.

Для облікових записів KindProxy керуйте авторизованими IP у панелі IP Whitelist . Якщо ви використовуєте Grid, додайте egress IP вузла браузера, а не машини, на якій запускається клієнт Python.

Використовуєте резидентний проксі з Selenium? KindProxy підтримує HTTP/HTTPS-з’єднання проксі та IP-білий список. Ви можете ознайомитися з тарифами резидентних проксі і вибрати кінцеву точку, що відповідає середовищу браузера. Перед тестуванням переконайтеся, що публічний egress IP машини браузера авторизовано.

Виправте помилки з’єднання з проксі та тайм-аути

ERR_PROXY_CONNECTION_FAILED або Connection Refused

Ці помилки зазвичай означають, що браузер не зміг установити з’єднання з налаштованою кінцевою точкою. Спочатку підтвердьте ім’я хоста, порт і протокол. Потім перевірте, чи розв’язується DNS і чи дозволено середовищу браузера робити вихідні з’єднання на цей порт. Якщо браузер перебуває в контейнері або на вузлі Grid, виконайте мережеву перевірку з цього середовища.

Якщо кінцева точка доступна з клієнта командного рядка, але не з Selenium, порівняйте машини та мережеві маршрути. Успішний тест із робочої станції не доводить, що віддалений контейнер браузера може досягти того самого хоста.

Selenium TimeoutException

Тайм-аут не означає автоматично, що автентифікація проксі не вдалася. Проксі може бути підключений, поки цільовий сайт повільний, сторінка може чекати аналітику чи інші сторонні ресурси, або тест може чекати елемент, який ніколи не з’являється.

Відокремте навігацію від перевірок вмісту. Задайте розумний тайм-аут завантаження сторінки, потім використайте конкретну умову очікування для елемента, потрібного тесту:

driver.set_page_load_timeout(60)

Збільшення тайм-ауту може допомогти за повільного, але робочого маршруту. Воно не виправить неправильний хост, заблокований порт, відхилені облікові дані чи невідповідність білого списку. Уникайте сліпих необмежених повторів; спочатку зафіксуйте етап збою та вихідний виняток.

Помилки HTTPS, TLS і тунелю

Коли браузер звертається до HTTPS-сайту через HTTP-проксі, він зазвичай просить проксі відкрити тунель методом HTTP CONNECT. Потім браузер узгоджує TLS із призначенням через цей тунель. Тому HTTP-проксі можна використовувати для доступу до HTTPS-сайтів; сама кінцева точка проксі не повинна бути HTTPS-проксі.

Якщо ви бачите ERR_TUNNEL_CONNECTION_FAILED, переконайтеся, що налаштовані кінцева точка та протокол правильні й що проксі може встановити тунель. Якщо браузер повідомляє про помилку сертифіката або TLS, вивчіть точне повідомлення браузера та ланцюжок сертифікатів призначення.

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

Чому Chrome і Firefox можуть поводитися по-різному

Selenium передає можливості браузера, але більшу частину поведінки проксі реалізує сам браузер. Це означає, що адреса проксі, яка працює в Chrome, може поводитися інакше у Firefox, особливо коли задіяні автентифікація, профілі, розширення або віддалені сесії.

Firefox надає переваги проксі, такі як network.proxy.type, network.proxy.http і network.proxy.http_port. Ці налаштування задають маршрут проксі; самі по собі вони не вирішують HTTP-автентифікацію за іменем користувача та паролем.

Не копіюйте обхідний шлях автентифікації Chrome у Firefox, припускаючи, що він спрацює. Розглядайте розширення та переваги профілю як компоненти, залежні від браузера, і тестуйте їх окремо. Документація Selenium щодо параметрів браузера описує, як параметри конкретного браузера передаються в WebDriver.

Перевірте маршрут проксі та цільовий сайт окремо

Використовуйте дві перевірки:

1. Відкрийте публічну сторінку перевірки IP у браузері під керуванням Selenium і запишіть отриманий IP. Порівняйте його з прямим підключенням із тієї ж машини браузера.
2. Окремо відкрийте цільовий сайт і перевірте відповідь або вміст сторінки, який очікує тест.

Якщо важливий вибір країни, використовуйте джерело GeoIP, якому довіряє ваша команда. Бази GeoIP можуть розходитися, а сайт також може використовувати cookies, налаштування облікового запису, локаль або збережений вибір країни. Мова сторінки або валюта самі по собі не доводять країну мережевого виходу.

Успішне завантаження сторінки перевірки IP показує, що браузер досяг цього призначення за поточним маршрутом. Воно не доводить, що інший сайт прийме запит або поверне очікуваний вміст.

Поетапний діагностичний скрипт Selenium

Супровідний скрипт у репозиторії GitHub призначений для простого діагностичного процесу. Автономний скрипт, що додається до цієї статті, використовує стандартні налаштування кінцевої точки проксі Selenium 4 і передбачає, що проксі авторизовано через IP-білий список. Він не реалізує HTTP-автентифікацію за іменем користувача та паролем.

Задайте PROXY_SERVER і TARGET_URL у середовищі. Ціллю має бути сайт, яким ви володієте або який уповноважені тестувати. Скрипт:

• запускає Chrome й окремо повідомляє про збої запуску WebDriver;
• відкриває кінцеву точку перевірки IP, щоб перевірити поточний маршрут браузера;
• відкриває цільовий URL як окремий етап;
• повідомляє етап збою та тип винятку, не стверджуючи, що кожен збій навігації — це 407;
• закриває браузер у блоці finally.

Див. додану папку selenium-proxy-auth-diagnostic для скрипта, файлу залежностей та інструкцій із налаштування.

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

Приклад: успішний тест проксі Selenium

Ми виконали діагностичний процес на Linux-сервері з Selenium 4 і Chrome, використовуючи кінцеву точку HTTP-проксі, авторизовану через IP-білий список. Браузер успішно відкрив кінцеву точку перевірки IP, повернув вихідний IP проксі й завантажив https://example.com/.

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

Повне покрокове керівництво з налаштування див. у посібнику з налаштування проксі Selenium .

FAQ

Чому Selenium повертає помилку 407?

Проксі вимагає автентифікацію або не прийняв передану автентифікацію. Перевірте режим автентифікації облікового запису, облікові дані та білий список. Помилки браузера Selenium без спостережуваного 407 недостатньо, щоб підтвердити, що причиною збою стала автентифікація.

Чи може Selenium передавати ім’я користувача та пароль HTTP-проксі?

Стандартна модель проксі Selenium для Python налаштовує адреси кінцевих точок, але не надає загальних полів імені користувача та пароля для HTTP. Методи, залежні від браузера, потрібно перевіряти з точним браузером і сервісом проксі.

Чому проксі працює в Chrome, але не працює у Firefox?

Браузери обробляють налаштування проксі та автентифікацію через різні реалізації. Підтвердьте параметри проксі, профіль, версію браузера та метод автентифікації окремо в кожному браузері.

Чому Selenium завершується за тайм-аутом, коли проксі доступний?

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

Як перевірити, чи справді Selenium використовує мій проксі?

Відкрийте кінцеву точку перевірки IP у браузері під керуванням Selenium і порівняйте отриманий IP із прямим підключенням із тієї ж машини браузера. Для віддалених сесій виконуйте пряме порівняння з мережевого середовища вузла браузера.

Чи запобігає резидентний проксі CAPTCHA або помилкам доступу?

Ні. Проксі змінює мережевий маршрут або місце виходу. Він не може гарантувати, як відповість сайт.

Висновок

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

Якщо ваш робочий процес Selenium використовує IP-білий список, ознайомтеся з панеллю KindProxy IP Whitelist . Якщо ви налаштовуєте новий процес автоматизації браузера, вивчіть тарифи резидентних проксі KindProxy , щоб порівняти доступні варіанти трафіку й вибрати відповідну кінцеву точку проксі. Інструкції з налаштування почніть із Як використовувати проксі з Selenium у Python .

Додаткове читання

• Параметри браузера Selenium
• Selenium Python Proxy API
• Як використовувати проксі з Selenium у Python