¿Cuántas IP de proxy necesitas de verdad?

Es la pregunta que surge antes de casi toda compra de proxies: ¿cuántas IP necesito? Suena al tipo de cosa que debería tener un número por respuesta, y se siente como el número que determina si el trabajo va a funcionar. En la práctica suele ser la pregunta equivocada, y los equipos que arrancan con ella a menudo compran lo que no es. Lo que de verdad decide si tu scraping corre limpio no es cuántas direcciones posees, es cómo se distribuyen tus solicitudes entre las que usas, y si algún objetivo individual llega a ver alguna vez suficiente tráfico desde una sola dirección como para que le importe.

Aquí está cómo pensarlo bien, incluido el único caso en que contar IP sí es el enfoque correcto.

Por qué la pregunta está mal planteada

El instinto de contar IP es un resto de un modelo de precios más viejo. Cuando los proxies se vendían por puerto o por dirección estática, comprabas un número concreto de IP y ese número era tu capacidad, así que contar tenía sentido. Las redes residenciales modernas no funcionan así. Extraes de un gran pool compartido, se te factura por el ancho de banda que mueves en lugar de por las direcciones que tocas, y el número de IP distintas que acabas usando es un resultado de cómo configuras la rotación, no una cantidad que compras por adelantado. Ese cambio, tratado con más profundidad en el artículo sobre por qué la era del por-puerto terminó, es por qué “cuántas IP” ya no se corresponde con nada que compres realmente.

Hay una segunda razón por la que el planteamiento engaña. Un sitio objetivo no ve tu pool. Ve las solicitudes que llegan a su propia puerta, y se forma una opinión por dirección basada en cómo se comportan esas solicitudes. Diez mil IP no salvarán un trabajo que envía todo su volumen a través de un puñado de ellas, y un número modesto de direcciones bien distribuidas correrá cómodamente un trabajo que un montaje ingenuo no podría. La distribución es la variable, no el inventario.

Qué determina de verdad tus requisitos

Cuatro cosas deciden lo que un trabajo necesita. Recórrelas en orden y la respuesta sale sola.

La primera es tu tasa de solicitudes por objetivo. No tu volumen total de solicitudes a través de todo, sino cuántas solicitudes envías a un solo sitio en una ventana dada, porque los límites de tasa se aplican por IP y por objetivo. La segunda es la concurrencia, es decir cuántas solicitudes tienes en vuelo a la vez, lo que fija cuántas direcciones están en uso simultáneo. La tercera son los requisitos de sesión: si tu trabajo necesita una IP retenida para un flujo multipaso, que es el único caso que se convierte en un conteo real. La cuarta es la amplitud geográfica, porque un trabajo que cubre muchos mercados necesita su volumen repartido a través de cada uno de esos mercados en lugar de un gran pool concentrado en otra parte, y donde hay targeting a nivel de ciudad de por medio, la pregunta relevante es la disponibilidad en esa ciudad, no el tamaño de la red en general.

Las cuentas aproximadas para el trabajo rotativo

Para la recopilación rotativa corriente, el cálculo útil no es “cuántas IP existen” sino “cuántas direcciones distintas necesita mi volumen para mantenerse educado en cada objetivo”.

Toma tu tasa de solicitudes a un solo sitio, luego divide por la tasa que estás dispuesto a enviar desde una sola dirección. Si un trabajo envía 60.000 solicitudes por hora a un objetivo, y quieres que ninguna dirección envíe más de aproximadamente una solicitud cada 20 segundos a ese objetivo, que son 180 por hora, entonces ese volumen necesita repartirse a través de algo del orden de 330 direcciones distintas en cualquier momento dado. Cambia cualquiera de las entradas y la respuesta se mueve: reduce el volumen a la mitad y necesitas la mitad, ralentiza cada dirección y necesitas más. Los números aquí son ilustrativos, ya que cada objetivo tolera una tasa distinta y deberías afinar a lo que un sitio concreto acepta de verdad, pero la forma del cálculo es el punto. Estás resolviendo para la distribución, y el pool simplemente tiene que ser lo bastante grande y estar lo bastante bien distribuido en tus mercados objetivo como para suministrarla.

Esto es exactamente lo que hace por ti el balanceo de carga, y por qué las conexiones concurrentes ilimitadas importan más que una cifra de IP de titular: la restricción que muerde es cuántas solicitudes envía una dirección a un sitio, no cuántas direcciones existen en total. Si estás golpeando muchos objetivos distintos, las cuentas aplican por objetivo, y un volumen repartido entre cincuenta sitios es mucho menos exigente que el mismo volumen apuntado a uno.

El caso en que sí cuentas de verdad: las sesiones sticky

Hay una situación en la que un número es genuinamente la respuesta correcta, y vale la pena ser preciso al respecto. Cuando tu trabajo necesita una identidad retenida, una búsqueda multipaso, un flujo de login, una secuencia tipo checkout, o cualquier proceso donde un sitio rastrea estado a través de solicitudes, cada uno de esos flujos concurrentes necesita su propia sesión sticky en su propia IP durante todo lo que dure el flujo. Aquí el conteo es directo: cincuenta sesiones simultáneas significan cincuenta direcciones retenidas en ese momento, y quinientas significan quinientas.

Así que la versión honesta de la pregunta no es “cuántas IP necesito” sino “cuántas sesiones sticky concurrentes necesito”, que es una pregunta sobre la forma de tu carga de trabajo en lugar de sobre la red. Todo lo que no requiera una identidad retenida debería rotar, porque la rotación reparte la carga automáticamente y es como está diseñado para usarse el modelo de rotación.

