Інженерія10 хв читання

Як запускати десятки антидетект-браузерів паралельно та не втрачати синхронізацію

Розбираємо груповий vision-аналіз, відновлення статусів і контроль конкурентності, які дозволяють великим пакетам браузерів працювати як єдина система.

1 квіт. 2026 р.

Виклик паралельної автоматизації браузерів

Запустити один браузер просто. Запустити 50 браузерів, які роблять те саме одночасно — це зовсім інша проблема. Сторінки завантажуються з різною швидкістю, CAPTCHA з'являється в деяких сесіях, але не в інших, і умови мережі різняться між профілями. Без координації паралельний пакет швидко перетворюється на 50 незалежних скриптів, які розходяться.

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

Як працює паралельне виконання в Ornold

Коли ви говорите AI-агенту "відкрити google.com у всіх браузерах", Ornold не проходить по сесіях одну за одною. Він відправляє команду навігації всім активним сесіям паралельно через CDP (Chrome DevTools Protocol). Те саме стосується кліків, заповнення форм, скриншотів та всіх інших дій браузера.

// This navigates ALL active sessions simultaneously
await browser_parallel_navigate({ url: "https://target.example/signup" });

// This fills the email field in ALL sessions at once
// Each session can get a different value
await browser_parallel_fill({
  ref: "email",
  values: profiles.map(p => p.email)
});

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

Групований візуальний аналіз

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

Групований візуальний аналіз Ornold вирішує це, беручи скриншоти з усіх сесій, аналізуючи їх як пакет і групуючи сесії за їхнім візуальним станом:

// Analyze all sessions at once
const analysis = await browser_parallel_vision_analyze_grouped();

// Results are grouped by page state:
// group "signup_form": [session1, session2, ... session25]
// group "captcha": [session26, session27, session28]
// group "error_page": [session29]
// group "loading": [session30]

Це принципово відрізняється від перевірки кожної сесії окремо. Один виклик API дає вам повну картину. AI-агент може потім розгалузити логіку: розв'язати CAPTCHA для сесій, які це потребують, повторити навігацію для тих, які не вдалися, і продовжити потік для тих, які готові.

Групований аналіз особливо цінний, коли сторінки розходяться через A/B-тести, геотаргетинг або виявлення ботів. Замість припущення, що всі сесії знаходяться в одному стані, ви бачите реальність кожної з них.

Обмежена паралелізм

Запуск 50 браузерів у справжньому паралелізмі звучить добре, поки ви не зіткнетеся з обмеженнями ресурсів. Кожна сесія браузера споживає CPU, пам'ять і пропускну здатність мережі. Виклики візуального аналізу мають обмеження частоти API. Сервіси розв'язання CAPTCHA обмежують одночасні запити.

Ornold використовує обмежену паралелізм — він обробляє сесії в контрольованих пакетах, а не запускає все одразу:

Дії браузера (навігація, клацання, заповнення) — виконуються у всіх сесіях одночасно. Це легкі CDP-команди, які не навантажують ресурси.
Візуальний аналіз — обробляється групами (за замовчуванням: 12 за раз). Скриншоти беруться паралельно, але виклики аналізу групуються, щоб залишатися в межах обмежень API.
Розв'язання CAPTCHA — запити відправляються паралельно, але сервіс розв'язання природно обмежує на основі потужності. Ornold обробляє чергу.
Скриншоти — захоплюються одночасно з усіх сесій. Дані зображень передаються потоком, а не буферизуються в пам'яті.

// Control concurrency for vision analysis
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 12 });

// For very large batches, you can lower concurrency
// to reduce memory pressure
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 6 });

Відстеження стану та відновлення

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

Ornold забезпечує відстеження стану в реальному часі для кожної активної сесії:

// Check the state of all sessions
const status = await browser_status();
// Returns per-session info:
// { id: "session-1", url: "https://target.example/dashboard", state: "ready" }
// { id: "session-2", url: "https://target.example/signup", state: "ready" }
// { id: "session-3", url: "about:blank", state: "error" }

Маючи дані про стан, AI-агент може приймати рішення про відновлення:

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

Синхронізація сесій

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

