Классическая ошибка при масштабировании парсера — покупка прокси "на глаз": взяли 100 IP, запустили парсер, получили баны через полчаса. Проблема не в количестве адресов, а в том, что никто не считает реальную нагрузку на каждый IP. Разберём формулу расчёта пула прокси, основанную на RPS (requests per second), задержках и лимитах целевого сайта — с конкретными цифрами и кодом на Python.
Почему считать пул по количеству IP — ошибка
Типичный подход новичка в парсинге: "нужно собрать 50 000 карточек товаров, значит купим 500 прокси и раскидаем нагрузку". Логика кажется здравой, но не учитывает главного — сайты вроде Wildberries и Ozon банят не по абсолютному числу запросов, а по интенсивности запросов с одного IP в единицу времени. То есть 500 прокси, каждый из которых стреляет по 20 запросов в секунду, забанятся мгновенно — антибот-системы видят паттерн, похожий на DDoS.
С другой стороны, если у вас 50 прокси, но каждый делает 1 запрос в 5-10 секунд с рандомными паузами, имитируя поведение человека, вы можете парсить стабильно неделями без единого бана. Количество IP — это не причина стабильности, а следствие правильно посчитанной нагрузки. Именно поэтому формула должна отталкиваться не от "сколько IP купить", а от "сколько RPS нужно достичь и какая безопасная нагрузка на один IP".
Ещё один нюанс: разные типы прокси имеют разный "запас прочности" на один IP. Датацентровые прокси банятся быстрее при высокой частоте запросов, потому что их подсети легко распознаются как хостинговые. Резидентные и мобильные IP выглядят как обычные пользователи, и им можно позволить чуть более высокую частоту без риска блокировки — но это не значит, что можно игнорировать лимиты вовсе.
Базовая формула расчёта пула прокси
Формула расчёта количества прокси в пуле выглядит так:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Где:
- N — необходимое количество прокси в пуле;
- RPS_target — целевая скорость парсинга (запросов в секунду по всей системе);
- Delay_per_ip — минимальная безопасная пауза между запросами с одного IP (в секундах);
- Concurrency_per_ip — сколько параллельных потоков вы допускаете на один IP (обычно 1, максимум 2 для резидентных прокси).
Логика простая: если вы хотите держать 10 запросов в секунду в сумме, а безопасная пауза между запросами с одного IP — 8 секунд, то один IP физически может выдать только 1 запрос за 8 секунд, то есть 0.125 RPS. Чтобы получить 10 RPS суммарно, нужно 10 / 0.125 = 80 прокси. Это и есть тот самый расчёт, который заменяет угадывание "500 IP на всякий случай".
Как посчитать целевой RPS для парсинга
Перед расчётом пула нужно определить RPS_target — сколько запросов в секунду вам реально нужно, чтобы собрать данные в разумный срок. Формула здесь обратная:
RPS_target = Total_requests / Time_budget_seconds
Пример: нужно собрать 100 000 карточек товаров с Wildberries за 8 часов (28 800 секунд). Если на каждую карточку уходит 1 запрос, RPS_target = 100 000 / 28 800 ≈ 3.47 запроса в секунду. Это не так много, как кажется на первый взгляд — многие переоценивают нужную скорость и покупают избыточное количество прокси.
Если задача включает несколько типов запросов (например, сначала получить список категорий, затем карточки, затем отзывы), считайте RPS для каждого этапа отдельно — они могут идти параллельно с разными пулами прокси, и суммарная нагрузка на площадку будет распределена по разным эндпоинтам.
Лимиты на один IP: сколько запросов в минуту безопасно
Delay_per_ip — самый важный параметр в формуле, и его нужно определять эмпирически для каждого сайта. Общие ориентиры, основанные на практике парсинга маркетплейсов:
| Площадка | Безопасная пауза между запросами с 1 IP | Максимум запросов/мин с 1 IP |
|---|---|---|
| Wildberries (API карточек) | 4-6 сек | 10-15 |
| Ozon (страницы товаров) | 5-8 сек | 8-12 |
| Авито (объявления) | 6-10 сек | 6-10 |
| Яндекс.Маркет | 5-7 сек | 8-12 |
Эти цифры — стартовая точка, не догма. Начинайте с консервативных значений (верхняя граница паузы), мониторьте процент ошибок 429 и 403, и постепенно уменьшайте паузу, если баны не растут. Резкое увеление RPS без постепенного тестирования — самый частый способ спалить весь пул прокси за один день.
Практические расчёты: Wildberries, Ozon, Авито
Разберём три реальных сценария с полным расчётом по формуле.
Сценарий 1: мониторинг цен на Wildberries. Нужно обновлять цены 20 000 товаров каждые 2 часа. RPS_target = 20 000 / (2 × 3600) ≈ 2.78 RPS. При паузе 5 сек на 1 IP и Concurrency = 1: N = (2.78 × 5) / 1 ≈ 14 прокси. Для запаса на случай бана части IP рекомендуется брать пул с коэффициентом 1.5-2x, то есть 21-28 прокси.
Сценарий 2: разовый сбор каталога Ozon. 500 000 карточек за 24 часа. RPS_target = 500 000 / 86 400 ≈ 5.79 RPS. При паузе 6 сек: N = (5.79 × 6) / 1 ≈ 35 прокси. С запасом — 50-60 прокси.
Сценарий 3: мониторинг конкурентов на Авито в реальном времени. 5000 объявлений, обновление каждые 15 минут. RPS_target = 5000 / 900 ≈ 5.56 RPS. При паузе 8 сек: N = (5.56 × 8) / 1 ≈ 45 прокси. Здесь важно учитывать, что Авито активно палит датацентровые подсети, поэтому для такой задачи разумнее сразу закладывать резидентные или мобильные IP.
Резидентные, мобильные и датацентровые прокси в формуле
Тип прокси напрямую влияет на Delay_per_ip и, соответственно, на итоговое N в формуле. Датацентровые прокси дешевле и быстрее, но требуют более длинных пауз между запросами и чаще банятся при повышенной частоте — фактически, для тех же 5 RPS вам может понадобиться в 2-3 раза больше датацентровых IP, чем резидентных.
| Тип прокси | Средний Delay_per_ip | Когда использовать |
|---|---|---|
| Прокси дата-центров | 8-15 сек | Открытые API, сайты без строгого антибота |
| Резидентные прокси | 4-8 сек | Wildberries, Ozon, Авито и другие маркетплейсы с антиботом |
| Мобильные прокси | 3-6 сек | Самые агрессивные защиты, соцсети, мобильные API |
Для парсинга маркетплейсов вроде Wildberries и Ozon оптимальным выбором обычно становятся резидентные прокси — они балансируют цену и стабильность, позволяя держать более короткие паузы без резкого роста банов. Датацентровые прокси стоит рассматривать только для площадок без агрессивного антибота или для разовых задач с невысоким RPS.
Реализация пула на Python: код с ротацией
Ниже — упрощённая реализация пула прокси с контролем частоты запросов на каждый IP. Логика: каждый прокси хранит время последнего использования, и планировщик выбирает только те IP, у которых прошло достаточно времени с последнего запроса.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # безопасная пауза в секундах
last_used: float = field(default=0.0)
class ProxyPool:
def __init__(self, proxies: List[str], delay_per_ip: float):
self.nodes = [ProxyNode(address=p, delay_per_ip=delay_per_ip) for p in proxies]
def get_available_proxy(self) -> Optional[ProxyNode]:
now = time.time()
available = [
node for node in self.nodes
if now - node.last_used >= node.delay_per_ip
]
if not available:
return None
# выбираем случайный из доступных, чтобы избежать паттерна очереди
node = random.choice(available)
node.last_used = now
return node
def size(self) -> int:
return len(self.nodes)
def calculate_pool_size(rps_target: float, delay_per_ip: float, concurrency: int = 1) -> int:
"""Формула: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Пример использования
rps_target = 5.79 # рассчитано из объёма задачи и времени
delay_per_ip = 6.0 # безопасная пауза для Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Нужно прокси в пуле: {n_proxies}") # ~35, с запасом 50-60
В реальном парсере эту логику нужно дополнить очередью задач (например, через asyncio или multiprocessing), чтобы воркеры ждали появления свободного прокси, а не завершались с ошибкой при их отсутствии. Также стоит добавить экспоненциальный backoff при получении 429/403 — это автоматически увеличит паузу для конкретного IP при признаках блокировки.
Мониторинг и динамическая коррекция пула
Статический расчёт по формуле — это отправная точка, а не финальное решение. В реальной эксплуатации нужно отслеживать три ключевые метрики:
- Success rate — процент успешных запросов (код 200) от общего числа. Падение ниже 90-95% сигнализирует о том, что Delay_per_ip нужно увеличить или добавить прокси в пул;
- Ban rate — доля прокси, показавших признаки блокировки (капча, 403, редирект на форму верификации) за последний час;
- Real RPS — фактическая скорость обработки запросов, которая может отличаться от расчётной из-за таймаутов и повторных попыток.
Практическое правило: если ban rate превышает 5-7% в час, увеличивайте Delay_per_ip на 20-30% и пересчитывайте N по формуле заново. Если success rate стабильно выше 98% на протяжении нескольких часов, можно постепенно уменьшать паузу и снижать размер пула — это прямая экономия бюджета на прокси без потери стабильности.
Хорошая практика — вести лог по каждому IP отдельно: время последнего успешного запроса, количество последовательных ошибок, среднее время ответа. Это позволяет автоматически исключать "подпорченные" прокси из ротации на 30-60 минут вместо того, чтобы продолжать слать через них запросы и получать капчу на каждом шаге.
Частые ошибки при расчёте пула прокси
Даже зная формулу, легко ошибиться в деталях расчёта. Вот список типичных промахов:
- Игнорирование запаса на баны. Даже при идеальном расчёте 5-10% прокси будут временно недоступны из-за блокировок или сетевых проблем. Всегда добавляйте коэффициент 1.3-2x к базовому N;
- Одинаковый Delay_per_ip для всех эндпоинтов. Страница категории и страница карточки товара могут иметь разные лимиты — считайте отдельно;
- Concurrency больше 1 без тестирования. Параллельные запросы с одного IP резко повышают риск бана, особенно на резидентных прокси — начинайте с Concurrency = 1;
- Отсутствие ротации User-Agent и заголовков. Даже правильно рассчитанный пул прокси не спасёт, если все запросы идут с одинаковым отпечатком браузера;
- Фиксированная пауза без джиттера. Строго одинаковый интервал между запросами (например, ровно 5.0 сек) — это паттерн, легко распознаваемый антиботом. Добавляйте случайное отклонение ±20-30%.
Заключение
Формула N = (RPS_target × Delay_per_ip) / Concurrency_per_ip превращает расчёт пула прокси из гадания в инженерную задачу с конкретными цифрами. Сначала определите целевую скорость парсинга исходя из объёма данных и времени, затем эмпирически найдите безопасную паузу для конкретной площадки, и только после этого считайте необходимое количество IP — с запасом 30-100% на баны и сбои.
Такой подход экономит бюджет: вместо покупки избыточного количества IP "на всякий случай" вы платите ровно за тот объём прокси, который нужен для достижения целевого RPS без риска блокировок. Для парсинга маркетплейсов и других защищённых сайтов рекомендуем начинать с резидентных прокси — они дают наилучший баланс между стабильностью и стоимостью при работе с антибот-системами Wildberries, Ozon и Авито.