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

Разработка парсеров для 1С-Битрикс: с чего начать?

XMLReader, а не SimpleXML — выбор инструмента определяет судьбу проекта. SimpleXML загружает весь XML в память, и при файле поставщика на 800 МБ PHP упадёт с fatal error на лимите 512 МБ. XMLReader обрабатывает потоково, node за node, потребляя 20–30 МБ — в 30 раз эффективнее. С этой детали стартует любая разработка парсеров под Битрикс. Мы делаем такие системы уже 10+ лет, и ни один проект не обходится без правильного выбора парсера.

Какие проблемы решает парсинг?

• Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
• Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
• Агрегация поставщиков — пять прайсов в разных форматах (CSV с CP1251, XML в CommerceML, Excel с объединёнными ячейками) превращаются в единый каталог с общей системой свойств инфоблока.
• Обогащение карточек — подтягиваем характеристики, инструкции, 3D-модели с сайтов производителей. Без этого карточка товара — пустышка для SEO.
• Обновление ассортимента — товары, пропавшие из фида поставщика, деактивируются через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Новые — создаются. Каталог синхронизирован.

Какие инструменты используем в разработке парсеров?

Статические сайты — PHP (Goutte, Symfony DomCrawler) или Python (Scrapy, lxml). Скорость: 50–100 страниц/сек. Хватает для каталогов без JS-рендеринга.

SPA и динамические сайты — Puppeteer или Playwright. Бесконечный скролл, AJAX-фильтры, lazy-load картинок — headless-браузер всё это обработает. Скорость падает до 1–10 страниц/сек, но альтернативы нет: данные существуют только после выполнения JavaScript.

Файлы поставщиков:

• Excel (XLS, XLSX) — PhpSpreadsheet. Осторожно с объединёнными ячейками и формулами — они ломают автоматический маппинг.
• CSV — fgetcsv() с правильной кодировкой. Поставщики любят CP1251, BOM в UTF-8 и точку с запятой вместо запятой. Всё это нужно детектить и обрабатывать.
• XML/YML — XMLReader для больших файлов, SimpleXML для фидов до 50 МБ.
• CommerceML — стандартный формат обмена с 1С. Разбираем import.xml и offers.xml, маппим на структуру инфоблоков.

API — REST-эндпоинты поставщиков, API маркетплейсов (Ozon Seller API, Wildberries API). Работаем в рамках rate limits, обрабатываем пагинацию.

Как устроен пайплайн автонаполнения?

Четыре этапа. Каждый может сломаться по-своему.

1. Сбор. Парсер обходит источники по cron-расписанию. Сырые данные пишем в промежуточную таблицу — не сразу в b_iblock_element. Логируем всё: сколько страниц обошли, сколько элементов распарсили, где получили 403 или timeout. Без логов отладка парсера — гадание на кофейной гуще.

2. Нормализация. Здесь основная работа:

   • Очистка HTML-тегов, лишних пробелов, Unicode-мусора
   • Единицы измерения: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Маппинг категорий поставщика → разделы инфоблока Битрикс. У одного поставщика «Ноутбуки», у другого «Ноутбуки и планшеты», у третьего «Laptops» — всё в одну секцию
   • Дедупликация по артикулу, EAN/GTIN. Один товар от трёх поставщиков не должен появиться трижды

3. Загрузка в Битрикс. Через CIBlockElement::Add() для новых элементов, CIBlockElement::Update() для существующих. Изображения: скачиваем, ресайзим через CFile::ResizeImageGet(), конвертируем в WebP. Свойства — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генерируем из транслитерации названия.

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

Почему мониторинг цен конкурентов необходим?

Отдельная подсистема со своей спецификой:

Результат — дашборд: ваш товар vs конкуренты, история цен, тренды. Менеджер видит, где можно поднять цену без потери позиции, а где нужно реагировать.

Модуль импорта CSV/XML: настройка под ваш формат

Для файлов от поставщиков — кастомный модуль с админкой:

• Настраиваемый маппинг: «колонка B в файле → свойство BRAND инфоблока»
• Автодетект кодировки (CP1251, UTF-8, UTF-16) через mb_detect_encoding() с проверкой
• Загрузка изображений по URL с очередью — чтобы не забить канал
• Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
• Cron-расписание, отчёт: создано 145, обновлено 892, ошибок 3 (с деталями)

Большие файлы: CSV обрабатываем батчами по 1000 строк через fgetcsv(), XML потоково через XMLReader, фоновое выполнение через очередь агентов Битрикс — никаких PHP-таймаутов.

Правовая сторона — что важно учесть

• robots.txt — уважаем. Crawl-delay — соблюдаем.
• Частота запросов — 1–2 в секунду, не больше. Не нужно DDoS-ить чужой сайт.
• Контент производителей — используем. Уникальные авторские тексты — не копируем.
• Персональные данные — не собираем.

Что входит в разработку парсера под ключ?

Как мы работаем и сроки

1. Прототип — парсер для 1–2 источников за 2–3 дня. Оцениваем качество данных, подводные камни (защита Cloudflare, капча, динамическая подгрузка).
2. Разработка — полный пайплайн: парсер → нормализация → импорт в Битрикс → админка для управления.
3. Тестирование — прогоняем на полном объёме каталога, проверяем edge-кейсы (пустые поля, кривой HTML, битые картинки).
4. Запуск — настраиваем cron, мониторинг ошибок через Telegram-бот.
5. Поддержка — конкурент переделал вёрстку? Обновляем CSS-селекторы в парсере.

Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.