Сколько прокси нужно для скрапинга? | ProxyHat

Почему количество прокси важно для веб-скрапинга

Один из первых вопросов любого проекта по скрапингу обманчиво прост: сколько прокси мне на самом деле нужно? Используете слишком мало — ваши IP-адреса заблокируют за считанные минуты. Используете слишком много — тратите бюджет на мощности, которые никогда не задействуете. Правильное количество зависит от целевых сайтов, объёма запросов, стратегии ротации и допустимого уровня блокировок.

Это руководство предоставляет практическую методику расчёта, чтобы вы могли точно определить размер пула прокси — будь то десять страниц в день или десять миллионов.

Если вы новичок в прокси для скрапинга, начните с нашего Полного руководства по прокси для веб-скрапинга для изучения базовых концепций.

Основная формула

В простейшем виде количество одновременных IP, которое вам нужно:

required_ips = (requests_per_minute) / (safe_rpm_per_ip)

Где safe_rpm_per_ip — максимальная частота запросов, которую один IP может выдержать на целевом сайте без срабатывания блокировок. Это значение сильно варьируется в зависимости от цели:

Тип цели	Безопасный RPM на IP	Примечания
Небольшие блоги / статические сайты	20-60	Минимальная защита от ботов
Интернет-магазины (Shopify, WooCommerce)	5-15	Умеренное ограничение частоты
Крупные платформы (Amazon, Google)	1-5	Агрессивное обнаружение
Социальные сети (LinkedIn, Instagram)	0.5-2	Очень строгий контроль

Пример расчёта

Допустим, вам нужно собрать 50 000 страниц товаров с интернет-магазина за день, выполнив задачу в 8-часовое окно:

# Target: 50,000 pages in 8 hours
requests_per_minute = 50000 / (8 * 60)  # ≈ 104 RPM
safe_rpm_per_ip = 10                     # e-commerce average
required_ips = 104 / 10  # ≈ 11 concurrent IPs

На практике следует добавить запас 30-50% на повторные попытки, ошибки и паузы при срабатывании лимитов. Реалистичная потребность — около 15-17 одновременных IP.

Факторы, влияющие на требования к прокси

1. Уровень защиты целевого сайта

Сайты с продвинутыми системами защиты от ботов требуют больше IP, потому что каждый адрес может отправить меньше запросов до обнаружения. Google, Amazon и крупные социальные платформы активно инвестируют в фингерпринтинг и поведенческий анализ. Закладывайте в бюджет в 3-5 раз больше IP, чем предполагает базовая формула.

2. Объём и частота запросов

Непрерывный скрапинг (мониторинг 24/7) требует больше IP, чем пакетные задания. Если вы запускаете ежедневный пакет, можно агрессивно ротировать пул во время рабочего окна, а затем дать IP-адресам «остыть». При мониторинге в реальном времени каждый IP остаётся активным дольше, увеличивая общие требования.

3. Географическое распределение

Если нужны данные из нескольких регионов (локализованные цены, гео-специфичная выдача), вам нужны IP в каждой целевой географии. Проект, собирающий цены в 10 странах, может потребовать 15 IP на страну — итого 150. Проверьте доступные локации ProxyHat для планирования гео-распределения.

4. Требования к сессиям vs ротация

Некоторые задачи (авторизация, анализ многостраничного оформления заказа) требуют липких сессий, где один и тот же IP сохраняется в течение нескольких минут. Это блокирует IP на более длительное время, снижая эффективную утилизацию пула. Чистый сбор данных без состояния сессии позволяет ротировать на каждом запросе, используя каждый IP эффективнее.

5. Резидентные vs датацентр-прокси

Резидентные IP имеют более высокий уровень доверия и могут выполнить больше запросов до блокировки, поэтому их может потребоваться меньше. Но они дороже за ГБ. IP датацентров дешевле, но обнаруживаются быстрее, поэтому нужен больший пул. Подробное сравнение — в статье Резидентные vs датацентр vs мобильные прокси.

Таблицы размеров по сценариям использования

