Где должны жить профили автоматизации, и почему не рядом с рабочими

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

Во что обходится профиль на каждую задачу

Каталоги стоят дёшево. Пространство имён - нет.

Всё, что перечисляет профили, вынуждено перечислять их так же, как и вы: настольное приложение, ваши собственные скрипты, диалог экспорта. Прогон, создавший task-1, task-2 и так далее до task-400, выкладывает 400 записей перед каждым из этих читателей, причём навсегда: никто не знает, что прогон уже закончился.

Имена ещё и пересекаются между прогонами. Прошломесячный task-14 и сегодняшний task-14 - это один каталог, поэтому второй прогон наследует куки и личность первого. Иногда именно это и нужно. Когда не нужно, оно проявляется не ошибкой, а необъяснимо залогиненной сессией.

Что меняет временный режим

temporary: true переносит профиль во второе дерево. В каталоге кеша, по умолчанию ~/.anti-detect-browser, управляемые профили лежат в profiles/, а временные - в profiles-temp/. Из одного этого разделения следует три вещи:

Настольное приложение их не видит. Оно читает только управляемое дерево, поэтому временного профиля нет ни в списке, ни в поиске, ни в диалоге экспорта.

Два дерева - это два разных пространства имён. Временный gmail и управляемый gmail - разные профили со своим отпечатком, куками и passkey. Ни один не может затереть другой.

Сервер о них не спрашивают. Временный профиль локален по построению, так что прогон не создаст облачных профилей просто потому, что запускал браузеры.

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

import { AntiDetectBrowser } from 'anti-detect-browser'

const ab = new AntiDetectBrowser({
  key: process.env.ANTI_DETECT_BROWSER_KEY,
  temporary: true,
})

for (const task of tasks) {
  const { page, browser } = await ab.launch({ profile: `task-${task.id}` })
  await page.goto(task.url)
  await browser.close()
}

temporary: false в конкретном вызове launch() возвращает один профиль обратно в управляемое дерево.

Ничего не удаляется само, и это осознанно

Временный профиль переживает browser.close() вместе с отпечатком, куками и passkey. Удалять при закрытии было бы опрятнее - и заодно означало бы, что каждая повторная попытка приходит на тот же аккаунт из того же скрипта с совершенно нового устройства без истории. Это один из самых надёжных способов получить пометку на аккаунте. Повторное использование здесь и есть функция; отдельное дерево решает лишь то, кому придётся смотреть на эти профили, а не сколько они живут.

Поэтому чистка задаётся явно:

const removed = ab.clearTemporaryProfiles({ olderThanDays: 7 })
console.log(`удалено профилей: ${removed.length}`)

или из терминала:

npx anti-detect-browser --clear-temp --older-than=7 --dry-run

Возраст считается от последней записи ядра браузера в профиль, а не от момента создания, поэтому профиль, которым вы пользуетесь раз в неделю, не попадёт под чистку. Вызов возвращает имя, каталог и размер в байтах всего удалённого, а --dry-run печатает тот же список, ничего не удаляя. Читается при этом только profiles-temp/, так что управляемый профиль с тем же именем ничем не рискует.

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

Когда этот переключатель не нужен

Если у вас несколько долгоживущих профилей, которые вы и сами открываете руками, оставьте их управляемыми. Вся ценность здесь в том, чтобы убрать профили из списка, а спрятать профиль, на который вы хотите нажать, - чистый проигрыш.

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

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

Как проверить самому

Сделайте один временный запуск и загляните в оба дерева:

ls ~/.anti-detect-browser/profiles ~/.anti-detect-browser/profiles-temp

Новое имя должно оказаться во втором каталоге, отсутствовать в первом и не появиться в настольном приложении после обновления списка. Затем запустите чистку с --dry-run и убедитесь, что в списке на удаление нет ничего знакомого.

Подробности по API - в документации SDK, а что входит в тарифы - на странице цен.