Урок про мультиакаунт: поєднання проксі-IP та антидетект-браузера

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

Проксі-IP та антидетект-браузер вирішують два різні завдання: проксі визначає, «звідки виходить трафік», а антидетект-браузер визначає, «який робочий простір браузера отримує кожен акаунт». Їх поєднання потрібне не для того, щоб замаскувати одну людину під безліч користувачів, а щоб створити кожному легітимному акаунту зрозуміле, стабільне й перевірюване середовище.

Нижче ми крок за кроком пояснимо від принципів до налаштування та наведемо чек-лист перед запуском і порядок усунення типових неполадок.

1. Спочатку розберемо розподіл ролей проксі-IP та антидетект-браузера

Проксі-IP: вирішує, звідки виходить трафік

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

Проксі впливає переважно на чотири речі:

• географічне положення, оператор і мережева репутація вихідного IP;
• затримка, стабільність і здатність до паралельних з'єднань;
• підтримувані протоколи, як-от HTTP, HTTPS або SOCKS;
• чи потрібна автентифікація за логіном/паролем або за білим списком IP.

Важливо пам'ятати: сам по собі проксі не ізолює Cookie, локальне сховище, стан входу, розширення, версії браузера та інші параметри пристрою. Коли кілька акаунтів використовують звичайний браузер, сесії можуть продовжувати змішуватися, навіть якщо змінити проксі.

Антидетект-браузер: зберігає окремий робочий простір для кожного акаунта

Сайти можуть зчитувати багато даних, які розкривають браузер і пристрій: user agent, мову, часовий пояс, екран, графічні можливості, шрифти. Пояснення Privacy Sandbox від Google також відносить обмеження пасивно розкритих і придатних для міжсайтового відстеження даних до напрямів захисту приватності в браузері.

Головна цінність антидетект-браузера — зібрати Cookie, кеш, локальне сховище, конфігурацію проксі, стартову сторінку та права спільної роботи кожного акаунта в окремі незалежні середовища. Середовища можна зберігати довго: учасникам команди не потрібно обмінюватися паролями чи багаторазово виходити й входити в один браузер.

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

Чому їх потрібно використовувати разом

Якщо розкласти повне середовище акаунта, рівняння складається лише з п'яти частин:

Середовище акаунта = мережевий вихід + сесія браузера + параметри пристрою + дані акаунта + дії оператора

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

2. Сценарії, у яких мультиакаунт виправданий

Розумні та поширені сценарії:

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

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

3. Як обрати проксі-IP

Вибір за протоколом

• HTTP-проксі: підходить для звичайних HTTP-запитів, але спершу переконайтеся в підтримці цільового сайту та використовуваного способу автентифікації;
• HTTPS-проксі: зазвичай означає HTTP-проксі, здатний нести HTTPS-з'єднання, часто через тунель CONNECT;
• SOCKS5-проксі: універсальніший, пересилає трафік багатьох застосунків, але розв'язання DNS і підтримка UDP залежать від клієнта та провайдера;
• PAC: компанія може використовувати скрипт автоматичного налаштування, щоб вирішити, які адреси підключати напряму, а які через проксі.

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

Вибір за якістю для бізнесу

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

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

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

Заведіть реєстр проксі

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

4. Будуємо мультиакаунт-середовище на антидетект-браузері

Нижче на прикладі веб-версії PurpleMark показано, як перенести «реєстр проксі + відповідність акаунтів» у реальне середовище браузера. Конкретні назви полів можуть трохи відрізнятися у різних версіях; орієнтуйтеся на реальний інтерфейс.

Крок 1: спочатку складіть таблицю відповідності «акаунт—середовище—мережа»

Перш ніж створювати середовища, продумайте, як співвідносяться акаунти та ресурси:

Акаунт	Юрособа/клієнт	Призначення	Цільовий регіон	Ім'я середовища	Проксі	Відповідальний
Store-A	Entity-A	Управління магазином	US	US-Store-A	Proxy-A	Alice
Brand-B	Client-B	Публікація контенту	GB	GB-Brand-B	Proxy-B	Bob

Принцип: одне середовище відповідає лише одному довгостроковому призначенню акаунта. Ім'я середовища має давати співробітнику змогу одразу побачити юрособу, платформу та регіон; уникайте розпливчастих назв на кшталт «Середовище 1» чи «Новий акаунт».

Крок 2: створіть незалежні середовища браузера

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

Групи можна будувати за клієнтом, юрособою, брендом або платформою. Не робіть «регіон» єдиним виміром групування, інакше різні клієнти в одному регіоні, як і раніше, легко плутатимуться.

Крок 3: прив'яжіть проксі та перевірте зв'язність