Сценарий использования	Запросов в день	Рекомендуемое кол-во IP	Тип прокси
Малый SEO-аудит (1 сайт)	1 000-5 000	5-10	Резидентные
Мониторинг цен на товары	10 000-50 000	15-30	Резидентные
Отслеживание SERP (100 ключевых слов)	5 000-20 000	10-25	Резидентные
Скрапинг каталога интернет-магазина	50 000-200 000	30-80	Резидентные
Крупномасштабная агрегация данных	500 000+	100-500+	Резидентные ротируемые

Расчёт общей пропускной способности

Количество прокси — одно измерение; пропускная способность — другое. Оцените общий объём передаваемых данных:

# Average page sizes
static_page = 50 KB      # HTML only
dynamic_page = 200 KB    # HTML + JSON/API responses
full_render = 2-5 MB     # with all assets (headless browser)
# Example: 50,000 pages/day × 200 KB average
daily_bandwidth = 50000 * 200 / 1024 / 1024  # ≈ 9.5 GB/day

Это поможет выбрать подходящий тариф ProxyHat с учётом потребностей как в количестве IP, так и в пропускной способности.

Реализация: динамическое определение размера пула

Вместо статических предположений реализуйте динамическое определение размера пула, которое адаптируется к реальным условиям. Вот пример с использованием шлюза ProxyHat с адаптивной конкурентностью:

Пример на Python

import asyncio
import aiohttp
from dataclasses import dataclass, field
from time import time
@dataclass
class PoolSizer:
    """Dynamically adjusts concurrent proxy connections based on success rate."""
    min_concurrent: int = 5
    max_concurrent: int = 100
    target_success_rate: float = 0.95
    current_concurrent: int = 10
    results: list = field(default_factory=list)
    def record(self, success: bool):
        self.results.append((time(), success))
        # Keep only last 100 results
        self.results = self.results[-100:]
    @property
    def success_rate(self) -> float:
        if not self.results:
            return 1.0
        return sum(1 for _, s in self.results if s) / len(self.results)
    def adjust(self):
        rate = self.success_rate
        if rate >= self.target_success_rate and self.current_concurrent < self.max_concurrent:
            # Success rate is good — try more concurrency
            self.current_concurrent = min(self.current_concurrent + 2, self.max_concurrent)
        elif rate < self.target_success_rate * 0.9:
            # Success rate dropping — reduce concurrency
            self.current_concurrent = max(self.current_concurrent - 5, self.min_concurrent)
async def scrape_with_adaptive_pool(urls: list[str]):
    sizer = PoolSizer()
    proxy = "http://USERNAME:PASSWORD@gate.proxyhat.com:8080"
    semaphore = asyncio.Semaphore(sizer.current_concurrent)
    async with aiohttp.ClientSession() as session:
        async def fetch(url):
            async with semaphore:
                try:
                    async with session.get(url, proxy=proxy, timeout=aiohttp.ClientTimeout(total=30)) as resp:
                        success = resp.status == 200
                        sizer.record(success)
                        return await resp.text() if success else None
                except Exception:
                    sizer.record(False)
                    return None
        for batch_start in range(0, len(urls), sizer.current_concurrent):
            batch = urls[batch_start:batch_start + sizer.current_concurrent]
            await asyncio.gather(*[fetch(url) for url in batch])
            sizer.adjust()
            # Update semaphore for next batch
            semaphore = asyncio.Semaphore(sizer.current_concurrent)
            print(f"Concurrent IPs: {sizer.current_concurrent}, Success rate: {sizer.success_rate:.1%}")

Для продакшена ProxyHat Python SDK автоматически управляет пулом соединений и ротацией.

Пример на Node.js

