Автоматизация на ZennoPoster и A-Parser: какие прокси нужны и как их подключить

ZennoPoster и A-Parser — два самых распространённых в рунете инструмента массовой автоматизации. Первый эмулирует действия в браузере по визуальному шаблону, второй собирает данные из поисковиков и сайтов десятками потоков. У обоих один и тот же ограничитель производительности: как только количество одновременных потоков превышает единицу, всё упирается в адреса, с которых идут запросы.

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

Коротко для тех, кто спешит

• ZennoPoster и A-Parser требуют разных прокси. Первому нужны «человечные» адреса с липкой сессией, второму — большой пул с ротацией и запасом трафика.
• Количество адресов считается от количества потоков, а не от количества задач. Один поток — минимум один адрес в один момент времени.
• Для A-Parser серверные прокси часто достаточны на нетребовательных источниках и заметно дешевле резидентских. На поисковой выдаче и защищённых площадках — только резидентские.
• Для ZennoPoster по аккаунтам работает правило «один аккаунт — один адрес», с липкой сессией на всё время сценария.
• Оба инструмента умеют работать со списком прокси и с ротационным шлюзом. Шлюз проще в настройке, список даёт контроль над тем, какой адрес какой задаче достался.
• Трафик — главная статья расходов в парсинге. Отключение загрузки картинок и медиа в ZennoPoster экономит кратно больше, чем выбор тарифа.

Чем задачи этих программ отличаются с точки зрения прокси

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

ZennoPoster: браузерные сценарии

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

Следствия для прокси:

• Трафика на поток уходит много: полноценная страница со скриптами и картинками весит мегабайты, а не килобайты.
• Сессия должна жить. Если адрес сменится посреди сценария, сайт увидит, что пользователь телепортировался, и сессия слетит.
• Адрес должен выглядеть «человечным» — особенно если сценарий работает с аккаунтом.

A-Parser: массовые запросы к источникам

A-Parser — многопоточный парсер с каталогом готовых модулей под поисковики, маркетплейсы, соцсети и произвольные сайты, с возможностью писать свои парсеры на JavaScript и выгружать результат в CSV, Excel или JSON. Здесь нет браузера: это прямые HTTP-запросы, много и быстро.

Следствия для прокси:

• Трафика на запрос уходит мало — обычно это HTML без медиа. Зато запросов очень много.
• Сессия не нужна: каждый запрос самодостаточен, ротация адреса между запросами не вредит.
• Критична скорость отклика и стабильность: медленный адрес в пуле тормозит весь поток.

Как считать количество прокси под потоки

Это самый частый вопрос и самый частый источник разочарования: «купил 10 прокси, поставил 100 потоков, всё забанилось». Порядок расчёта должен быть обратным — от допустимого темпа к количеству адресов.

Формула для A-Parser

Отталкивайтесь от безопасного темпа запросов на один адрес. Для нетребовательных источников это 20–60 запросов в минуту, для поисковой выдачи и защищённых площадок — 6–12, как мы разбирали в гайде по парсингу Авито.

• Определите нужную скорость сбора: сколько запросов в минуту вы хотите суммарно.
• Разделите на безопасный темп для вашего источника — получите минимальное количество адресов.
• Добавьте 20–30% запаса: часть адресов в любом пуле окажется медленной или уже помеченной источником.

Пример: нужно 600 запросов в минуту по поисковой выдаче, безопасный темп — 10 в минуту на адрес. Минимум 60 адресов, с запасом — около 75. Ставить при этом 200 потоков бессмысленно: они будут стоять в очереди к тем же адресам и создавать всплески.

Формула для ZennoPoster

Здесь считается не темп, а одновременность:

• Сценарии с аккаунтами — один аккаунт один адрес, жёстко. Количество адресов равно количеству активных аккаунтов, а не потоков.
• Сценарии без аккаунтов (сбор данных, проверка страниц) — достаточно одного адреса на поток, адреса можно переиспользовать между запусками.
• Трафик — умножайте количество страниц на их реальный вес. Снимите десяток страниц и посмотрите фактический расход, прежде чем брать тариф.

Какой тип адресов брать

Серверные (датацентровые)

Самый дешёвый вариант и по-прежнему рабочий для A-Parser на нетребовательных источниках: собственные сайты, открытые API, каталоги без защиты, техническая проверка ссылок. Диапазоны дата-центров известны крупным площадкам, поэтому на поисковой выдаче, маркетплейсах и соцсетях они живут плохо. Для ZennoPoster с аккаунтами — не вариант.

Резидентские

Универсальное решение для обеих программ. Адреса домашних провайдеров, тарификация обычно по гигабайтам. Для A-Parser это оптимальный тип на защищённых источниках, для ZennoPoster — рабочий минимум в сценариях с аккаунтами. Основной риск — перерасход трафика, если не следить за весом страниц.

Мобильные

Максимальная живучесть за счёт того, что за одним адресом оператора стоят тысячи реальных абонентов. Оправданны там, где цена ошибки высока: прогрев и ведение аккаунтов в ZennoPoster, работа с площадками, которые агрессивно банят. Для массового парсинга в A-Parser избыточны по цене.

Развёрнутое сравнение сервисов по типам адресов, ценам и лимитам — в материале Топ-5 прокси для парсинга и скрапинга 2026 и в общем рейтинге сервисов.

Как подключить прокси в ZennoPoster

В ZennoPoster есть два принципиально разных пути, и выбор между ними определяет всю схему работы.

Через встроенный менеджер прокси

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

