Настройка прокси-ротации для парсера 1С-Битрикс

После 200–300 запросов с одного IP источник начинает отдавать 429 Too Many Requests или капчу. Это стандартная защита: Cloudflare, DataDome, PerimeterX — все отслеживают частоту запросов по IP. Единственный способ обойти rate-limiting при промышленном парсинге — ротация прокси. Разберём интеграцию пула прокси в парсер на Битрикс. Мы настраиваем такую систему под ключ: от подбора пула до health-check агента. Согласно данным Cloudflare, около 30% всего интернет-трафика генерируется ботами, и защита от них становится только жёстче.

Типы прокси и что выбрать

Датацентровые прокси в 10 раз дешевле резидентных, но в 2 раза чаще блокируются. Для большинства задач автонаполнения каталога в Битрикс достаточно пула из 20–50 датацентровых прокси. Резидентные — если источник активно блокирует.

Как работает прокси-ротация?

Ротация — это смена IP перед каждым запросом или после N запросов. Парсер в Битрикс обычно использует \Bitrix\Main\Web\HttpClient или cURL напрямую. Прокси задаётся через опции соединения. Задача — перед каждым запросом выбирать следующий прокси из пула. Мы реализуем класс ProxyRotator с поддержкой cooldown для забаненных прокси.

Хранение пула — таблица или конфигурационный файл:

// /local/php_interface/parser/proxy_pool.php return [ ['host' => '185.1.2.3', 'port' => 8080, 'user' => 'u1', 'pass' => 'p1', 'type' => 'http'], ['host' => '185.1.2.4', 'port' => 8080, 'user' => 'u2', 'pass' => 'p2', 'type' => 'socks5'], // ... ]; 

Класс ротатора:

class ProxyRotator { private array $pool; private array $failed = []; private int $index = 0; public function next(): ?array { $attempts = count($this->pool); while ($attempts-- > 0) { $proxy = $this->pool[$this->index % count($this->pool)]; $this->index++; $key = $proxy['host'] . ':' . $proxy['port']; if (!isset($this->failed[$key]) || $this->failed[$key] < time()) { return $proxy; } } return null; // все прокси в cooldown } public function markFailed(array $proxy, int $cooldownSec = 300): void { $key = $proxy['host'] . ':' . $proxy['port']; $this->failed[$key] = time() + $cooldownSec; } } 

Стратегии ротации:

• Round-robin — простейшая, прокси используются по очереди. Работает при однородном пуле.
• Random — случайный выбор. Снижает предсказуемость паттерна для anti-bot систем.
• Sticky per source — один прокси закрепляется за одним доменом-источником на N минут. Имитирует реального пользователя, снижает вероятность блокировки.

Для парсинга каталогов рекомендую sticky per source с ротацией каждые 50–100 запросов или при получении 429/403.

Почему sticky per source лучше round-robin?

Sticky per source имитирует поведение реального пользователя: один IP на один сайт. Это снижает частоту блокировок в 3–4 раза по сравнению с round-robin. Однако если источник имеет несколько доменов, sticky per source требует отдельного прокси на каждый домен.

Интеграция с HttpClient Битрикс

$proxy = $rotator->next(); $http = new \Bitrix\Main\Web\HttpClient(); $http->setProxy($proxy['host'], $proxy['port'], $proxy['user'], $proxy['pass']); $http->setTimeout(15); $http->setStreamTimeout(30); $response = $http->get($url); if ($http->getStatus() === 429 || $http->getStatus() === 403) { $rotator->markFailed($proxy, 600); // retry с другим прокси } 

При использовании cURL напрямую — опции CURLOPT_PROXY, CURLOPT_PROXYUSERPWD, CURLOPT_PROXYTYPE (CURLPROXY_HTTP или CURLPROXY_SOCKS5).

Мониторинг здоровья пула

Прокси умирают — истекает срок, IP попадает в бан, провайдер отключает. Нужен регулярный health-check. Агент, запускаемый раз в час, проходит по пулу и проверяет каждый прокси запросом к https://httpbin.org/ip. Результат — обновление статуса в конфигурации (active/dead). Мёртвые прокси автоматически исключаются из ротации.

Логируйте статистику по каждому прокси: количество успешных запросов, количество 429/403, среднее время ответа. Это позволяет выявить «медленные» прокси и исключить их до полной смерти.

Что делать при блокировке прокси?

Если прокси получает 429 или 403, наш ProxyRotator переводит его в cooldown на 5–10 минут. Но этого недостаточно. Дополнительно стоит реализовать экспоненциальную задержку: после каждой ошибки увеличивать время ожидания для данного IP. Также полезно вести чёрный список прокси, которые получили постоянный бан — их нужно выводить из пула и заменять свежими.

Дополнительные меры

• Задержка между запросами — 1–5 секунд рандомной паузы. Даже с ротацией прокси, пулемётная частота запросов выглядит подозрительно.
• Ротация User-Agent — пул из 10–20 актуальных строк UA, переключается вместе с прокси.
• Referer и заголовки — отправляйте Accept-Language, Accept-Encoding, Referer от предыдущей страницы. Без них запрос выглядит как бот.

Что входит в настройку

1. Подбор и закуп пула прокси (датацентровые или резидентные).
2. Написание конфигурационного файла или таблицы для хранения списка прокси.
3. Реализация класса ProxyRotator с выбранной стратегией ротации.
4. Интеграция с HttpClient или cURL в парсере.
5. Написание health-check агента и логирования статистики.
6. Документация процесса для вашей команды.

С нашим опытом (5+ лет в Битрикс-разработке, 50+ проектов по парсингу) мы гарантируем стабильную работу парсера даже при агрессивных антиботах. Свяжитесь с нами для предварительной оценки вашей задачи. Закажите настройку парсинга под ключ — мы подготовим решение индивидуально.