Quantos Proxies Voce Precisa para Scraping?

Por que a contagem de proxy importa para raspar a Web

Uma das primeiras perguntas qualquer raspar rostos de projeto é enganosamente simples: De quantos proxies é que preciso? Use muito poucos e seus IPs serão banidos em poucos minutos. Use muitos e você desperdiçar orçamento em capacidade que você nunca tocar. O número certo depende de seus sites de destino, volume de solicitação, estratégia de rotação e tolerância para blocos.

Este guia fornece uma estrutura de cálculo prática para que você possa dimensionar seu pool proxy com confiança, se você está raspando dez páginas por dia ou dez milhões.

Se você é novo para raspar proxies, comece com o nosso Guia completo de Web Raspando Proxies para conceitos fundamentais.

A Fórmula Principal

No seu mais simples, o número de IPs que você precisa é:

required_ips = (requests_per_minute) / (safe_rpm_per_ip)

Onde segura rpm per ip é a taxa máxima de solicitação que um único IP pode manter em seu site alvo sem ativar blocos. Isto varia drasticamente por alvo:

Cálculo de Exemplo

Suponha que você precisa raspar 50.000 páginas de produto de um site de comércio eletrônico diariamente, completando o trabalho dentro de uma janela de 8 horas:

# 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

Na prática, você deve adicionar um 30-50% tampão para tentativas, falhas e arrefecimentos de limite de taxa. Assim, a necessidade realística está ao redor 15-17 IPs simultâneos.

Fatores que afetam seus requisitos de proxy

1. Sofisticação do local do alvo

Sites com avançado sistemas anti-bots requer mais IPs porque cada IP pode fazer menos pedidos antes de ser marcado. Google, Amazon e grandes plataformas sociais investem fortemente em impressão digital e análise comportamental. Orçamento para 3-5x mais IPs do que a fórmula base sugere ao segmentar estes sites.

2. Solicitar volume e frequência

A raspagem contínua (24/7 monitoramento) precisa de mais IPs do que trabalhos em lote. Se você executar um lote diário, você pode girar através de sua piscina agressivamente durante a janela, em seguida, deixe IPs esfriar. Para monitoramento em tempo real, cada IP permanece ativo por mais tempo, aumentando sua exigência total.

3. Distribuição Geográfica

Se você precisa de dados de várias regiões (preço localizado, resultados de pesquisa geo-específica), você precisa de IPs em cada geografia alvo. Um projeto de raspagem de preços em 10 países pode precisar de 15 IPs por país, ou seja, 150 no total. Verificar o disponível Locais do ProxyHat para planear a sua distribuição geográfica.

4. Sessão vs Requisitos Rotativos

Algumas tarefas (fluxos de login, análise de checkout de várias páginas) requerem sessões pegajosas onde o mesmo IP persiste por minutos. Isso liga IPs mais longos, reduzindo a utilização efetiva do pool. Coleta de dados pura sem estado de sessão pode girar em cada solicitação, usando cada IP de forma mais eficiente.

5. Residencial vs Datacenter

Os IPs residenciais têm maiores pontuações de confiança e podem fazer mais pedidos antes das proibições, então você pode precisar de menos deles. Mas custam mais por GB. Os IPs do Datacenter são mais baratos, mas são marcados mais rápido, então você precisa de uma piscina maior. Para uma comparação mais profunda, ver Residencial vs Datacenter vs Mobile Proxies.

Tamanho de tabelas por caso de uso

Calculando Largura de Banda Total

Contagem de proxy é uma dimensão; largura de banda é a outra. Estimar sua transferência total de dados:

# 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

Isso ajuda você a escolher o certo Plano ProxyHat baseado tanto em IP quanto em largura de banda.

Implementação: Dimensionamento de Piscina Dinâmica

Ao invés de adivinhar estaticamente, implemente o dimensionamento dinâmico do pool que se adapta às condições do mundo real. Aqui está um exemplo usando o gateway ProxyHat com concordância adaptativa:

Exemplo 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%}")

Para utilização na produção ProxyHat Python SDK lida automaticamente com o agrupamento e rotação de ligações.

Exemplo 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)}%`);
  }
}

Erros comuns ao avaliar piscinas de proxy

• Usando a mesma contagem para todos os alvos. Um pool que trabalha para blogs estáticos falhará na Amazon. Sempre referência por alvo.
• Ignorando retentar as despesas. Solicitações falhadas consomem largura de banda e tempo. Fator numa taxa de repetição de 20-40% para alvos agressivos.
• Não contabilizando os requisitos da sessão. Se você precisa de sessões fixas para fluxos de login, cada sessão liga um IP. Calcular com base em sessões simultâneas, não apenas taxa de solicitação.
• Esquecer as necessidades geográficas. Dez IPs nos EUA não vão ajudá-lo a raspar resultados localizados no Japão. Plano por geografia.
• Superprovisionar "por precaução". Com proxies residenciais rotativos como ProxyHat, você acessa uma grande piscina automaticamente. Você paga pela largura de banda, não pelo número de IPs no pool. Foco em escolhendo o tipo de proxy certo em vez de acumular IPs.

Vantagem ProxyHat: Gestão de Piscinas Simplificada

Com o gateway proxy residencial rotativo do ProxyHat, você não precisa gerenciar manualmente uma lista de IPs. Cada pedido através de gate.proxyhat.com recebe automaticamente um novo IP de um conjunto de milhões. Isto significa:

• Sem gerenciamento manual da lista IP
• Rotação automática em cada pedido (ou sessões pegajosas quando necessário)
• Acesso a IPs em 190+ países
• Pagar pela largura de banda utilizada, não por IP

Sua "contagem de proxy" efetivamente se torna seu nível de concorrência — quantas conexões simultâneas você executa através do gateway. Comece com as fórmulas acima, em seguida, deixe o código de dimensionamento adaptativo ajustá-lo na produção.

Para uma completa caminhada da arquitetura de raspagem com proxies, consulte Guia completo de Web Raspando Proxies. Para aprender sobre as estratégias de rotação que complementam o dimensionamento de sua piscina, leia Como raspar sites sem ser bloqueado.

Perguntas Frequentes

De quantos proxies preciso para raspar em pequena escala?

Para projetos pequenos com menos de 5.000 pedidos por dia visando sites moderadamente protegidos, 5-10 proxies residenciais concorrentes são tipicamente suficientes. Com um gateway rotativo como o ProxyHat, você simplesmente define seu nível de concordância para 5-10 e o sistema lida com a atribuição de IP.

Preciso de mais proxies para sites pesados de JavaScript?

Sim. Raspar navegador sem cabeça é mais lento por solicitação (2-10 segundos vs 0,5-1 segundo somente para HTML), o que significa que cada slot concorrente processa menos solicitações. Você pode precisar de 2-3x a concorrência para manter o mesmo rendimento. Veja nosso guia sobre evitando bloqueios para dicas de otimização.

Devo usar proxies residenciais ou datacenters?

Para a maioria das tarefas de raspagem, proxies residenciais oferecem taxas de sucesso mais elevadas e requerem menos conexões simultâneas. Os proxies do Datacenter são mais baratos por GB, mas são bloqueados mais rápido, exigindo um pool maior. Leia o nosso comparação do tipo de proxy para orientação pormenorizada.

Como funciona a piscina rotativa do ProxyHat?

Cada pedido através do gateway do ProxyHat (gate.proxyhat.com:8080) é automaticamente atribuído um IP residencial diferente. Você não gerencia IPs individuais — você controla a concorrência e o sistema lida com rotação. Isso é mais eficiente do que manter uma lista IP estática.