Виберіть протокол проксі, заповніть хост, порт, логін і пароль і виконайте перевірку з'єднання. Тест має підтвердити щонайменше п'ять речей:

• чи встановлюється з'єднання успішно;
• чи відповідає вихідний IP і країна/регіон очікуванням;
• чи стабільний доступ до цільової платформи;
• чи йде розв'язання DNS через проксі, як задумано;
• чи не запитує автентифікація проксі дані знову й знову.

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

Крок 4: приведіть параметри браузера до логічної узгодженості

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

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

Крок 5: перший вхід і збереження сесії

Перед першим входом переконайтеся, що ім'я середовища та вихідний IP правильні, потім власник акаунта або авторизований співробітник виконує вхід і двофакторну перевірку. Після успіху закрийте та знову відкрийте середовище, щоб переконатися, що Cookie та локальне сховище коректно відновлюються.

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

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

Крок 6: розподіліть командну роботу за принципом найменших привілеїв

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

Періодично проводьте аудит: хто може відкривати які середовища, хто змінював проксі, хто експортував Cookie чи дані. Коли учасник іде, клієнт припиняє авторизацію або проєкт завершується, одразу відкликайте доступ і ротуйте задіяні облікові дані. Щоденну перевірку зручно починати зі списку «запущені середовища»: спочатку подивіться, які середовища активні, потім перевірте, чи виглядають відповідні журнали операцій нормально.

5. Чек-лист із 10 пунктів перед запуском

1. Акаунт має законну авторизацію та відповідає політиці платформи про кілька акаунтів;
2. Відповідність імені середовища, юрособи, платформи та відповідального коректна;
3. Регіон проксі відповідає реальним бізнес-потребам;
4. Вихідний IP стабільний і нормально досягає цільової платформи;
5. Тести DNS і WebRTC не показують несподіваного мережевого виходу;
6. Часовий пояс, мова, система та регіон проксі логічно узгоджені;
7. Cookie та локальне сховище залишаються лише у відповідному середовищі;
8. Двофакторна перевірка та способи відновлення під контролем компанії;
9. Учасники команди мають лише мінімальні права, потрібні для роботи;
10. Прописано порядок дій під час закінчення терміну проксі, аномальних входів і кадрових змін.

Значення «відрізняється» чи «унікальне», показане тестовим інструментом, не означає «безпечніше». Завдання — зробити конфігурацію реалістичною, стабільною та зрозумілою, а не змушувати кожен параметр виділятися.

6. Розбір типових проблем

Проксі показує успішне з'єднання, але сторінки не відкриваються

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

Регіон IP правильний, але мова чи час на сайті не сходяться

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

Часті коди підтвердження чи додаткові перевірки

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

Кілька акаунтів випадково переплуталися

Одразу зупиніть роботу та перевірте: чи не відкрито помилкове середовище, чи не скопійовано один Cookie, чи не ввімкнено синхронізацію браузера, чи не використовували кілька акаунтів системний браузер. Вийдіть із помилкових сесій, очистіть зачеплені середовища (краще через вбудовані функції очищення кешу та кошика в управлінні середовищами) та за журналом аудиту визначте масштаб помилки. Потім посильте правила спільного доступу та іменування.

Чи потрібно періодично змінювати проксі-IP

Для довгих акаунтів немає єдиної відповіді «обов'язково змінювати регулярно». Поки лінія стабільна, регіон правильний і немає проблем безпеки, зберігати фіксовану відповідність зазвичай простіше пояснити та перевірити. Коли проксі виходить із ладу, змінюється провайдер або бізнес переїжджає, переходьте планово в період низького ризику та фіксуйте причину.

7. Ритм обслуговування проксі та середовищ

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

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

Висновок

Розумне поєднання проксі-IP та антидетект-браузера — це, по суті, метод керування середовищами акаунтів: проксі дає мережевий вихід під бізнес, середовище браузера зберігає незалежні сесії, а права та журнали тримають командну роботу під контролем.

Спершу вибудуйте взаємно однозначну відповідність акаунт—середовище—мережа, потім послідовно виконайте перевірки зв'язності, DNS, WebRTC, Cookie та прав. Довго зберігайте конфігурацію стабільною та фіксуйте кожну зміну. Це помітно знижує плутанину та внутрішні помилки, але фундаментом безпеки акаунта завжди залишаються авторизація платформи, достовірні дані та відповідне ведення справ.

Щоб упровадити цей процес у команді, відкрийте веб-версію PurpleMark і йдіть у порядку «таблиця відповідності → створення середовища → прив'язка проксі → узгодженість параметрів → збереження сесії → призначення прав»: спочатку доведіть перше середовище акаунта до кінця, потім поступово поширте на решту.