¿Cuántos proxies necesitas para scraping?

Por qué Proxy cuenta asuntos para Web Scraping

Una de las primeras preguntas que cualquier proyecto se enfrenta es engañosamente simple: ¿Cuántos proxies necesito? Use demasiados pocos y sus IPs sean prohibidos en minutos. Use demasiados y desperdicie el presupuesto en la capacidad que nunca toque. El número adecuado depende de los sitios de destino, el volumen de solicitud, la estrategia de rotación y la tolerancia para los bloques.

Esta guía proporciona un marco de cálculo práctico para que pueda dimensionar su piscina proxy con confianza, ya sea que está raspando diez páginas al día o diez millones.

Si eres nuevo para raspar los proxies, comienza con nuestros Guía completa de Proxies de Rastreo Web para conceptos fundamentales.

La fórmula principal

En su más simple, el número de IPs concurrentes que necesita es:

required_ips = (requests_per_minute) / (safe_rpm_per_ip)

Donde safe rpm per ip es la tasa de solicitud máxima que un solo IP puede mantener en su sitio de destino sin abrir bloques. Esto varía drásticamente por objetivo:

Cálculo del ejemplo

Supongamos que necesita raspar 50.000 páginas de productos de un sitio de comercio electrónico diariamente, completando el trabajo dentro de una ventana 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

En la práctica, debe añadir un 30-50% buffer para retries, fallas y desfriamientos de velocidad. Así que la necesidad realista está alrededor 15-17 IPs concurrentes.

Factores que afectan a sus requisitos Proxy

1. Sofisticación del sitio de destino

Sitios con avanzados sistemas antibot requieren más IPs porque cada IP puede hacer menos solicitudes antes de ser insignia. Google, Amazon y las principales plataformas sociales invierten fuertemente en el análisis de huella y comportamiento. Presupuesto para 3-5x más IPs que la fórmula base sugiere cuando se apunta a estos sitios.

2. Solicitud de volumen y frecuencia

El raspado continuo (24/7 monitorización) necesita más IPs que los trabajos por lotes. Si ejecuta un lote diario, puede girar a través de su piscina agresivamente durante la ventana, y luego dejar que los IPs se enfríen. Para el monitoreo en tiempo real, cada IP permanece activa más tiempo, aumentando su requisito total.

3. Distribución geográfica

Si necesita datos de varias regiones (precio localizado, resultados de búsqueda geo-específica), necesita IPs en cada geografía objetivo. Un proyecto raspando precios en 10 países podría necesitar 15 IPs por país, lo que significa 150 totales. Compruebe lo disponible Localizaciones de ProxyHat para planificar su geodistribución.

4. Período de sesiones vs

Algunas tareas (flujos de inicio, análisis de checkout multipágina) requieren sesiones pegajosas donde la misma IP persiste durante minutos. Esto vincula IPs más tiempo, reduciendo la utilización efectiva de la piscina. La recopilación de datos pura sin estado de sesión puede rotar en cada solicitud, utilizando cada IP de manera más eficiente.

5. Residential vs Datacenter

Los IPs residenciales tienen mayores puntajes de confianza y pueden hacer más solicitudes antes de las prohibiciones, por lo que puede necesitar menos de ellos. Pero cuestan más por GB. Los IPs del centro de datos son más baratos pero se marcan más rápido, por lo que necesita una piscina más grande. Para una comparación más profunda, vea Residential vs Datacenter vs Mobile Proxies.

Tablas de tamaño por caso de uso

Cálculo total ancho de banda

El conteo proxy es una dimensión; el ancho de banda es el otro. Estimación de la transferencia total de datos:

# 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

Esto le ayuda a elegir la derecha Plan ProxyHat basado en necesidades de IP y ancho de banda.

Implementación: Capacidad dinámica de la piscina

En lugar de adivinar estadísticamente, implemente el tamaño dinámico de la piscina que se adapta a las condiciones del mundo real. Aquí hay un ejemplo usando la pasarela ProxyHat con concurrencia adaptativa:

Python Ejemplo

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 el uso de la producción, ProxyHat Python SDK maneja la conexión de unión y rotación automáticamente.

Node.js Ejemplo

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

Errores comunes al tamaño de piscinas Proxy

• Usando la misma cuenta para todos los objetivos. Una piscina que trabaja para blogs estáticos fallará en Amazon. Siempre referencia por objetivo.
• Ignorando la reingresación. Las solicitudes fallidas consumen ancho de banda y tiempo. Factor en una tasa de reingreso del 20-40% para objetivos agresivos.
• No contabilizar las necesidades de los períodos de sesiones. Si necesita sesiones pegajosas para flujos de inicio de sesión, cada sesión vincula una IP. Cálculo basado en sesiones simultáneas, no sólo tasa de solicitud.
• Olvidando las necesidades geográficas. Diez IPs en EE.UU. no le ayudarán a eliminar los resultados localizados en Japón. Plan por geografía.
• Sobreprovisionamiento "simplemente en caso". Con proxies residenciales giratorios como ProxyHat, accede a una piscina grande automáticamente. Usted paga por ancho de banda, no por el número de IPs en la piscina. Centrarse en elegir el tipo proxy adecuado en lugar de acaparar IPs.

ProxyHat Advantage: Gestión de Piscinas simplificada

Con la pasarela de proxy residencial rotante de ProxyHat, no necesita administrar manualmente una lista de IPs. Cada solicitud a través de gate.proxyhat.com automáticamente recibe una IP fresca de un grupo de millones. Esto significa:

• No manual IP list management
• Rotación automática en cada solicitud (o sesiones pegajosas cuando sea necesario)
• Acceso a IPs en 190 países
• Pagar por ancho de banda usado, no por tarifas

Su "conteo indirecto" se convierte efectivamente en su nivel de concurrencia — cuántas conexiones simultáneas se ejecutan a través de la puerta de entrada. Comience con las fórmulas anteriores, luego deje que el código de tamaño adaptable lo ajuste en la producción.

Para un paseo completo de la arquitectura de raspado con proxies, vea nuestra Guía completa de Proxies de Rastreo Web. Para conocer las estrategias de rotación que complementan el tamaño de la piscina, leer Cómo cambiar sitios web sin ser bloqueados.

Preguntas frecuentes

¿Cuántos proxies necesito para raspar a pequeña escala?

Para proyectos pequeños bajo 5.000 solicitudes por día dirigidos a sitios protegidos de forma moderada, 5-10 proxies residenciales concurrentes son generalmente suficientes. Con una pasarela giratoria como ProxyHat, simplemente establece su nivel de concurrencia a 5-10 y el sistema maneja la asignación IP.

¿Necesito más proxies para sitios con JavaScript?

Sí. El desguace del navegador sin cabeza es más lento por petición (2-10 segundos vs 0,5-1 segundo solo para HTML), lo que significa que cada ranura concurrente procesa menos solicitudes. Usted puede necesitar 2-3x la concurrencia para mantener el mismo rendimiento. Vea nuestro guía evitar bloques para consejos de optimización.

¿Debería usar proxies residenciales o de centro de datos?

Para la mayoría de las tareas de desguace, los proxies residenciales ofrecen mayores tasas de éxito y requieren menos conexiones concurrentes. Los proxies del centro de datos son más baratos por GB pero se bloquean más rápido, lo que requiere una piscina más grande. Lea nuestro comparación de tipo proxy para orientación detallada.

¿Cómo funciona la piscina rotativa ProxyHat?

Cada solicitud a través de la entrada de ProxyHat (gate.proxyhat.com:8080) se asigna automáticamente un IP residencial diferente. Usted no administra IPs individuales — controla la concurrencia y el sistema maneja la rotación. Esto es más eficiente que mantener una lista IP estática.