Прокси в A-Parser: проксичекеры, потоки и настройки парсеров для SEO-задач

В A-Parser прокси подключаются через проксичекер: вы создаёте чекер, кладёте список в его файл proxy.txt (или указываете ссылки на источники), чекер проверяет адреса, а затем вы выбираете его в пресете настроек потоков, с которым работает задание. Опция Use proxy у всех парсеров включена по умолчанию, поэтому, как только к заданию привязан рабочий чекер, запросы идут через ваши прокси.

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

Что делает A-Parser и зачем ему прокси

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

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

Как прокси проходят через A-Parser

Настройки разнесены по четырём уровням, и понимание их порядка экономит много времени:

1. Проксичекер — загружает список, проверяет его и оставляет только живые адреса.
2. Пресет настроек потоков — задаёт число потоков задания и чекеры, из которых оно берёт прокси.
3. Задание — использует один пресет потоков и один или несколько парсеров.
4. Настройки парсера — позволяют отключить прокси, поменять время бана и число повторов или направить отдельный парсер на другой чекер.

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

Шаг 1. Подготовьте список прокси

A-Parser читает одну прокси на строку. Поддерживаемые варианты записи:

203.0.113.21:8080
198.51.100.40:1080
seo-user:k8Lq2v@203.0.113.22:8080

• ip:port — для прокси с авторизацией по IP (в белый список добавляйте адрес сервера, где запущен A-Parser, а не своего ноутбука).
• login:password@ip:port — у каждой прокси свои логин и пароль; в чекере нужно включить Use proxy authorization.
• Список ip:port с общими логином и паролем — включите Use proxy authorization и один раз заполните Authorization login и Authorization password.

Префикс протокола не нужен: при значении Proxies type по умолчанию (HTTP, SOCKS5) чекер сначала пробует HTTP, а при неудаче — SOCKS5. Если провайдер выдаёт оба варианта, подойдёт любой; разницу между ними мы разбирали в сравнении SOCKS5 и HTTP.

Шаг 2. Создайте проксичекер

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

Файлы пользовательского чекера лежат в files/proxy/<имя чекера>/:

• proxy.txt — ваш список; если используете ссылки на источники, оставьте его пустым;
• sites.txt — адреса списков прокси, по одному на строку (удобно, если провайдер отдаёт список по ссылке);
• regex.txt — шаблоны для извлечения прокси со страницы произвольного вида: первая группа — IP, вторая — порт;
• alive.txt — живые прокси, которые чекер записывает при включённой опции Save alive proxies to file.

Шаг 3. Какие опции чекера стоит поменять

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

Шаг 4. Пресет настроек потоков

Перейдите в Настройки → Настройки потоков, выберите пресет или создайте новый и посмотрите на поля:

• Threads count — сколько запросов задание выполняет параллельно; во встроенных пресетах 20 и 100.
• Proxy Checkers (Проксичекеры) — из каких чекеров задание берёт прокси; по умолчанию All.
• Max threads per proxy — сколько потоков могут одновременно работать через одну прокси; 0 снимает ограничение.
• Max connections per host — ограничивает одновременные соединения с одним сайтом и бережёт небольшие ресурсы.
• Global proxy ban — задания с этой опцией ведут общий список забаненных прокси для каждого парсера.
• Reuse proxy between retries — разрешает одной прокси обслуживать все повторы запроса, без смены.
• Proxy strategy — оставлять прокси, на которой запрос прошёл успешно, для следующего запроса или каждый раз брать случайную.

Сохраните пресет и выберите его в редакторе заданий.

Шаг 5. Настройки на уровне парсера

У каждого парсера есть общий набор опций, которые можно переопределить в задании:

• Use proxy — включена по умолчанию; выключайте только там, где прокси не нужны (например, при локальной обработке текста).
• Proxy ban time — сколько секунд прокси отдыхает после отказа цели; значение по умолчанию у парсеров разное.
• Request retries — по умолчанию 10; запрос, который не прошёл и после этого, пропускается.
• Request delay — по умолчанию 0; диапазон вида 5,15 добавляет случайную паузу в секундах.
• Request timeout — по умолчанию 60 секунд.
• Proxy Checker — выбор чекера для конкретного парсера, важнее настройки задания.

Сколько потоков выдержит пул

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

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

Ротируемый шлюз или список статических IP

• Ротируемый резидентский шлюз. Одна строка в proxy.txt (или несколько портов) даёт новый выход на каждое подключение. Подходит для сбора выдачи в больших объёмах. Время бана держите коротким: бан строки шлюза выключает сразу все его выходы. Обычный выбор здесь — резидентские прокси с ротацией.
• Список статических IP. Каждая строка — отдельный адрес, и чекер, баны и Max threads per proxy работают так, как задумано. Этот вариант хорош для спокойного съёма позиций и проверок, где нужна стабильная страна. Для такой схемы подойдут наши статические прокси.

Частые ошибки

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

Все прокси с логином отваливаются. Проверьте, что включена Use proxy authorization, а список записан как login:password@ip:port. Для прокси с авторизацией по IP добавьте в белый список внешний адрес машины, где работает A-Parser.

Проверку прокси проходят, а поисковик отдаёт ошибки. Проверка подтверждает только связность. Снизьте число потоков, добавьте Request delay или перейдите на резидентские адреса.

Шлюз выпадает из ротации. Его забанили после нескольких отказов. Сократите Proxy ban time или включите Reuse proxy between retries для этого парсера.

Через час работы падает скорость. Пул слишком мал для такого числа потоков. Сначала уменьшите потоки, потом добавьте IP.