До всіх статей

Мобільні проксі для Selenium: індивідуальні IP для гео‑QA

2026-02-09
Мобільні проксі для Selenium: індивідуальні IP для гео‑QA

Пояснюємо, як підключати мобільні проксі в Selenium, коли потрібен sticky IP, і як QA‑команда тестує реєстрацію та чекаут у кількох країнах.

Що таке Selenium і навіщо він у тестуванні

Selenium — це набір інструментів для автоматизації браузера: ваш тестовий код керує Chrome/Firefox/Edge так, ніби це робить живий користувач. Найчастіше Selenium застосовують у web‑QA для перевірки критичних сценаріїв (логін, реєстрація, кошик, оплата), у регресі (щоб не «ламалися» старі функції після релізу) та в моніторингу (періодично відкривати сторінки й фіксувати помилки/відхилення).

Важлива особливість: Selenium працює на рівні браузера, а отже тест бачить реальний HTML, виконання JavaScript, редіректи, cookie, LocalStorage, мережеві запити й поведінку антибот‑механізмів. Це робить його зручним там, де «голий» HTTP‑клієнт (curl/requests) не повторює поведінку браузера.

Де Selenium використовується найчастіше

  • Функціональне web‑QA: перевірка флоу «відкрив → знайшов → додав → оплатив».
  • Регрес‑набори: швидка перевірка основних сценаріїв після змін у коді.
  • Смоук‑тести: короткий набір перевірок перед деплоєм.
  • Моніторинг: регулярні перевірки доступності сторінок, статусів, помилок на фронті.
  • Перевірка локалізації: мова, валюта, доставка, ціни, наявність методів оплати.
  • Валідація антибот‑логіки: капчі, 2FA, risk‑rules, поведінкові пороги.

Режими запуску: локально, headless, Grid/Remote

Сучасний Selenium (4+) дозволяє запускати тести по‑різному, і від цього залежить, де й як зручно задавати проксі:

  • Локально: драйвер і браузер працюють на вашому ПК/сервері. Плюс — простота. Мінус — складніше масштабувати паралельно.
  • Headless: браузер без видимого вікна (часто на Linux‑сервері). Плюс — швидко й дешево. Мінус — деякі сайти поводяться інакше, а антибот може бути чутливішим.
  • Selenium Grid / RemoteWebDriver: тести керують браузерами на віддалених вузлах (Docker/VM). Плюс — паралельність і контроль середовищ. Мінус — важливо правильно передавати capabilities (у т.ч. proxy) і фіксувати мережеві умови.

У всіх випадках проксі найнадійніше задавати на рівні сесії WebDriver — через capabilities / options, описані у специфікації WebDriver та в документації Selenium.

Де вказується proxy у Selenium

Є три практичні підходи, і їх часто комбінують:

  • Proxy capability (стандарт W3C): проксі описується як JSON‑об’єкт «proxy» у capabilities. Це найбільш переносимий шлях між браузерами/драйверами.
  • Клас Proxy у Selenium: у Java‑API (та аналогах в інших мовах) є об’єкт Proxy, який заповнює http/ssl/socks/noProxy тощо й передається в драйвер/опції.
  • Нативні параметри браузера: наприклад, у Chromium можна задавати проксі командним ключем --proxy-server або вимкнути його через --no-proxy-server. Це корисно, якщо потрібна специфічна поведінка Chromium.

Тонкі моменти: авторизація, HTTPS і стабільність

У QA‑сценаріях найчастіше виникають три «болі»:

  • Proxy з логіном/паролем. Не всі браузери однаково приймають credentials у рядку проксі. Часто використовують розширення/плагіни, або проміжний локальний проксі‑хендлер, або проксі без авторизації у тестовому контурі.
  • HTTPS‑трафік. Для Selenium це зазвичай прозоро: браузер сам робить TLS, але якщо ви хочете інспектувати HTTPS (наприклад, через MITM), тоді потрібні сертифікати й правильні налаштування довіри.
  • Стабільність каналу. Проксі додає затримку, а мобільні мережі можуть «плавати». Для тестів важливо збільшити таймаути, логувати мережеві помилки та відрізняти баг сайту від нестабільності мережі.

