Прокси для Dolphin Anty: настройка профиля по шагам с проверкой после каждого

Прокси в Dolphin Anty это запись доступа, привязанная к карточке браузерного профиля: профиль уходит в сеть через указанный хост и порт, и площадка видит адрес из пула, рабочая машина остаётся за ним. Отпечаток профиля отвечает за то, каким устройством выглядит браузер: user-agent, разрешение экрана, набор шрифтов, WebGL, часовой пояс. Запись прокси отвечает за точку выхода. Живут эти настройки в разных местах интерфейса, проверяются разными способами, и путаница между ними обходится дороже всего остального. Я веду несколько десятков профилей и настраиваю их по одному порядку: строка доступа, поля карточки, встроенная проверка, запуск. После каждого шага идёт своя проверка. Ниже разбираю все четыре шага и показываю, какие ошибки находятся за минуту и какие всплывают уже после входа в аккаунт.

Блок прокси в карточке профиля: какие поля заполняются

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

Первым ставится тип. От него зависит, как браузер будет разговаривать с портом: SOCKS5 передаёт TCP-поток и умеет отдавать разрешение имён на сторону прокси, HTTP работает по методу CONNECT и разбирает заголовки запроса. Оба варианта входят в пакет, и в карточке они выбираются одним кликом. Дальше идут хост и порт: сюда переносится левая часть строки доступа из кабинета. Потом логин и пароль, у них своя логика, о которой ниже отдельный раздел. Последним заполняется имя записи, и это поле новички пропускают чаще всего.

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

Общий список адресов и привязка к профилю: разные сущности

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

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

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

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

Форматы строки доступа: IP:PORT и IP:PORT:LOGIN:PASS

Список адресов в кабинете выдаётся двумя форматами, и оба принимаются Dolphin при импорте. Разница между ними лежит в способе доступа к порту.

IP:PORT работает по привязке своего адреса. В кабинете указывается адрес машины, с которой пойдут запросы, и порт пускает соединения только оттуда. В пакет входит два таких адреса, менять их можно свободно. Формат удобен, когда Dolphin стоит на одной постоянной машине или на сервере с фиксированным выходом: полей логина и пароля в карточке заполнять не нужно, они остаются пустыми, и строка выглядит короткой. Тонкость одна: при двух привязанных адресах лимит потоков делится между ними пополам, поэтому для тяжёлых прогонов я оставляю привязку одной машины.

IP:PORT:LOGIN:PASS работает по паре доступа. Порт пускает любого, кто предъявил правильную пару, и машина может быть какой угодно. Этот формат я беру для ноутбука, для второй рабочей станции и для случаев, когда Dolphin запускается через удалённый рабочий стол на арендованном сервере. Смена сети никак не сказывается: пара работает из офиса, из дома, с телефонной раздачи.

# формат с привязкой
203.0.113.41:1080
203.0.113.58:1080

# формат с парой доступа
203.0.113.41:1080:u7391:kQ4rTm2p
203.0.113.58:1080:u7391:kQ4rTm2p

При импорте Dolphin разбирает строку по двоеточиям и раскладывает части по полям автоматически. Ошибки возникают на трёх вещах. Первая: в буфер вместе со строкой попал перевод строки или хвостовой пробел, и пароль сохраняется с лишним символом. Вторая: список пришёл в записи вида LOGIN:PASS@IP:PORT, такой порядок Dolphin читает иначе, и части встают не по своим полям. Третья: в пароле встретилось двоеточие, разбор ломается на нём. Все три случая видны сразу, если после импорта открыть одну запись и посмотреть, что легло в поля. Список из кабинета отдаётся ссылкой или файлом, и я всегда беру файл: из файла строки переносятся без промежуточного буфера, а значит без хвостовых пробелов.

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

Четыре шага настройки и проверка после каждого

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

Шаг первый: строка доступа. Я беру файл со списком, открываю его в редакторе, смотрю на одну строку и убеждаюсь, что в ней ровно то количество частей, которое обещает формат. Проверка шага делается через curl из терминала, до всякого Dolphin. Если строка отвечает в терминале, дальше можно работать спокойно.

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

Шаг третий: встроенная кнопка проверки. Dolphin стучится на порт своими силами и возвращает страну, статус и время ответа. Проверка шага в самом её результате: зелёный статус означает, что порт принял соединение и отдал ответ.

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

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

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

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

Первый способ работает вне Dolphin. Терминал обращается на тот же порт с той же парой доступа и показывает адрес, под которым запрос выходит наружу.

# SOCKS5 с парой доступа, разрешение имён на стороне порта
curl -x socks5h://u7391:kQ4rTm2p@203.0.113.41:1080 -s https://api.ipify.org

# тот же порт по HTTP, с кодом ответа и временем
curl -x http://u7391:kQ4rTm2p@203.0.113.41:8080 \
     -s -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com

# формат с привязкой, без пары доступа
curl -x socks5h://203.0.113.41:1080 -s https://api.ipify.org

Вывод первой команды даёт адрес выхода. Он должен отличаться от адреса машины и совпадать с хостом из строки. Вторая команда добавляет код ответа и время: код 200 при времени до полусекунды говорит о нормальном канале, время за две секунды указывает на дальний маршрут либо на загруженный порт. Третья команда показывает, работает ли привязка: если она отвечает без пары доступа, значит адрес машины в кабинете указан верно.

Второй способ работает внутри Dolphin, но до входа в целевой аккаунт. Я запускаю профиль и открываю сервис определения адреса. Смотрю три вещи подряд: сам адрес, ответ по DNS и наличие локального адреса в блоке WebRTC. Адрес совпал, серверы имён принадлежат сети порта, WebRTC пуст. После этого профиль готов к работе.

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

Встроенная проверка: что она показывает и что остаётся за кадром

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

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

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

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

Как разнести профили по адресам

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

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

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

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

Массовый импорт профилей и раскладка адресов

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

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

# убрать пустые строки и хвостовые пробелы
sed -e 's/[[:space:]]*$//' -e '/^$/d' proxies.txt > proxies.norm.txt

# найти повторы
sort proxies.norm.txt | uniq -d

# посчитать части в каждой строке: должно быть 2 либо 4
awk -F: '{print NF, $0}' proxies.norm.txt | sort -n | uniq -c -w2

Третья команда показывает распределение по количеству частей. Если в выводе появились строки с тремя частями или с пятью, там сломан разбор, и такие строки я вычищаю до импорта. Дубли снимаю сразу: одна запись, попавшая в список дважды, потом привяжется к двум профилям, и они пойдут через одну точку входа при полной уверенности, что точки разные.

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

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

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

Как хранить пары логин-пароль

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

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

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

Третье: смена пары при смене состава команды. Человек ушёл, пары меняются в кабинете, новые строки раскладываются по записям. Занимает пятнадцать минут при сотне профилей, если таблица соответствия ведётся аккуратно.

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

Что у меня стоит в постоянной схеме

Порядок из четырёх шагов я не меняю уже давно, потому что он окупается на каждой новой пачке профилей. Строка проверяется в терминале до Dolphin. Поля карточки сверяются глазами после сохранения. Кнопка проверки отсекает опечатки. Запуск профиля подтверждает адрес, серверы имён и WebRTC на живой странице.

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

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

Рядом в разделе инструментов лежат смежные разборы: прокси в Key Collector с настройкой потоков под съём позиций, подключение прокси в A-Parser с раскладкой списка по заданиям и настройка прокси в ZennoPoster с привязкой адресов к шаблонам. Из раздела основ к теме профилей ближе всего страница про белый или серый адрес: там разобрано, какие признаки адреса площадка читает раньше отпечатка браузера.