Кейс7 хв читання

Масштабування реєстрації акаунтів на 50 профілів: реальний пакетний сценарій

Команда поєднала унікальні дані профілів, автоматичне розв’язання CAPTCHA та recovery-перевірки, щоб провести реєстрацію у 50 браузерах послідовно від початку до кінця.

8 бер. 2026 р.

Сценарій

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

Виконання вручну займало б 3-4 години. З Ornold MCP та AI-агентом весь пакет завершився менш ніж за 25 хвилин — включаючи розв'язання CAPTCHA та відновлення після помилок.

Підготовка: дані для кожного профілю

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

Команда підготувала набір даних з:

Унікальні адреси електронної пошти (по одній на профіль, від різних провайдерів)
Реалістичні імена, що відповідають локалі/мові профілю
Надійні паролі (унікальні для кожного профілю, не послідовні)
Номери телефонів для SMS-верифікації (з сервісу віртуальних номерів)

Якість даних важливіша за швидкість автоматизації. Одна дублікована електронна пошта або явно підроблене ім'я можуть спричинити виявлення шахрайства та позначити весь пакет. Витратьте час на створення реалістичних, різноманітних наборів даних.

// Приклад структури набору даних профілю
const profiles = [
  { email: "sarah.mitchell@proton.me", name: "Sarah Mitchell", phone: "+1-555-0142", password: "kR9#mPx2vL" },
  { email: "james.wong@tutanota.com", name: "James Wong", phone: "+1-555-0198", password: "nT4$hQw8bJ" },
  // ... ще 48 унікальних профілів
];

Етап 1: запуск та навігація

З 50 готовими сесіями Linken Sphere (кожна зі своїм проксі, відбитком та часовим поясом) першим кроком була одночасна навігація всіх на сторінку реєстрації.

// Запустити всі сесії та перейти на сторінку реєстрації
await browser_list(); // Перевірити, що доступні 50 сесій
await browser_parallel_navigate({ url: "https://target.example/signup" });

// Чекати завантаження форми у всіх сесіях
await browser_parallel_wait_for({
  text: "Create your account",
  timeoutMs: 20000
});

48 з 50 сесій завантажили сторінку реєстрації за 8 секунд. Дві сесії були повільніші через затримку проксі — команда `wait_for` чекала, поки вони наздогнали на позначці 14 секунд.

Етап 2: заповнення форми

Кожній сесії потрібні були власні унікальні дані. Команда паралельного заповнення Ornold приймає масив значень, які відповідають 1:1 активним сесіям:

// Заповнити електронну пошту — кожна сесія отримує унікальне значення
await browser_parallel_fill({
  ref: "email",
  values: profiles.map(p => p.email)
});

// Заповнити ім'я
await browser_parallel_fill({
  ref: "fullname",
  values: profiles.map(p => p.name)
});

// Заповнити пароль
await browser_parallel_fill({
  ref: "password",
  values: profiles.map(p => p.password)
});

Заповнення форми у всіх 50 сесіях займало близько 3 секунд. Режим взаємодії на основі DOM (безплатний, без vision-кредитів) справився зі структурованими полями форми без проблем.

Етап 3: розв'язання CAPTCHA

На сторінці реєстрації був виклик reCAPTCHA v2. Ornold виявив його у всіх 50 сесіях і паралельно відправив запити на розв'язання:

// Розв'язати CAPTCHA у всіх 50 сесіях
const captchaResult = await browser_solve_captcha();
// { total: 50, detected: 50, solved: 47, failed: 3 }

47 з 50 CAPTCHA розв'язані з першої спроби (15-35 секунд). Три сесії не пройшли — сервіс розв'язання вичерпав час. Замість повторної спроби всього пакету команда повторила лише невдалі сесії:

// Повторити невдалі сесії
const retryResult = await browser_solve_captcha();
// Спрямовується лише на сесії, які все ще мають нерозв'язані CAPTCHA
// { total: 3, detected: 3, solved: 3, failed: 0 }

Розв'язання CAPTCHA — найповільніший крок у більшості потоків реєстрації. Розв'язуйте після заповнення форми (не раніше), щоб мінімізувати ймовірність закінчення терміну дії токена.

