Octo Browser настройка прокси: менеджер адресов, теги и запуск профилей из кода

Раздел 1.4 · Антидетект-браузеры

1. Что понадобится

Клиент Octo Browser под Windows, macOS или Linux, действующий аккаунт и открытая вкладка «Профили». От сервиса адресов нужен готовый список. Кабинет отдаёт его ссылкой либо файлом в двух формах записи: IP:PORT для случая, когда доступ открыт по привязанному внешнему адресу машины, и IP:PORT:LOGIN:PASS для случая с парой доступа. Протокол задаётся в карточке отдельным полем, программа ровно работает с SOCKS5, HTTP и HTTPS. Автоматизация потребует ещё двух вещей: локального интерфейса на порту 58888 и токена облачного интерфейса из настроек аккаунта.

Арифметику потоков я свожу до того, как заведу первую партию карточек. Обычные пакеты дают 1000 одновременных соединений, корпоративный до 3000, суммировать пакеты между собой по этому показателю нельзя, а две привязанные машины делят выделенное число пополам. Открытое окно Octo, где крутится лента с картинками, съедает десятки соединений сразу, поэтому запас перестаёт казаться большим примерно на четвёртом десятке одновременно работающих карточек. Гигабайты при этом никто не считает, трафик идёт без ограничения объёма. Парку, который поднимают каждый рабочий день, я беру месячный доступ к пулу адресов: пакет включается минут за пять, а форму записи перед большой раздачей проверяю бесплатным тестом до 2 часов.

2. Менеджер прокси и хранение адресов отдельно от профилей

Раздел «Прокси» открывается из левого меню и существует независимо от карточек. Внутри лежат записи, у каждой своё название, протокол, хост, порт, пара доступа и набор тегов. Профиль хранит у себя ссылку на запись, строка подключения живёт в одном экземпляре. Такая раскладка меняет цену обновления списка: правка одной записи расходится по всем ссылающимся на неё карточкам при их следующем запуске.

Массовое добавление живёт в той же вкладке под кнопкой «Импорт». Поле берёт многострочный текст, по строке на запись, и разбирает три формы записи сразу. Кусок списка я вставляю прямо из кабинета сервиса. Очерёдность строк при вставке остаётся прежней, значит номер позиции в кабинете указывает на ту же запись внутри менеджера.

192.0.2.140:1080:o5824:Rw7pLd3v
socks5://o5824:Rw7pLd3v@192.0.2.140:1080
203.0.113.201:3128

Третья форма без пары доступа рассчитана на привязку внешнего адреса машины в кабинете сервиса. Привязок пакет даёт две, переставляются они без ограничения по числу правок, поэтому выход из офиса и выход из дома уживаются рядом без переоформления. Я держу под рукой оба варианта списка: со стационарных машин короткая форма быстрее, с ноутбуков по случайным сетям выручает пара доступа. Браузерным карточкам я ставлю серверные адреса без обрывов сессии, потому что окну с открытой сессией важна ровная связь от запуска до закрытия.

Записи, которыми давно никто не пользуется, я убираю партиями примерно раз в две недели. Менеджер спокойно вмещает хоть тысячу строк, поэтому за месяц раздел раздувается вдвое, а годной в нём остаётся едва половина. Колонка «Профили» напротив записи показывает количество ссылающихся карточек, и нули из неё уходят под удаление первыми. Порядок у меня жёсткий: сперва удаление пустующих записей, затем импорт нового набора, затем раздача по тегам. Карточка, у которой запись пропала из менеджера, при старте покажет сетевое поле пустым и выйдет собственным адресом машины, поэтому откладывать удаление на потом смысла нет.

3. Привязка адреса к профилю при создании и при массовом создании

Форма новой карточки открывается кнопкой «Создать профиль». Сетевой блок называется «Прокси» и стоит следом за именем, тегами и версией ядра. Верхнее поле блока задаёт источник адреса, и от него зависит, что покажется ниже: строка поиска по менеджеру либо пять пустых полей под ручной ввод.

Массовое создание открывается той же кнопкой, переключателем «Несколько профилей» в верхней части окна. Задаются количество, шаблон имени со счётчиком вида shop-{n}, общий набор тегов и источник адресов. Источником выступает выборка из менеджера по тегу, и вот здесь порядок раздачи стоит понимать заранее. Программа идёт по выборке сверху вниз и отдаёт по одной записи на карточку. Когда карточек в партии больше, чем записей в выборке, список пойдёт по кругу с начала, и верхние записи достанутся сразу двум или трём профилям.

Сверять эту арифметику удобно прямо в менеджере до нажатия кнопки: включаете фильтр по тегу и смотрите счётчик записей над таблицей. Число из счётчика и количество карточек в окне создания должны сойтись, когда каждому профилю положен свой адрес. Оба числа я выписываю рядом перед запуском, потому что искать пересечения по колонке адреса среди сотни готовых карточек заметно дольше. Под такие партии список я забираю сразу в полной форме, тогда любая строка ложится в импорт менеджера без переделки. Разбор той же раскладки для соседнего антидетекта лежит на странице про раскладку адресов в Dolphin Anty.

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