const HttpsProxyAgent = require('https-proxy-agent');
const fetch = require('node-fetch');
class AdaptivePoolSizer {
  constructor(min = 5, max = 100) {
    this.min = min;
    this.max = max;
    this.current = 10;
    this.results = [];
    this.targetRate = 0.95;
  }
  record(success) {
    this.results.push({ time: Date.now(), success });
    if (this.results.length > 100) this.results = this.results.slice(-100);
  }
  get successRate() {
    if (!this.results.length) return 1;
    return this.results.filter(r => r.success).length / this.results.length;
  }
  adjust() {
    if (this.successRate >= this.targetRate && this.current < this.max) {
      this.current = Math.min(this.current + 2, this.max);
    } else if (this.successRate < this.targetRate * 0.9) {
      this.current = Math.max(this.current - 5, this.min);
    }
  }
}
async function scrapeWithAdaptivePool(urls) {
  const sizer = new AdaptivePoolSizer();
  const agent = new HttpsProxyAgent('http://USERNAME:PASSWORD@gate.proxyhat.com:8080');
  for (let i = 0; i < urls.length; i += sizer.current) {
    const batch = urls.slice(i, i + sizer.current);
    const results = await Promise.allSettled(
      batch.map(url =>
        fetch(url, { agent, timeout: 30000 })
          .then(res => { sizer.record(res.ok); return res.text(); })
          .catch(() => { sizer.record(false); return null; })
      )
    );
    sizer.adjust();
    console.log(`Concurrent: ${sizer.current}, Success: ${(sizer.successRate * 100).toFixed(1)}%`);
  }
}

Частые ошибки при определении размера пула прокси

Использование одного и того же количества для всех целей. Пул, работающий для статических блогов, не справится с Amazon. Всегда тестируйте на каждой цели отдельно.
Игнорирование накладных расходов на повторные запросы. Неудачные запросы расходуют трафик и время. Учитывайте 20-40% повторных попыток для агрессивных целей.
Неучёт требований к сессиям. Если нужны липкие сессии для авторизации, каждая сессия занимает IP. Рассчитывайте по числу одновременных сессий, а не только по частоте запросов.
Забывать о географических потребностях. Десять IP в США не помогут собрать локализованные результаты в Японии. Планируйте по каждой географии.
Избыточное выделение «про запас». С ротируемыми резидентными прокси ProxyHat вы автоматически получаете доступ к огромному пулу. Вы платите за трафик, а не за количество IP. Сосредоточьтесь на выборе правильного типа прокси, а не на накоплении IP-адресов.

Преимущество ProxyHat: упрощённое управление пулом

С ротируемым шлюзом резидентных прокси ProxyHat вам не нужно вручную управлять списком IP. Каждый запрос через gate.proxyhat.com автоматически получает свежий IP из пула в миллионы адресов. Это означает:

Нет ручного управления списком IP
Автоматическая ротация на каждом запросе (или липкие сессии при необходимости)
Доступ к IP в 190+ странах
Оплата за использованный трафик, а не за количество IP

Ваше «количество прокси» фактически становится уровнем конкурентности — сколько одновременных соединений вы пропускаете через шлюз. Начните с формул выше, а затем позвольте адаптивному коду оптимизировать параметры в продакшене.

Полное руководство по архитектуре скрапинга с прокси — в нашем Полном руководстве по прокси для веб-скрапинга. О стратегиях ротации, дополняющих расчёт размера пула, читайте в статье Как скрапить сайты без блокировки.

Часто задаваемые вопросы

Сколько прокси нужно для небольшого скрапинга?

Для небольших проектов с менее чем 5 000 запросами в день к умеренно защищённым сайтам обычно достаточно 5-10 одновременных резидентных прокси. С ротируемым шлюзом ProxyHat вы просто устанавливаете уровень конкурентности на 5-10, и система сама назначает IP.

Нужно ли больше прокси для сайтов с JavaScript?

Да. Скрапинг через headless-браузер медленнее на каждый запрос (2-10 секунд вместо 0.5-1 секунды для чистого HTML), поэтому каждый параллельный слот обрабатывает меньше запросов. Может потребоваться в 2-3 раза больше конкурентности для сохранения пропускной способности.

Стоит ли использовать резидентные или датацентр-прокси?

Для большинства задач скрапинга резидентные прокси обеспечивают более высокий процент успеха и требуют меньше одновременных подключений. Прокси датацентров дешевле за ГБ, но блокируются быстрее, требуя большего пула. Подробности — в нашем сравнении типов прокси.

Как работает ротируемый пул ProxyHat?

Каждый запрос через шлюз ProxyHat (gate.proxyhat.com:8080) автоматически получает другой резидентный IP. Вы не управляете отдельными IP — контролируете конкурентность, а система обеспечивает ротацию. Это эффективнее, чем поддержание статического списка IP.