En un plan de proxy residencial por GB, el ancho de banda es la unidad que compras, así que elegir el plan correcto se reduce a una pregunta: ¿cuántos gigabytes usarás de verdad en un mes? Si estimas demasiado bajo, chocas con el overage o el throttling a mitad de mes; si estimas demasiado alto, pagas de más por un margen que nunca tocas. La buena noticia es que el ancho de banda es estimable, no un misterio. Con una fórmula, algunos tamaños realistas por página, y una medición de cinco minutos, puedes dimensionar un plan con confianza.
Esta guía es para equipos que planifican el uso de proxies. Construiremos la estimación paso a paso, la fundamentaremos en una medición real, y recorreremos ejemplos resueltos para cargas de trabajo comunes.
La fórmula
Todo se reduce a esto:
GB mensuales ≈ (peticiones por mes × tamaño medio de respuesta × factor de overhead) / bytes por GBCuatro entradas, y una de ellas domina. Tomémoslas en orden de impacto.
Paso 1: tamaño medio de respuesta (el gran motor)
Cuántos bytes vuelven por petición es donde las estimaciones viven o mueren, y varía en más de 10x según cómo obtienes. Rangos típicos:
| Qué obtienes | Tamaño típico por petición |
|---|---|
| Respuesta JSON de API esbelta | 5 a 50 KB |
| Solo página HTML (sin assets) | 100 a 500 KB |
| Página completa en un navegador headless (imágenes, CSS, JS, fuentes) | 1 a 5 MB+ |
El factor individual más grande de tu factura es si renderizas un navegador completo o obtienes HTML/JSON directamente. Un navegador descarga todo lo de la página; una petición HTTP simple trae una fracción de eso. Si puedes sacar tus datos del HTML o de una API, tu tamaño por petición, y tu ancho de banda, caen en un orden de magnitud. (Eso, más el bloqueo de assets, es el núcleo de cómo recortar los costes de ancho de banda de proxy.)
No adivines este número si puedes medirlo, ve el Paso 4.
Paso 2: peticiones por mes
Esto normalmente son páginas (o registros) por frecuencia:
peticiones por mes = ítems × comprobaciones por día × 30Un monitor de precios que rastrea 10,000 productos una vez al día son 10,000 × 1 × 30 = 300,000 peticiones al mes. Una construcción de dataset de una sola vez es solo el recuento total de páginas, sin multiplicador de frecuencia. Incluye la paginación: si cada “ítem” abarca tres páginas de resultados, multiplica en consecuencia.
Paso 3: el factor de overhead
Los crawls reales no son 100% eficientes. Los reintentos, redirects, e intentos fallidos cruzan todos el proxy y cuestan todos ancho de banda, una petición bloqueada o con timeout aún gastó bytes. Añade un factor de overhead encima de tu estimación limpia:
- Objetivos fáciles y abiertos: ~1.1 (10% de overhead)
- Sitios típicos: ~1.2 (20%)
- Objetivos bien defendidos (bloqueos/reintentos frecuentes): ~1.3 o más
Cuanto más difícil el objetivo, más reintentos, así que más alto el factor. Reducir tu tasa de bloqueo (mejor calidad de IP, ritmo sensato) lo encoge directamente, ve cómo evitar que te bloqueen.
Paso 4: mide tu tamaño real por página (no adivines)
La forma más rápida de llegar a una estimación fiable es obtener una muestra representativa de tu objetivo real a través del proxy y medir los bytes. El tamaño de respuesta en bytes es len(response.content):
import os, requests, statistics
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"proxies = {"http": proxy_url, "https": proxy_url}
sample_urls = [ ... ] # 20-50 URLs objetivo representativassizes_kb = []for url in sample_urls: r = requests.get(url, proxies=proxies, timeout=30) sizes_kb.append(len(r.content) / 1024)
avg_kb = statistics.mean(sizes_kb)print(f"avg {avg_kb:.0f} KB/request (n={len(sizes_kb)})")Córrelo contra 20 a 50 URLs reales y tienes un tamaño medio fundamentado en lugar de una conjetura. Nota que esto mide los bytes comprimidos que de verdad cruzan el proxy (mantén Accept-Encoding activado), que es lo que se te factura. La configuración completa del cliente está en proxies residenciales con Python.
Ejemplos resueltos
Usando GB mensuales = peticiones × tamaño_medio × overhead / 1,000,000 (KB a GB, decimal):
Monitorización de precios, solo HTML. 10,000 productos, diario, ~200 KB/página, overhead 1.15.
300,000 × 200 KB × 1.15 = 69,000,000 KB ≈ 69 GB/mes.
El mismo trabajo, pero con renderizado de navegador completo. ~2 MB/página en lugar de 200 KB.
300,000 × 2,000 KB × 1.15 = 690,000,000 KB ≈ 690 GB/mes.
Los mismos datos, 10x el ancho de banda, ese es el coste de renderizar cuando no lo necesitabas (ve con Playwright para bloquear assets si debes renderizar).
Monitorización de búsqueda/ranking, respuestas esbeltas. 500 consultas, 4x/día, ~30 KB cada una, overhead 1.2.
500 × 4 × 30 × 30 KB × 1.2 = 2,160,000 KB ≈ 2.2 GB/mes. Pequeño y barato.
Construcción de dataset de una sola vez. 2,000,000 de páginas, ~300 KB HTML, overhead 1.2.
2,000,000 × 300 KB × 1.2 = 720,000,000 KB ≈ 720 GB, una vez, no mensual.
El patrón está claro: el tamaño de respuesta y la elección de renderizado dominan; el recuento de peticiones escala linealmente; el overhead es un multiplicador modesto.
De la estimación al plan
Convierte el número en un plan con un poco de disciplina:
- Añade un margen. Dimensiona el plan a tu estimación más un 20 a 30%, para el crecimiento dentro del mes y el error de estimación. Quedarte sin nada a mitad de ciclo es más disruptivo que un poco de margen.
- Conoce los términos de overage. Comprueba cómo maneja tu proveedor el pasarte, por-GB extra, throttling, o una parada dura, para que un mes ocupado no te sorprenda.
- Reconcilia semanalmente. Compara el uso real contra tu estimación temprano en el ciclo y ajusta. El uso real te enseña tu verdadero tamaño por página y tasa de bloqueo más rápido que cualquier conjetura.
- Encoge el número antes de comprar más. A menudo el gigabyte más barato es el que no gastas, sáltate el renderizado, bloquea assets, y no re-descargues páginas sin cambios (recorta los costes de ancho de banda de proxy) antes de agrandar el plan. Este es el modelo por GB que hace que la eficiencia pague (la era del por-puerto se acabó).
Preguntas frecuentes
¿Cómo estimo el ancho de banda si nunca he corrido el trabajo? Mide una muestra representativa de tus páginas objetivo a través del proxy (Paso 4) para obtener un tamaño real por petición, luego enchúfalo en la fórmula con tu recuento de peticiones y un factor de overhead. Una muestra medida le gana a cualquier estimación genérica.
¿Qué usa más ancho de banda? El renderizado de navegador completo, con diferencia, descarga cada imagen, fuente, y script. Obtener HTML o una API JSON directamente puede recortar el tamaño por petición en 10x. La elección de renderizado es la mayor palanca sobre tu factura.
¿Las peticiones fallidas y reintentadas cuentan para mi ancho de banda? Sí. Cualquier petición que cruza el proxy usa ancho de banda, incluyendo bloqueos, redirects, y reintentos. Por eso la estimación incluye un factor de overhead, y por eso reducir tu tasa de bloqueo baja el coste.
¿1 GB son 1,000 MB o 1,024 MB? Depende de la definición de facturación del proveedor, decimal (1,000) o binaria (1,024). La diferencia es de un 7% aproximadamente, bien para estimar, pero confirma cuál usa tu proveedor cuando dimensionas cerca de un límite de plan.
¿Cuánto margen debería añadir? Planifica para tu estimación más un 20 a 30%, para absorber el crecimiento y el error de estimación dentro del mes. Luego reconcilia contra el uso real y ajusta, en lugar de sobre-comprar por adelantado.
En resumen
Estimar el ancho de banda de proxy residencial no es adivinar: multiplica las peticiones por un tamaño medio de respuesta medido y un factor de overhead, convierte a GB, y añade un margen. Las dos cosas que más mueven el número son cómo obtienes (HTML/JSON le gana al navegador completo por unas 10x) y con qué frecuencia reintentas (mejor calidad de IP significa menos bytes desperdiciados), así que mide una muestra real antes de comprometerte, y recorta el número antes de comprar más.
Una vez que tienes una estimación, la página de precios presenta los planes por GB para que puedas emparejar un nivel con tu número más margen, y apunta un scraper bien afinado al gateway residencial para mantener el uso real cerca del plan.