Чим відрізняються мобільні проксі і коли вони потрібні

Мобільні проксі — це вихід в інтернет через IP‑адреси мобільних операторів (4G/5G). На практиці це означає іншу репутацію IP і типові для мобільного інтернету умови (NAT/CGNAT, зміна маршруту, інша геоприв’язка). Для QA це корисно, коли ви хочете відтворити сценарій «як у мобільного користувача» не лише по User‑Agent, а й по мережевих ознаках.

Окремий клас — індивідуальні mobile proxy («один модем/канал на одну команду або на один тестовий потік»). Це зменшує взаємовплив тестів і сторонніх користувачів: менше шансів, що ваш IP «забрудниться» чужими діями, і простіше пояснювати різницю результатів між країнами.

Гео‑QA: локалізація, валюта, контент, доставка

Багато сайтів віддають різний контент залежно від країни та IP:

  • ціни та валюта;
  • набір товарів/послуг і наявність складу;
  • доступність методів оплати;
  • тексти локалізації, правові дисклеймери, банери;
  • різні CDN‑вузли й різна швидкість завантаження.

Звичайний VPN інколи достатній, але мобільний IP може показати іншу картину: наприклад, інші капчі, інші risk‑правила або інші варіанти редіректу на локальний домен.

Sticky IP для тестів: навіщо і як мислити

Sticky IP означає, що ваша сесія зберігає одну й ту саму вихідну IP‑адресу певний час (5–30 хвилин, година, день — залежно від провайдера проксі). Для Selenium це критично у двох випадках:

  • Багатокрокові флоу (реєстрація → підтвердження → кошик → оплата): якщо IP зміниться посеред сценарію, сайт може попросити додаткову перевірку або зламати сесію.
  • Порівняння «країна проти країни»: коли ви фіксуєте відхилення контенту/цін, вам потрібно мінімізувати випадкові фактори, і стабільна IP — один із них.

З іншого боку, занадто довга «липкість» може заважати під час масового прогону: якщо сайт «вчиться» на вашій поведінці, інколи краще мати окремий sticky‑період на кожен тест‑кейс або на кожен набір.

Як організувати індивідуальні мобільні проксі для команди

Практична схема для QA‑команди:

  • Окремий проксі‑пул на країну: наприклад, MD/RO/UA або DE/FR/PL — залежно від бізнесу.
  • Окремий «канал» на паралельний потік: якщо у вас 5 паралельних тестів, краще 5 незалежних sticky‑сесій (або 5 модемів), щоб тести не впливали один на одного.
  • Єдиний формат конфігурації: змінні середовища (PROXY_HOST/PORT/USER/PASS, COUNTRY), щоб один і той самий код запускати на різних гео без правок у репозиторії.
  • Логи «мережа + браузер»: фіксуйте країну, IP (зовнішній чек), час, user‑agent, версію браузера/драйвера і посилання на артефакти (скрін, HAR/лог консолі).

Кейс: реєстрація та чекаут у 3 країнах на мобільних IP

Уявімо e‑commerce продукт, який працює в трьох країнах. QA‑команда хоче перевіряти два сценарії: реєстрація та чекаут. Вимога бізнесу: «контент, ціни, доставка і оплата повинні відповідати країні користувача».

Налаштування:

  • три індивідуальні мобільні проксі (по одному на країну) зі sticky‑часом 30 хвилин;
  • три незалежні прогонові джоби в CI (по одній на країну) або один джоб із параметром COUNTRY;
  • однакова версія браузера й драйвера, однаковий набір тестових даних (користувачі, картки‑заглушки, адреси).