4. Теги и группировка адресов под задачи

Теги в Octo висят и на карточках, и на записях менеджера, причём наборы эти независимы друг от друга. Совпадение имён между ними я держу намеренно: тег парсинг на записи и тег парсинг на профиле дают одинаковую выборку в двух разных списках, и раздача сводится к двум движениям фильтра.

Плотность посадки карточек на запись определяется характером работы окна. Профиль, заглядывающий в почтовый ящик раз в сутки, по нагрузке почти бесплатен, и десяток таких на одну запись живёт спокойно. Профиль, который часами листает выдачу и качает файлы, удерживает соединения долго, ему я даю запись на двоих или троих и развожу запуски паузами.

Отдельная тема это подсети внутри набора. Строки в списке часто оказываются соседями по третьему октету, и группа карточек, вышедшая с рядом стоящих хостов, для площадки выглядит связанной. Разложить набор по подсетям взглядом тяжело уже на пятом десятке строк, поэтому я считаю их командой:

Get-Content .\pool.txt | ForEach-Object { (($_ -split ':')[0] -split '\.')[0..2] -join '.' } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 6 Name, Count

Когда верхняя строка вывода показывает два десятка хостов в одной подсети, я развожу эти записи разными тегами и отдаю разным группам профилей. В пуле держится порядка 12 000 адресов, так что материала на широкую выборку достаточно всегда. Обновление набора идёт автоматически на стороне сервиса, ротация внутри пула работает мне на руку: перебирать строки вручную не приходится. Общий подход к раскладке строк по карточкам я расписывал на странице про адреса для антидетект-браузеров.

5. Встроенная проверка и что она показывает

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

Границы отчёта задаются его устройством. Запрос уходит один, живёт доли секунды и идёт на порт 443, поэтому долгую работу под нагрузкой и проходимость нестандартного порта площадки он оставляет без ответа. Смотрит отчёт только на адрес выхода, значит утечка внутреннего адреса через WebRTC и поход за именами мимо посредника пройдут мимо его внимания. И отношение самой площадки к маршруту отчёт предсказать бессилен, у площадки на этот счёт свои правила.

Перечисленное я добираю руками, минут за пять на группу карточек. Первое окно из партии запускаю и оставляю с автообновлением на три минуты, наблюдая за разрывами. Потом открываю страницу проверки WebRTC. Потом страницу проверки серверов имён. Заход на саму площадку идёт последним. Держать вкладку открытой хоть час я могу без оглядки на счётчик, потому что адреса с безлимитным трафиком снимают вопрос объёма целиком, платится только срок доступа к пулу.

Массовая проверка занимает время пропорционально размеру выборки: сотня записей отрабатывает минуты за четыре, и на всём протяжении клиент подтормаживает, интерфейс отвечает с задержкой. Я запускаю её перед перерывом и возвращаюсь к готовой колонке статусов. Красные строки обычно идут группами, поэтому первых полусотни хватает, чтобы понять состояние набора целиком.

6. Работа команды и раздача профилей сотрудникам

Карточки Octo лежат в облаке команды, поэтому передача профиля сотруднику сводится к выдаче доступа, копировать что-либо между машинами не нужно. Доступ раздаётся по тегам: человек видит карточки со своим тегом, остальной парк для него закрыт. Записи менеджера привязаны к команде целиком, и заранее стоит решить, кому из участников показывать пары доступа.

Раскладка, к которой я пришёл на команде из шести человек, выглядит так. Записи заводит один администратор, он же хранит файл со списком и обновляет набор. Сотрудники получают карточки по тегу площадки и работают с готовой привязкой, поля пары у них закрыты. Отладочный тег с двумя строками открыт всем, чтобы новую сборку профиля можно было обкатать без обращения к администратору.

Уход человека из команды упирается в один шаг: перевыпуск пары доступа в кабинете сервиса. Он обесценивает прежние копии строки разом, после чего старые файлы со списком ничего не открывают. Я делаю перевыпуск каждый раз, когда доступ к менеджеру теряет владельца, следом импортирую свежий набор и прогоняю массовую проверку. На парке из двух сотен карточек вся процедура занимает минут десять. Команде, где окна поднимает вся смена ежедневно, удобнее держать срок доступа на месяц, тогда перевыпуск пары и обновление набора укладываются в один заход без пересборки раскладки по тегам.

7. Интерфейс автоматизации Octo и запуск профилей из кода

Интерфейсов два, и обязанности между ними разделены. Локальный поднимается вместе с клиентом на порту 58888 и заведует запуском и остановкой окон на этой машине. Облачный живёт на стороне сервиса, принимает токен из настроек аккаунта и заведует самими карточками: список, создание, правка привязки.

LOCAL=http://127.0.0.1:58888/api
CLOUD=https://app.octobrowser.net/api/v2/automation
TOKEN=<токен из настроек аккаунта>

