Лимит трафика на парсинг Wildberries и Ozon: как не слить месячный пакет прокси за ночь

Селлер запускает парсер цен конкурентов на ночь, а утром получает уведомление: трафик закончился, пакет исчерпан на 90%. Знакомая ситуация? Чаще всего виноват не парсер сам по себе, а отсутствие лимитов на уровне прокси и скрипта. В этой статье разберём, как именно трафик «утекает» впустую, и как поставить защиту, чтобы месячный пакет резидентных или мобильных прокси хватал до конца расчётного периода.

Почему трафик заканчивается за ночь

Парсинг Wildberries, Ozon или Авито выглядит как простая задача: отправил запрос — получил JSON с ценой. Но на практике трафик расходуется не только на полезные данные. Основные источники перерасхода:

• Загрузка изображений и медиа. Если парсер открывает страницу товара целиком через браузер (а не делает прямой запрос к API), он автоматически подгружает картинки, видео, баннеры — это десятки мегабайт на одну карточку.
• Повторные запросы из-за капчи и блокировок. Маркетплейс распознаёт бота, выдаёт капчу или временный бан IP, скрипт делает повторный запрос — трафик тратится впустую, а данные не приходят.
• Отсутствие кэширования запросов. Без логики «уже спарсено за этот час — не повторять» скрипт может опрашивать одни и те же карточки по несколько раз за ночь.
• Параллельные потоки без ограничения. Запуск 50-100 потоков одновременно кажется ускорением работы, но при этом трафик расходуется в разы быстрее, чем планировалось, а часть запросов просто блокируется.
• Неправильный выбор типа прокси. Резидентные и мобильные прокси обычно тарифицируются по объёму трафика (ГБ), в отличие от прокси дата-центров, где чаще оплата идёт за количество IP или время аренды. Если парсер настроен на резидентный пул без контроля — лимит сгорает быстро.

Комбинация этих факторов приводит к тому, что скрипт, рассчитанный на месяц работы, расходует пакет трафика за одну ночную сессию парсинга 10-20 тысяч карточек товаров.

Как считается трафик у разных типов прокси

Прежде чем ставить лимиты, важно понять, за что именно вы платите. Разные типы прокси по-разному учитывают расход, и это напрямую влияет на стратегию экономии.

Тип прокси	Тарификация	Риск перерасхода	Когда применять
Резидентные прокси	По объёму трафика (ГБ)	Высокий без лимитов	Парсинг с обходом антибот-защиты маркетплейсов
Мобильные прокси	По объёму трафика или по времени	Высокий, трафик дороже	Парсинг мобильных версий сайтов, обход жёстких блокировок
Прокси дата-центров	По количеству IP / времени аренды	Низкий, трафик обычно безлимитный	Массовый парсинг без строгой антибот-защиты

Если вы парсите Wildberries или Ozon, где активно работает защита от ботов, резидентные или мобильные IP почти всегда необходимы — датацентровые адреса блокируются быстро. Но именно из-за тарификации по трафику здесь особенно важно поставить лимиты заранее.

Сколько трафика реально нужно на парсинг

Чтобы поставить адекватный лимит, нужно отталкиваться от реальных цифр, а не от ощущений. Примерные расходы на практике:

• Запрос к API карточки товара (JSON, без картинок): 5-30 КБ на карточку. На 10 000 карточек — около 50-300 МБ.
• Загрузка страницы товара через headless-браузер с картинками: 1-3 МБ на карточку. На те же 10 000 карточек — 10-30 ГБ.
• Мониторинг цен раз в час по 1000 SKU: при облегчённых запросах — порядка 1-5 ГБ в сутки, при полной загрузке страниц — 50-100 ГБ в сутки.

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

Лимиты в антидетект-браузерах и прокси-менеджерах

Для тех, кто парсит через антидетект-браузер (например, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) или собственный прокси-менеджер, самый простой способ ограничить расход — настроить лимиты на уровне профиля и аккаунта прокси-провайдера.

1. Зайдите в личный кабинет прокси-провайдера и найдите раздел управления трафиком или лимитами по суб-пользователям/портам.
2. Создайте отдельный суб-аккаунт или порт для парсинга — не используйте тот же пул прокси, что и для фарма аккаунтов в Instagram или TikTok. Разделение по задачам сразу показывает, куда уходит трафик.
3. Установите дневной или часовой лимит трафика на этом суб-аккаунте — например, 5 ГБ в сутки вместо расходования всего месячного пакета за одну сессию.
4. В антидетект-браузере отключите автозагрузку изображений для профилей, которые используются исключительно для сбора данных, а не для визуального просмотра страниц.
5. Настройте расписание запуска профилей так, чтобы парсинг шёл не одной длинной сессией, а короткими интервалами с паузами — это снижает риск блокировки и даёт время отследить расход трафика между запусками.