Що фіксують у кожному прогоні:

  • мова інтерфейсу та валюта;
  • ціни на 3 контрольні товари;
  • список методів доставки та оплати;
  • чи з’являється капча/додаткова перевірка при реєстрації;
  • чи однакові редіректи (на локальний домен/піддомен) і чи немає «залипання» на іншій країні через cookie.

Типові знахідки в такому кейсі:

  • різна ціна через інший ПДВ або інші промо‑правила;
  • відсутність певного методу оплати в країні B;
  • інший каталог доставки (наприклад, кур’єр недоступний);
  • капча з’являється лише на мобільному IP країни C — і це не відтворюється на датацентровому проксі або VPN.

Практичні поради, щоб результати були відтворювані

  • Завжди починайте з «чистого» профілю (окрема директорія профілю на тест) або очищуйте cookie/local storage перед сценарієм.
  • Контролюйте «липкість»: одна sticky‑сесія на один тест‑потік. Якщо ваш провайдер робить ротацію, синхронізуйте її з початком тесту, а не посередині.
  • Відділяйте мережеву проблему від багу: логування статус‑кодів, скріншоти, повтор з тією ж IP, а потім повтор з іншим каналом.
  • Таймаути: мобільні проксі часто повільніші, тому збільште timeouts очікування елементів і завантаження сторінок.
  • Паралельність: не перевантажуйте один мобільний канал десятками тестів одночасно — це спотворює результати.
  • Документуйте гео: у звіті має бути країна, час, IP та спосіб налаштування проксі (capabilities/flags).

Мінімальна «ментальна модель»: що саме ви перевіряєте

У гео‑QA з мобільними проксі важливо розуміти, що ви перевіряєте одразу кілька шарів:

  • Geo‑routing: як сайт визначає країну (IP, домен, cookie, профіль, Accept‑Language).
  • Контент і бізнес‑правила: ціни, податки, промо, доставка/оплата.
  • Risk/anti‑bot: капчі, ліміти, додаткові перевірки саме для мобільних мереж.
  • Продуктивність: різні CDN‑вузли й час завантаження.

Джерела та специфікації

  • W3C WebDriver: опис proxy capability.
  • Selenium API: клас org.openqa.selenium.Proxy.
  • Selenium Docs: browser options / capabilities у Selenium 4.
  • Chromium: параметри командного рядка для проксі (--proxy-server).
  • ChromeDriver: capabilities та ChromeOptions.
  • MDN: довідка про WebDriver capabilities.

Які бувають режими проксі у WebDriver

У специфікації WebDriver проксі описується як capability з типом і параметрами. На практиці в Selenium ви зустрінете кілька сценаріїв:

  • manual: ви явно задаєте httpProxy, sslProxy, socksProxy і, за потреби, список винятків noProxy. Це найпростіший і найчастіший варіант для QA.
  • pac: браузер отримує URL до PAC‑файлу (proxy auto‑config) і сам вирішує, коли й куди ходити напряму або через проксі. Зручно в корпоративних мережах, але складніше відтворювати у CI.
  • autodetect: браузер пробує авто‑визначення проксі. Для тестів корисно рідко, бо робить середовище менш детермінованим.
  • direct: явна заборона проксі (корисно, щоб переконатися, що тест не «підхопив» системні налаштування).

Суть для QA проста: якщо ви хочете контроль і повторюваність — використовуйте manual і передавайте проксі на старті сесії WebDriver.

Де «живуть» проксі‑налаштування у коді