Por qué el tamaño bruto del pool es una métrica de comparación débil

Los proveedores anuncian tamaños de pool, y los números son lo bastante grandes como para ser difíciles de comparar de forma significativa. Tres cosas importan más que la cifra de titular.

La distribución en tus mercados va primero. Un pool muy grande que es delgado en el país o la ciudad que de verdad necesitas es peor para tu trabajo que una red más pequeña que sea densa ahí, así que el único tamaño de pool que importa es el disponible donde estás recopilando. La calidad va segunda, ya que las direcciones marcadas o sobreexplotadas atraen desafíos y respuestas distorsionadas sin importar cuántas de ellas haya, que es por qué la reputación de la IP afecta tu tasa de éxito más directamente que el volumen, y por qué ayuda entender qué es en realidad una IP residencial. La disponibilidad concurrente va tercera: lo que es usable en el momento en que envías tráfico es lo que importa, no un conteo acumulado de cada dirección que la red haya visto alguna vez.

La consecuencia práctica es que no deberías elegir un proveedor por el tamaño del pool. Corre tu propia carga de trabajo contra una compra pequeña y mídela, que es para lo que sirve la guía de testear velocidad, tasa de éxito y precisión de ubicación.

Qué dimensionar en su lugar: el ancho de banda

Como se te factura por datos movidos en lugar de por direcciones usadas, el número que vale la pena pronosticar es el ancho de banda. Estima el tamaño de página o de respuesta para tus objetivos, multiplica por el volumen que planeas recopilar, y tienes una cifra que se corresponde con lo que de verdad pagarás, que es el enfoque expuesto en estimar el ancho de banda mensual. Eso también hace obvia la mayor palanca de coste, y no es el número de IP: obtener solo lo que necesitas en lugar de páginas renderizadas enteras es donde están los ahorros, como se trata en recortar los costes de ancho de banda de proxy.

Configurarlo

Ambos modos vienen del mismo gateway, y la diferencia es un campo en el nombre de usuario. Omite un identificador de sesión y cada solicitud rota, que es lo que debería hacer la mayor parte de la recopilación:

import requests

# Rotating: every request exits through a different address
ROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
r = requests.get("https://example.com/page",
                 proxies={"http": ROTATING, "https": ROTATING}, timeout=15)

# Sticky: one held IP per concurrent flow, counted per session
def sticky(session_id):
    url = (f"http://customer-USERNAME-country-us-sid-{session_id}:"
           f"PASSWORD@p.shifter.io:443")
    return {"http": url, "https": url}

# 50 concurrent flows means 50 distinct session identifiers
for i in range(50):
    proxies = sticky(f"flow{i}")
    # run one multi-step sequence on this held address

Rota por defecto, retén una sesión solo donde un flujo genuinamente necesite una, y deja que el pool maneje la distribución en lugar de intentar gestionar tú mismo una lista fija de direcciones.

Validar la respuesta

Cualquier número al que llegues es una hipótesis de partida, y la única confirmación fiable es la medición. Vigila la tasa de éxito por objetivo y por región, porque un descenso es la señal de que tu tasa por dirección es demasiado agresiva para ese sitio mucho antes de que se convierta en un hueco de datos, que es lo que te da monitorizar el pipeline. Cuando una ruta se degrada, el failover mantiene el trabajo corriendo mientras ajustas. Y si estás viendo bloqueos, la solución es más a menudo el ritmo y la higiene de las solicitudes que más direcciones, que es la sustancia de evitar bloqueos.

Una lista corta

1. ¿Cuántas solicitudes por hora a tu objetivo individual más ocupado? Eso, dividido por la tasa por dirección que ese objetivo tolera, es aproximadamente cuánta distribución necesitas.
2. ¿Cuántos flujos concurrentes necesitan una identidad retenida? Ese es tu conteo de sesiones sticky, y es el único número que vale la pena enunciar.
3. ¿Qué países y ciudades necesitas, y es el pool denso en esos lugares en lugar de meramente grande en general?
4. ¿Cuántos datos moverás? Ese es el número que determina el coste.
5. ¿Has medido la tasa de éxito sobre tu propia carga de trabajo en lugar de confiar en una cifra de titular?

En resumen

“¿Cuántas IP necesito?” es una pregunta heredada de un modelo de precios que ya no aplica. En una red residencial moderna con precio por ancho de banda no estás comprando un conteo de direcciones, estás comprando acceso a un pool y pagando por los datos que mueves a través de él, así que aquello para lo que hay que diseñar es la distribución: suficiente reparto como para que ningún objetivo individual vea nunca más que tráfico corriente desde una sola dirección. Rota para el volumen, cuenta solo tus sesiones sticky concurrentes, juzga una red por su densidad en los mercados de los que de verdad recopilas y por la tasa de éxito que entrega sobre tu propia carga de trabajo, y dimensiona tu presupuesto en ancho de banda en lugar de en direcciones. Acierta con la distribución y el conteo de IP deja de ser algo en lo que tengas que pensar.

Eso es lo que los proxies residenciales están construidos para proporcionar, un gran pool de IP reales de nivel doméstico con targeting por país y ciudad, rotación por defecto, y sesiones sticky para los flujos que las necesitan. El precio por GB es el número alrededor del cual vale la pena planificar, porque pagas por los datos que de verdad extraes en lugar de por una cantidad de direcciones que esperas que sea suficiente.