Такой подход особенно важен для агентств и фрилансеров, которые ведут парсинг нескольких маркетплейсов одновременно: без разделения по суб-аккаунтам сложно понять, какой именно проект «съел» трафик.

Ограничение трафика на уровне скрипта и API

Если парсер написан самостоятельно на Python или Node.js, лимиты можно и нужно встроить прямо в код — это даёт более точный контроль, чем настройки интерфейса прокси-провайдера.

Пример простого счётчика трафика на Python с использованием requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # лимит 5 ГБ в сутки
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("Суточный лимит трафика исчерпан, парсинг остановлен")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# пример вызова
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Использовано трафика:", round(used_bytes / 1024 / 1024, 2), "МБ")

Логика простая: скрипт считает объём каждого ответа в байтах и останавливается, как только достигнут заданный лимит. Это защищает от ситуации, когда из-за ошибки в цикле или бесконечного повтора запросов скрипт «съедает» месячный пакет трафика за несколько часов.

Дополнительно стоит добавить:

• Экспоненциальную задержку при ошибках (retry с backoff) — вместо мгновенного повтора запроса при капче или бане, скрипт ждёт нарастающий интервал (5 сек, 15 сек, 60 сек), что снижает число бесполезных запросов.
• Ограничение числа параллельных потоков — например, не более 10-20 одновременных соединений через пул прокси, чтобы не провоцировать блокировки и не расходовать трафик впустую.
• Отключение загрузки ресурсов в headless-браузере — если парсинг идёт через Selenium или Puppeteer, в настройках браузера можно заблокировать загрузку картинок, шрифтов и CSS, оставив только HTML/JSON-ответы.

Мониторинг расхода в реальном времени

Лимит без мониторинга работает хуже, потому что вы узнаёте о проблеме только после остановки скрипта. Чтобы контролировать расход на лету:

• Включите уведомления в личном кабинете прокси-провайдера о достижении 50%, 80% и 100% месячного пакета трафика — большинство сервисов поддерживают такие алерты по email или в Telegram.
• Ведите простой лог в самом скрипте: записывайте в файл или базу данных объём трафика по часам, чтобы видеть пики расхода и быстро находить источник проблемы.
• Разделяйте трафик по задачам через отдельные суб-аккаунты или метки — отдельно для парсинга Wildberries, отдельно для Ozon, отдельно для Авито. Это упрощает анализ, какой проект расходует больше всего.
• Сверяйте расход с ожидаемым объёмом данных: если на 10 000 карточек ушло 20 ГБ вместо расчётных 300 МБ, значит где-то подгружаются лишние ресурсы или идут повторные запросы.

Чек-лист контроля бюджета трафика

Частые ошибки новичков

На практике большинство «сгоревших» пакетов трафика объясняются несколькими типовыми ошибками:

• Запуск парсинга «на ночь без присмотра» без лимитов. Скрипт работает 8-10 часов без остановки, и если где-то возникает цикл повторных запросов, трафик расходуется непрерывно до утра.
• Один общий пул прокси на все задачи. Фарм аккаунтов в Instagram, тестирование рекламы в Facebook Ads и парсинг Ozon используют один и тот же трафик — невозможно понять, что именно его расходует.
• Игнорирование капчи. Вместо того чтобы снизить частоту запросов при первых признаках капчи, скрипт продолжает долбить сайт с той же интенсивностью, тратя трафик на бесполезные ответы с кодом ошибки.
• Выбор резидентных прокси там, где достаточно дата-центровых. Если маркетплейс не блокирует датацентровые IP жёстко, переплата за трафик резидентного пула не оправдана — для менее защищённых целей подойдут прокси дата-центров с другой моделью тарификации.
• Отсутствие тестового прогона. Перед запуском полного парсинга на тысячи карточек стоит прогнать скрипт на 50-100 карточках и замерить реальный расход трафика, чтобы экстраполировать на весь объём.

Заключение

Трафик на парсинг «сгорает» не из-за объёма данных, а из-за отсутствия контроля: лишние картинки, повторные запросы при блокировках, параллельные потоки без ограничений и общий пул прокси на все задачи. Решение — разделить трафик по проектам, поставить дневные лимиты на уровне прокси-аккаунта, встроить счётчик расхода в сам скрипт и настроить мониторинг с уведомлениями до момента, когда пакет действительно закончится.

Если вы парсите маркетплейсы с активной защитой от ботов вроде Wildberries или Ozon, рекомендуем использовать резидентные прокси для обхода блокировок и дополнительно мобильные IP для самых чувствительных к антибот-защите сценариев — но в обоих случаях обязательно ставьте лимиты трафика заранее, чтобы месячный пакет не ушёл за одну ночную сессию.