Налаштування проксі-ротації для парсера 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+ проектів з парсингу) ми гарантуємо стабільну роботу парсера навіть при агресивних антиботах. Зв'яжіться з нами для попередньої оцінки вашого завдання. Замовте налаштування парсингу під ключ — ми підготуємо рішення індивідуально.