curl -s "$LOCAL/profiles/active"
curl -s -X POST "$LOCAL/profiles/start" -H 'Content-Type: application/json' \
     -d '{"uuid":"7ac1f0e94b2d","headless":false,"debug_port":true}'
curl -s -X POST "$LOCAL/profiles/stop"  -H 'Content-Type: application/json' \
     -d '{"uuid":"7ac1f0e94b2d"}'
curl -s "$CLOUD/profiles?page=0&page_len=50" -H "X-Octo-Api-Token: $TOKEN"

Обращение к карточке идёт по её uuid, человеческое имя профиля обоим интерфейсам безразлично. Соответствие имён и идентификаторов я выгружаю облачным вызовом после каждой новой партии и держу отдельным файлом возле скрипта. Старт отвечает полями ws_endpoint и debug_port, первое подставляется в подключение драйвера без переделки.

const start = await fetch('http://127.0.0.1:58888/api/profiles/start', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ uuid: '7ac1f0e94b2d', debug_port: true })
}).then(r => r.json());

const browser = await puppeteer.connect({ browserWSEndpoint: start.ws_endpoint });
const page = (await browser.pages())[0];
await page.goto('https://example.net/');
console.log(await page.title());

Залповый запуск партии клиент не вытягивает: окна не успевают подняться, ответ приходит без адреса отладочного порта, драйвер падает на подключении. Я развожу старты на 2 секунды и подаю по восемь окон за раз. При такой подаче пустых ответов у меня не было ни разу.

Привязку меняет облачный интерфейс, форму открывать не требуется. Тело правки ссылается на запись менеджера её собственным идентификатором:

{
  "uuid": "7ac1f0e94b2d",
  "proxy": {
    "external_id": "px-4471",
    "type": "socks5",
    "host": "192.0.2.140",
    "port": 1080,
    "login": "o5824",
    "password": "Rw7pLd3v"
  }
}

Запрос уходит методом PATCH на /profiles/{uuid}. Через него парк и переезжает на обновлённый набор: скрипт читает файл, сопоставляет строки с идентификаторами карточек и рассылает правки пачками по 25 штук. Двести профилей меняют привязку минуты за две, руками столько же заняло бы полдня. Поле external_id я заполняю всегда, оно связывает карточку с записью и оставляет счётчик профилей у записи верным.

Два свойства интерфейса, которые экономят время. Старт уже открытого окна возвращает прежний адрес отладочного порта и окно при этом не трогает, так что после сетевого сбоя скрипт можно вызывать повторно без риска получить дубль. Остановка через интерфейс сбрасывает куки и локальное хранилище на диск и отправляет их в облако команды, снятие процесса через диспетчер задач такой записи не даёт. Доступность порта я смотрю до первого прогона скрипта:

(Test-NetConnection 127.0.0.1 -Port 58888).TcpTestSucceeded

Ответ False бывает по двум поводам: клиент ушёл в трей после выхода из аккаунта либо порт занял посторонний процесс. Во втором случае владельца показывает netstat -ano | findstr 58888.

8. Проверка после настройки

Карточка поднимается кнопкой запуска в своей строке. Первая вкладка появляется секунды за четыре. Затянувшийся старт почти всегда говорит про несостоявшийся канал до посредника: браузер сидит и ждёт таймаута.

Четвёртая строка таблицы закрывается одной командой в консоли открытого окна, ответ приходит значением вида Europe/Amsterdam:

Intl.DateTimeFormat().resolvedOptions().timeZone

Последняя строка таблицы стоит десяти секунд и экономит час разбирательств. Одинаковые адреса у двух соседних карточек означают, что при массовом создании выборка пошла по кругу: профилей в партии оказалось больше, чем записей под тегом. Поправить это до начала работы куда приятнее.

Сетевой журнал в инструментах разработчика я открываю следом. Обращение в обход посредника выдаёт себя слишком быстрым ответом на фоне соседних строк журнала. Приносят такие обращения расширения со своими каналами связи, помогает отключение лишнего внутри карточки. Результат прогона я держу в поле «Заметка»: дата и перечень пройденных строк таблицы. Поле выводится колонкой в списке профилей и фильтруется, так что после обновления набора видно, какие карточки ещё ни разу не открывали.

9. Разбор ошибок

Пару слов про поведение адреса внутри открытого окна. Обновление пула идёт само собой, и это работает мне на пользу: набор строк остаётся свежим без ручного перебора. Уже установленное соединение внутри сессии держится ровно, а импорт нового списка перед прогоном приводит менеджер в актуальный вид. Обновляю я набор каждые несколько суток, привязку по парку раскидывает скрипт через облачный интерфейс, и укладывается всё в пару минут.

Соседние страницы справочника разбирают такую же настройку в остальных антидетект-браузерах: подключение адресов в AdsPower, настройка прокси в BitBrowser и работа с адресами в GenLogin, где хранилище устроено по-своему. Когда посредник понадобился обычному браузеру рядом, на этом же компьютере, откройте страницу про сетевые настройки профилей Firefox.