El error clásico al escalar un scraper es comprar proxies "a ojo": tomamos 100 IP, lanzamos el scraper y obtenemos bloqueos en media hora. El problema no está en la cantidad de direcciones, sino en que nadie calcula la carga real en cada IP. Vamos a desglosar la fórmula para calcular el pool de proxies, basada en RPS (requests per second), retrasos y límites del sitio objetivo — con cifras concretas y código en Python.
Por qué contar el pool por la cantidad de IP es un error
El enfoque típico de un principiante en scraping: "necesitamos recopilar 50,000 tarjetas de productos, así que compraremos 500 proxies y distribuiremos la carga". La lógica parece sensata, pero no toma en cuenta lo principal: sitios como Wildberries y Ozon no bloquean por el número absoluto de solicitudes, sino por la intensidad de las solicitudes desde una IP en un período de tiempo. Es decir, 500 proxies, cada uno de los cuales hace 20 solicitudes por segundo, serán bloqueados de inmediato: los sistemas anti-bot ven un patrón similar a un DDoS.
Por otro lado, si tienes 50 proxies, pero cada uno hace 1 solicitud cada 5-10 segundos con pausas aleatorias, imitando el comportamiento humano, puedes hacer scraping de manera estable durante semanas sin un solo bloqueo. La cantidad de IP no es la razón de la estabilidad, sino la consecuencia de una carga correctamente calculada. Por eso, la fórmula debe basarse no en "cuántas IP comprar", sino en "cuánto RPS necesitas alcanzar y cuál es la carga segura por IP".
Otro matiz: diferentes tipos de proxies tienen diferentes "márgenes de resistencia" por IP. Los proxies de centros de datos son bloqueados más rápidamente a altas frecuencias de solicitudes, porque sus subredes son fácilmente reconocibles como de hosting. Las IP residenciales y móviles parecen usuarios normales, y se les puede permitir una frecuencia ligeramente más alta sin riesgo de bloqueo — pero eso no significa que se puedan ignorar los límites por completo.
Fórmula básica para calcular el pool de proxies
La fórmula para calcular la cantidad de proxies en el pool es la siguiente:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Donde:
- N — cantidad necesaria de proxies en el pool;
- RPS_target — velocidad objetivo de scraping (solicitudes por segundo en todo el sistema);
- Delay_per_ip — pausa mínima segura entre solicitudes desde una IP (en segundos);
- Concurrency_per_ip — cuántos hilos paralelos permites en una IP (generalmente 1, máximo 2 para proxies residenciales).
La lógica es simple: si quieres mantener 10 solicitudes por segundo en total, y la pausa segura entre solicitudes desde una IP es de 8 segundos, entonces una IP físicamente solo puede emitir 1 solicitud cada 8 segundos, es decir, 0.125 RPS. Para obtener 10 RPS en total, necesitas 10 / 0.125 = 80 proxies. Este es el cálculo que reemplaza la suposición de "500 IP por si acaso".
Cómo calcular el RPS objetivo para scraping
Antes de calcular el pool, necesitas determinar RPS_target — cuántas solicitudes por segundo realmente necesitas para recopilar datos en un tiempo razonable. La fórmula aquí es inversa:
RPS_target = Total_requests / Time_budget_seconds
Ejemplo: necesitas recopilar 100,000 tarjetas de productos de Wildberries en 8 horas (28,800 segundos). Si se necesita 1 solicitud por cada tarjeta, RPS_target = 100,000 / 28,800 ≈ 3.47 solicitudes por segundo. No es tanto como parece a primera vista — muchos sobreestiman la velocidad necesaria y compran una cantidad excesiva de proxies.
Si la tarea incluye varios tipos de solicitudes (por ejemplo, primero obtener la lista de categorías, luego las tarjetas, luego las reseñas), calcula el RPS para cada etapa por separado — pueden ir en paralelo con diferentes pools de proxies, y la carga total en la plataforma se distribuirá entre diferentes endpoints.
Límites por IP: cuántas solicitudes por minuto son seguras
Delay_per_ip es el parámetro más importante en la fórmula, y debe determinarse empíricamente para cada sitio. Orientaciones generales, basadas en la práctica de scraping de marketplaces:
| Plataforma | Pausa segura entre solicitudes desde 1 IP | Máximo de solicitudes/min desde 1 IP |
|---|---|---|
| Wildberries (API de tarjetas) | 4-6 seg | 10-15 |
| Ozon (páginas de productos) | 5-8 seg | 8-12 |
| Avito (anuncios) | 6-10 seg | 6-10 |
| Yandex.Market | 5-7 seg | 8-12 |
Estas cifras son un punto de partida, no una dogma. Comienza con valores conservadores (límite superior de la pausa), monitorea el porcentaje de errores 429 y 403, y reduce gradualmente la pausa si los bloqueos no aumentan. Aumentar drásticamente el RPS sin pruebas graduales es la forma más común de quemar todo el pool de proxies en un solo día.
Cálculos prácticos: Wildberries, Ozon, Avito
Vamos a analizar tres escenarios reales con un cálculo completo según la fórmula.
Escenario 1: monitoreo de precios en Wildberries. Necesitas actualizar los precios de 20,000 productos cada 2 horas. RPS_target = 20,000 / (2 × 3600) ≈ 2.78 RPS. Con una pausa de 5 seg por 1 IP y Concurrency = 1: N = (2.78 × 5) / 1 ≈ 14 proxies. Para tener un margen en caso de bloqueo de algunas IP, se recomienda tomar un pool con un coeficiente de 1.5-2x, es decir, 21-28 proxies.
Escenario 2: recolección única del catálogo de Ozon. 500,000 tarjetas en 24 horas. RPS_target = 500,000 / 86,400 ≈ 5.79 RPS. Con una pausa de 6 seg: N = (5.79 × 6) / 1 ≈ 35 proxies. Con margen — 50-60 proxies.
Escenario 3: monitoreo de competidores en Avito en tiempo real. 5,000 anuncios, actualización cada 15 minutos. RPS_target = 5,000 / 900 ≈ 5.56 RPS. Con una pausa de 8 seg: N = (5.56 × 8) / 1 ≈ 45 proxies. Aquí es importante tener en cuenta que Avito bloquea activamente las subredes de centros de datos, por lo que para esta tarea es más razonable considerar inmediatamente IP residenciales o móviles.
Proxies residenciales, móviles y de centros de datos en la fórmula
El tipo de proxy afecta directamente a Delay_per_ip y, por ende, a N en la fórmula. Los proxies de centros de datos son más baratos y rápidos, pero requieren pausas más largas entre solicitudes y son bloqueados más frecuentemente a altas frecuencias — de hecho, para los mismos 5 RPS, puedes necesitar 2-3 veces más IP de centros de datos que residenciales.
| Tipo de proxy | Delay_per_ip promedio | Cuándo usar |
|---|---|---|
| Proxies de centros de datos | 8-15 seg | APIs abiertas, sitios sin un anti-bot estricto |
| Proxies residenciales | 4-8 seg | Wildberries, Ozon, Avito y otros marketplaces con anti-bot |
| Proxies móviles | 3-6 seg | Las protecciones más agresivas, redes sociales, APIs móviles |
Para hacer scraping de marketplaces como Wildberries y Ozon, la opción óptima suele ser proxies residenciales — equilibran precio y estabilidad, permitiendo mantener pausas más cortas sin un aumento brusco en los bloqueos. Los proxies de centros de datos deben considerarse solo para plataformas sin un anti-bot agresivo o para tareas únicas con un RPS bajo.
Implementación del pool en Python: código con rotación
A continuación, una implementación simplificada del pool de proxies con control de la frecuencia de solicitudes por cada IP. La lógica: cada proxy almacena el tiempo de último uso, y el planificador elige solo aquellas IP que han pasado suficiente tiempo desde la última solicitud.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # pausa segura en segundos
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
# seleccionamos aleatoriamente de los disponibles, para evitar el patrón de cola
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:
"""Fórmula: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Ejemplo de uso
rps_target = 5.79 # calculado a partir del volumen de la tarea y el tiempo
delay_per_ip = 6.0 # pausa segura para Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Proxies necesarios en el pool: {n_proxies}") # ~35, con margen 50-60
En un scraper real, esta lógica debe complementarse con una cola de tareas (por ejemplo, a través de asyncio o multiprocessing), para que los trabajadores esperen la aparición de un proxy libre, en lugar de finalizar con un error en su ausencia. También se debe agregar un backoff exponencial al recibir 429/403 — esto aumentará automáticamente la pausa para una IP específica al detectar signos de bloqueo.
Monitoreo y corrección dinámica del pool
El cálculo estático según la fórmula es un punto de partida, no una solución final. En la explotación real, es necesario rastrear tres métricas clave:
- Tasa de éxito — porcentaje de solicitudes exitosas (código 200) del total. Una caída por debajo del 90-95% indica que Delay_per_ip debe aumentarse o que se deben agregar proxies al pool;
- Tasa de bloqueo — proporción de proxies que han mostrado signos de bloqueo (captcha, 403, redirección a un formulario de verificación) en la última hora;
- RPS real — velocidad real de procesamiento de solicitudes, que puede diferir de la calculada debido a timeouts y reintentos.
Regla práctica: si la tasa de bloqueo supera el 5-7% por hora, aumenta Delay_per_ip en un 20-30% y recalcula N según la fórmula. Si la tasa de éxito se mantiene por encima del 98% durante varias horas, puedes reducir gradualmente la pausa y disminuir el tamaño del pool — esto es un ahorro directo en el presupuesto de proxies sin pérdida de estabilidad.
Una buena práctica es llevar un registro por cada IP por separado: tiempo de la última solicitud exitosa, cantidad de errores consecutivos, tiempo promedio de respuesta. Esto permite excluir automáticamente proxies "dañados" de la rotación durante 30-60 minutos en lugar de seguir enviando solicitudes a través de ellos y recibir captcha en cada paso.
Errores comunes al calcular el pool de proxies
Incluso conociendo la fórmula, es fácil cometer errores en los detalles del cálculo. Aquí hay una lista de errores típicos:
- Ignorar el margen para bloqueos. Incluso con un cálculo perfecto, el 5-10% de los proxies estarán temporalmente no disponibles debido a bloqueos o problemas de red. Siempre añade un coeficiente de 1.3-2x al N base;
- Delay_per_ip idéntico para todos los endpoints. La página de categoría y la página de tarjeta de producto pueden tener diferentes límites — calcula por separado;
- Concurrency mayor a 1 sin pruebas. Las solicitudes paralelas desde una IP aumentan drásticamente el riesgo de bloqueo, especialmente en proxies residenciales — comienza con Concurrency = 1;
- Falta de rotación de User-Agent y encabezados. Incluso un pool de proxies correctamente calculado no salvará si todas las solicitudes provienen de la misma huella de navegador;
- Pausa fija sin jitter. Un intervalo estrictamente igual entre solicitudes (por ejemplo, exactamente 5.0 seg) es un patrón fácilmente reconocible por el anti-bot. Añade una desviación aleatoria de ±20-30%.
Conclusión
La fórmula N = (RPS_target × Delay_per_ip) / Concurrency_per_ip convierte el cálculo del pool de proxies de una suposición a una tarea de ingeniería con cifras concretas. Primero, determina la velocidad objetivo de scraping en función del volumen de datos y el tiempo, luego encuentra empíricamente la pausa segura para la plataforma específica, y solo después calcula la cantidad necesaria de IP — con un margen del 30-100% para bloqueos y fallos.
Este enfoque ahorra presupuesto: en lugar de comprar una cantidad excesiva de IP "por si acaso", pagas exactamente por el volumen de proxies necesario para alcanzar el RPS objetivo sin riesgo de bloqueos. Para hacer scraping de marketplaces y otros sitios protegidos, recomendamos comenzar con proxies residenciales — ofrecen el mejor equilibrio entre estabilidad y costo al trabajar con sistemas anti-bot de Wildberries, Ozon y Avito.