Незалежно від мови (Java/Python/Node.js/C#) логіка однакова:

  • створюєте опції браузера (ChromeOptions/FirefoxOptions тощо);
  • додаєте capability «proxy» або об’єкт Proxy з параметрами;
  • ініціалізуєте WebDriver (локальний або Remote) з цими опціями.

Ключове правило: проксі має бути заданий до старту браузера. Якщо спробувати змінювати проксі «на льоту» в середині тесту, більшість драйверів/браузерів або не підхопить зміну, або зламає з’єднання.

Проксі + RemoteWebDriver: що врахувати в Grid і Docker

Коли ви працюєте через Selenium Grid, з’являються додаткові нюанси:

  • Проксі має бути досяжним з вузла Grid. Якщо ваш проксі доступний лише з локальної машини, а браузер крутиться в контейнері — з’єднання не буде.
  • Не плутайте «проксі для теста» і «проксі для Grid». Ваш тестовий клієнт спілкується з Grid по HTTP/WS, а сам браузер виходить в інтернет через проксі. Це два різні мережеві маршрути.
  • Секрети (логін/пароль до проксі) краще передавати через секрет‑сховище CI (GitHub Actions secrets, GitLab variables тощо), а не хардкодити в репозиторії.
  • Артефакти: зберігайте скріншоти/відео та логи сесій окремо для кожної країни, інакше важко розбирати розбіжності.

Як «імітувати мобільного користувача» правильно

Мобільний користувач — це не лише IP. Часто потрібно налаштувати одразу кілька речей:

  • Мережевий контур: мобільний IP через proxy (це те, що ви тестуєте в цій статті).
  • Mobile emulation / viewport: розмір екрана, DPR, touch‑події (в Chrome це робиться через опції/DevTools, залежно від стеку тестів).
  • User‑Agent та client hints: деякі сайти відрізняють мобільний/десктопний фронт не тільки по viewport.
  • Мова й регіон: Accept‑Language, таймзона, формат чисел/дат — інакше ви «змішаєте» країну IP та мову браузера.

Якщо ви зміните лише User‑Agent без мобільного IP, частина антибот‑правил не відтвориться. Якщо зміните лише IP без інших атрибутів — інколи отримаєте «країну», але не отримаєте мобільний фронт. Найкраща практика — чітко визначити, які саме шари ви хочете симулювати в конкретному наборі тестів.

Критерії вибору індивідуального mobile proxy для QA

  • Географія: країни/міста, які вам потрібні для бізнес‑логіки (валюта, доставка, податки).
  • Керування сесіями: чи можна задавати sticky‑час, чи є ручна ротація, чи є «прив’язка» до одного каналу/модема.
  • Продуктивність: затримка, стабільність, обмеження по трафіку/паралельності.
  • Прозорість: чи можете ви бачити поточну вихідну IP, ASN/оператора, історію ротацій, логи помилок.
  • Ізоляція: «один канал — один користувач/команда». Це знижує випадкові капчі через чужий трафік.

Для тестів зазвичай важливіші стабільність і керованість, ніж максимальна швидкість. Якщо канал інколи «провисає», але ви вмієте це відловлювати й повторювати сценарій — QA‑процес буде передбачуваним.

Чек‑лист дебагу, якщо результати між країнами «пливуть»

  • Перевірте IP і країну: на старті тесту відкрийте легку сторінку‑перевірку гео (або ваш внутрішній ендпоінт) і залогуйте результат у звіт.
  • Заблокуйте кеш: вимкніть кеш у браузері для тестів або використовуйте чистий профіль, інакше контент може братися з кешу/Service Worker.
  • Очистьте cookie між країнами: cookie‑прапори локалізації можуть «перетягнути» країну навіть при зміні IP.
  • Порівняйте заголовки: Accept‑Language, timezone, гео‑параметри можуть відрізнятися між раннерами.
  • Зробіть повтор з тією ж IP: якщо проблема зникає/з’являється хаотично — це або нестабільна мережа, або флапає бекенд/фічефлаг.
  • Перевірте ліміти: чи не перевищили ви поріг запитів/реєстрацій з одного каналу (антибот може реагувати).

Висновок

Індивідуальні мобільні проксі для Selenium — це інструмент для тих випадків, коли звичайного VPN або датацентрового проксі недостатньо, бо потрібно тестувати реальну «мобільну» мережеву картину: гео‑видачу, локалізацію, risk‑правила та капчі. Найкращі результати дає керований підхід: проксі задається на старті сесії WebDriver, sticky‑час синхронізований із тестами, а звіти містять IP/країну та артефакти для порівняння.