Этот путь предпочтителен, когда вам важно контролировать, какой адрес достался какому аккаунту. Для сценариев с аккаунтами это единственно правильный вариант: заведите таблицу соответствия аккаунт — адрес и подставляйте адрес из той же строки, откуда берётся логин.

Через ротационный шлюз сервиса

Многие сервисы дают единую точку входа, за которой стоит пул адресов: вы подключаетесь всегда по одному хосту и порту, а сервис сам меняет исходящий IP. Настройка проще — один адрес на все потоки, но контроля меньше.

Важная деталь: у большинства сервисов время жизни сессии на шлюзе настраивается — либо параметром в логине, либо отдельным портом под липкую сессию. Для браузерных сценариев ставьте липкую сессию длиннее, чем самый долгий ваш шаблон. Ротация «каждый запрос» в ZennoPoster почти всегда ломает логику: капча будет решаться с одного адреса, а отправляться с другого.

Обязательные настройки на стороне шаблона

• Отключите загрузку картинок и медиа, если данные из них не нужны. Это самая крупная экономия трафика, часто в разы.
• Согласуйте гео адреса с остальным отпечатком: язык интерфейса, часовой пояс, раскладка. Немецкий IP при московском часовом поясе — заметная аномалия.
• Ставьте случайные паузы между действиями. Хорошие прокси не отменяют поведенческого анализа.
• Проверяйте адрес в начале шаблона. Первый шаг — запрос к сервису определения IP; если адрес не тот или не отвечает, шаблон должен остановиться, а не отработать вхолостую.

Как подключить прокси в A-Parser

A-Parser устроен иначе: прокси здесь — отдельная сущность с собственными чекерами и правилами обновления.

• Источник списка. Адреса задаются файлом или ссылкой, по которой программа периодически забирает свежий список. Второй вариант удобен с сервисами, отдающими список по API: обновление идёт без вашего участия.
• Проверка адресов. Встроенный чекер отсеивает мёртвые и медленные прокси до того, как они попадут в работу. Настройте таймаут под ваш источник: слишком жёсткий отсечёт рабочие адреса, слишком мягкий пропустит тормозящие.
• Привязка к задаче. Разные наборы адресов можно раздавать разным парсерам. Это полезно, когда часть источников требует резидентских адресов, а часть обходится серверными: не расходуйте дорогой трафик там, где хватает дешёвого.
• Количество потоков. Выставляйте его не по мощности машины, а по количеству живых адресов в пуле и допустимому темпу на адрес.

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

Ошибки, которые ломают связку

• Потоков больше, чем адресов. Классика: 100 потоков на 10 прокси дают десятикратное превышение темпа на адрес и быстрый бан всего пула.
• Ротация там, где нужна липкая сессия. В ZennoPoster смена IP посреди сценария рвёт куки и авторизацию.
• Липкая сессия там, где нужна ротация. В A-Parser длинная сессия на одном адресе быстро упирается в лимиты источника.
• Нет чекера в A-Parser. Мёртвые адреса в списке съедают потоки на таймаутах, реальная скорость сбора падает в разы при тех же расходах.
• Картинки грузятся зря. В браузерных сценариях это основной перерасход трафика, а платите вы за гигабайты.
• Гео выбрано наугад. Если источник отдаёт региональную выдачу, адрес не того региона даёт формально валидные, но бесполезные данные.
• Годовой тариф до теста. Прогоните свой шаблон на минимальном пакете: реальный расход трафика почти всегда отличается от расчётного.

Что с промокодами

Прокси для автоматизации — расход постоянный и заметный, поэтому скидка на пополнение имеет смысл. Сейчас в нашей базе 44 действующих промокода на 30 сервисов, максимальный размер скидки — 50%. Свежая подборка с разбивкой по размеру — в материале Промокоды на прокси — сентябрь 2026.

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

FAQ

• В: Сколько прокси нужно на 50 потоков в A-Parser?
  Зависит от источника, а не от числа потоков. Разделите желаемую суммарную скорость в запросах в минуту на безопасный темп для источника: 20–60 запросов в минуту на адрес для нетребовательных сайтов и 6–12 для поисковой выдачи и защищённых площадок. Добавьте 20–30% запаса на медленные и отсечённые адреса.
• В: Подойдут ли серверные прокси для ZennoPoster?
  Для сценариев с аккаунтами — нет: диапазоны дата-центров известны площадкам и вызывают повышенное внимание антифрода. Для технических задач без авторизации, например проверки доступности страниц, они вполне годятся и стоят дешевле.
• В: Нужна ли липкая сессия и как её включить?
  Для ZennoPoster — да, на всё время работы шаблона. Обычно она включается либо отдельным портом шлюза, либо параметром сессии в строке логина; конкретный синтаксис зависит от сервиса и описан в его документации. Для A-Parser липкая сессия не нужна.
• В: Как сократить расход трафика в браузерных сценариях?
  Отключите загрузку изображений, шрифтов и медиа в настройках проекта, ограничьте лишние переходы внутри шаблона и не открывайте страницы, данные с которых не используются. На тяжёлых сайтах это даёт кратную экономию.
• В: Можно ли использовать один пул прокси для обеих программ одновременно?
  Технически да, но практически это плохая идея: A-Parser быстро израсходует лимиты адресов, и браузерные сценарии ZennoPoster начнут получать уже помеченные источником IP. Разделяйте пулы по задачам.
• В: Что делать, если после смены прокси сценарий перестал проходить авторизацию?
  Проверьте три вещи по порядку: живёт ли сессия достаточно долго (не включена ли ротация на каждый запрос), совпадает ли гео адреса с остальным отпечатком профиля, не находится ли адрес в чёрных списках. В большинстве случаев причина — первая.

Итог

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