Ornold використовує семантику очікування всіх: після кожної паралельної дії він чекає, поки всі сесії завершаться (або закінчиться час очікування) перед переходом до наступного кроку. Це запобігає тому, щоб швидкі сесії не випереджали повільні.

// Navigate all sessions
await browser_parallel_navigate({ url: "https://target.example/signup" });

// Wait until all sessions show the signup form
await browser_parallel_wait_for({
  text: "Create Account",
  timeoutMs: 15000
});
// Only proceeds when ALL sessions are ready (or timed out)

// Now fill forms — all sessions are on the same page
await browser_parallel_fill({ ref: "email", values: emails });

Час очікування в `wait_for` діє як запобіжний клапан. Якщо сесія не може досягти очікуваного стану протягом часу очікування, вона позначається, а не блокує весь пакет назавжди.

Дані для кожного профілю в пакетних операціях

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

// Each session gets its own email
await browser_parallel_fill({
  ref: "email",
  values: [
    "user1@mail.com",
    "user2@mail.com",
    "user3@mail.com",
    // ... one per active session
  ]
});

// Each session gets its own password
await browser_parallel_fill({
  ref: "password",
  values: profiles.map(p => p.password)
});

Масив значень відображається 1:1 на активні сесії по порядку. Якщо у вас є 30 активних сесій, ви надаєте 30 значень. Це зберігає модель паралельного виконання, дозволяючи повну настройку для кожного профілю.

Повний паралельний робочий процес

Ось реалістичний наскрізний потік для реєстрації облікових записів на 30 профілях антидетект-браузера:

// 1. Start sessions and navigate
await browser_list(); // See available profiles
await browser_parallel_navigate({ url: "https://target.example/signup" });
await browser_parallel_wait_for({ text: "Create Account", timeoutMs: 15000 });

// 2. Fill forms with per-profile data
await browser_parallel_fill({ ref: "email", values: emails });
await browser_parallel_fill({ ref: "password", values: passwords });
await browser_parallel_fill({ ref: "name", values: names });

// 3. Solve CAPTCHAs (detected and solved across all sessions)
await browser_solve_captcha();

// 4. Submit
await browser_parallel_click({ ref: "submit" });

// 5. Verify results
await browser_parallel_wait_for({ text: "Welcome", timeoutMs: 20000 });
const status = await browser_status();
// Check which sessions succeeded and which need recovery

Поради щодо масштабування

Почніть з 5-10 сесій для перевірки робочого процесу, потім масштабуйте. Налагодження набагато простіше з малим пакетом.
Використовуйте `browser_status()` після кожного основного кроку. Не припускайте, що всі сесії знаходяться в одному стані.
Встановіть розумні часи очікування. Занадто короткі і ви отримаєте помилкові збої. Занадто довгі і застрявші сесії блокуватимуть весь пакет.
Для пакетів понад 30, розглядайте розділення на групи та їх послідовний запуск. Це зменшує пікове використання ресурсів.
Моніторьте використання ресурсів вашого антидетект-браузера. Кожен профіль споживає RAM — 50 екземплярів Chromium можуть легко використовувати 16+ ГБ.
Утримуйте якість проксі постійною. Змішана якість проксі призводить до змішаних часів завантаження сторінок, що викликає проблеми синхронізації.

Поширені помилки

Припущення, що всі сесії бачать одну й ту ж сторінку — вони не бачать. A/B-тести, геотаргетинг та виявлення ботів створюють розбіжності. Завжди перевіряйте за допомогою `browser_status()` або групованого аналізу.
Відсутність логіки відновлення — якщо ви не обробляєте збої, одна застрявша сесія може заблокувати весь пакет. Вбудуйте повторні спроби та логіку пропуску.
Ігнорування обмежень ресурсів — 50 браузерів + візуальний аналіз + розв'язання CAPTCHA можуть перевантажити машину. Використовуйте обмежену паралелізм.
Послідовне мислення в паралельній системі — не проходьте по сесіях одну за одною. Використовуйте інструменти `browser_parallel_*` для дії на всіх сесіях одночасно.
Відсутність перевірки результатів — успішна відправка форми не означає, що обліковий запис був створений. Завжди перевіряйте кінцевий стан.