Етап 4: відправка та перевірка

З заповненими формами та розв'язаними CAPTCHA наступний крок — натиснути кнопку відправки та перевірити, що реєстрація пройшла успішно:

// Відправити форму
await browser_parallel_click({ ref: "submit" });

// Чекати сторінку успіху
await browser_parallel_wait_for({
  text: "Check your email",
  timeoutMs: 15000
});

// Перевірити статус
const status = await browser_status();

Результати після відправки:

46 сесій досягли сторінки підтвердження "Check your email"
2 сесії отримали додатковий виклик безпеки (запит верифікації по телефону)
1 сесія отримала помилку "too many requests"
1 сесія вичерпала час під час відправки

Етап 5: відновлення після помилок

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

Верифікація по телефону (2 сесії)

Цим сесіям потрібен був додатковий крок. AI-агент виявив поле введення телефону, заповнив віртуальні номери з набору даних та відправив. Обидві сесії завершилися після SMS-верифікації.

Помилка обмеження швидкості (1 сесія)

Помилка "too many requests" була пов'язана з проксі — IP був використаний нещодавно. Команда переключила проксі сесії та повторила спробу. Реєстрація пройшла успішно з другої спроби.

Вичерпання часу (1 сесія)

Проста перезагрузка сторінки та повторна відправка це виправили. Дані форми все ще були заповнені (браузер їх зберіг), тому потрібно було лише повторити дію відправки.

Кінцевий результат: 50 з 50 облікових записів успішно зареєстровані. Загальний час від першої навігації до останнього підтвердження: 23 хвилини.

Що це зробило можливим

Кілька факторів перетворили це з крихкого скрипту на надійну пакетну операцію:

Дані для кожного профілю — кожна сесія мала унікальні, реалістичні дані. Без дублікатів, без паттернів.
Паралельне виконання — всі 50 сесій проходили кожен етап разом, а не по одній за раз.
Вибіркове відновлення — помилки обробляються для кожної сесії, а не перезапуском всього пакету. AI-агент визначив, що пішло не так, і застосував правильне виправлення.
Перевірки статусу між етапами — виклики `browser_status()` та `wait_for` після кожного кроку рано виявляли розбіжності.
Логіка повторного розв'язання CAPTCHA — невдалі розв'язання повторювалися індивідуально замість повторного розв'язання всього пакету.

Розбір часу

Запуск сесії + навігація: ~15 секунд
Заповнення форми (50 сесій): ~3 секунди
Розв'язання CAPTCHA (перший проход): ~35 секунд
Повторне розв'язання CAPTCHA (3 сесії): ~25 секунд
Відправка форми + перевірка: ~10 секунд
Відновлення після помилок (4 сесії): ~8 хвилин
Всього: ~23 хвилини на 50 облікових записів

Без етапу відновлення після помилок щасливий шлях для 46 сесій завершився б приблизно за 2 хвилини. Більшість загального часу була витрачена на розв'язання CAPTCHA та обробку граничних випадків — що очікується в такому масштабі.

Уроки для подальшого масштабування

Якість даних — вузьке місце, а не швидкість автоматизації. Витратьте більше часу на реалістичні набори даних, ніж на оптимізацію часу клику.
Якість проксі безпосередньо впливає на процент успіху. Дешеві спільні проксі призводять до обмежень швидкості та блокування. Житлові або мобільні проксі працюють значно краще.
Не запускайте більше сесій, ніж може обробити ваша машина. 50 екземплярів Chromium потребують 16-24 ГБ оперативної пам'яті. Стежте за використанням ресурсів та масштабуйте обладнання перед масштабуванням кількості сесій.
Вбудуйте відновлення в робочий процес з самого початку. При 50+ профілях деякі помилки гарантовані. Питання в тому, обробляєте ви їх автоматично чи вручну.
Спочатку протестуйте з 5 профілями. Перевірте весь потік від початку до кінця перед масштабуванням до 50. Налагодження в масштабі експоненціально складніше.
Розподіліть великі пакети. Запуск 100 профілів одночасно з одного діапазону IP — червоний прапор. Розділіть на групи по 20-30 з затримками між ними.