¿Cuántos proxies necesitas realmente?

Vendemos proxies en Geonode, lo que convierte este artículo en un argumento a favor de que compres menos de lo que tenías pensado. Esa es realmente nuestra postura: un conjunto de proxies demasiado grande no te ofrece mayor seguridad y, con la tarificación basada en el tráfico, ni siquiera cuesta más —lo que significa que la gente tiene una idea errónea sin haber visto nunca la factura que la corregiría. La cifra que importa es la concurrencia frente a un único objetivo, y se puede medir en una tarde. Si te quedas con una sola cosa de todo esto, que sea la medición de la siguiente sección, en lugar de cualquier cifra que podamos darte.

El único método que funciona

Tres pasos, todos empíricos.

Paso uno: determina el límite máximo por dirección. Ejecuta tu carga de trabajo real desde una única dirección, aumentando gradualmente la tasa de solicitudes, y averigua en qué punto el destino empieza a dar señales de saturación —códigos 429, mensajes de error, respuestas más lentas o contenido degradado—. Ese umbral es tu capacidad por dirección para ese destino, y es la única cifra de este cálculo que no es una estimación.

Paso dos: establece el rendimiento necesario. Cuántas solicitudes y durante cuánto tiempo. Sé sincero con respecto a la parte de «durante cuánto tiempo», ya que es el factor que más influye en esta ecuación.

Paso tres: divide. El rendimiento requerido dividido por la capacidad por dirección da como resultado el número de direcciones simultáneas necesarias. Añade un margen para reintentos y variabilidad: un 50 % es generoso, y si necesitas más que eso, es probable que tu medición en el paso uno fuera optimista.

Ese es todo el método. La razón por la que no es el consejo habitual es que requiere realizar una prueba antes de comprar, y los proveedores no tienen ningún incentivo para sugerirlo.

Una nota sobre el paso uno: mide las respuestas útiles completadas por segundo, no las solicitudes intentadas. Un grupo que devuelva códigos 200 con contenido eliminado no está funcionando, y una métrica de tasa de éxito agregada lo indicará como en buen estado. Busca un marcador conocido y estable en la respuesta y cuenta solo las respuestas que lo contengan.

Cómo realizar la medición correctamente

Todo el método se basa en el primer paso, por lo que conviene ser específico sobre cómo llevarlo a cabo sin inducirse a error.

Realiza la prueba con tu destino real, no con un punto final de prueba. Una prueba con un servicio que devuelve tu dirección IP solo te indica que el proxy funciona, pero no te dice nada sobre cómo te tratará el sitio que te interesa. Cada destino tiene su propio umbral de tolerancia, y el valor que necesitas depende específicamente de cada uno.

*Aumenta gradualmente la carga y registra todo. Empieza muy por debajo de lo que esperas que sea el límite y ve subiendo, manteniendo cada tasa el tiempo suficiente para detectar un patrón —al menos unos minutos—. Registra la tasa, los códigos de estado, los tamaños de respuesta y el tiempo real para cada paso:

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

Presta tanta atención al tamaño de la respuesta como al código de estado. La forma más habitual de rechazo no es un 429, sino un 200 que lleva una página más pequeña. Una caída en el tamaño medio de la respuesta a una tasa concreta indica que el destino está empezando a servirte algo reducido, y esto pasa desapercibido si solo cuentas los códigos de estado.

Ejecútalo a diferentes horas del día. La tolerancia suele ser menor durante las horas punta de un sitio web, y un límite medido a las 3 de la madrugada no se mantendrá a mediodía. Toma la cifra más pesimista.

Repite el proceso con una segunda dirección. Si una dirección se satura con dos solicitudes por segundo y una segunda dirección se satura al mismo tiempo, el límite no es por dirección, sino que está en tu subred, en el perfil de tus solicitudes o en algún otro factor que no se solucionará añadiendo más direcciones. Ese es un resultado negativo importante y obtenerlo cuesta una ejecución adicional.

A continuación, detente antes de alcanzar el límite máximo, no justo al llegar a él. Operar al ritmo máximo que tolera un objetivo significa que cualquier fluctuación normal te hará sobrepasarlo. Dimensionar entre el 60 % y el 70 % del límite máximo medido te garantiza una tarea que se completa de forma fiable, en lugar de una que solo se completa cuando las condiciones son favorables.

Ejemplo práctico: Seguimiento diario de precios

La carga de trabajo más habitual, y aquella cuya respuesta más sorprende a la gente.

Requisito: 50 000 páginas de productos comprobadas una vez al día.

Límite máximo medido: el sistema admite aproximadamente una solicitud cada dos segundos desde una misma dirección antes de aplicar la limitación de frecuencia; digamos que son 1.800 solicitudes por hora.

Repartido a lo largo de 24 horas: 50 000 ÷ 24 ≈ 2 100 solicitudes por hora.

Direcciones necesarias: 2.100 ÷ 1.800 ≈ 1,2. Redondeando al alza y añadiendo un margen: de dos a cuatro direcciones.

Dos direcciones. Para cincuenta mil páginas al día, frente a un conjunto que se promociona por millones.

Ahora cambiemos una hipótesis. Supongamos que el trabajo debe completarse en un plazo de dos horas, en lugar de repartirse a lo largo del día:

Requisito: 50 000 páginas en 2 horas = 25 000 por hora. Direcciones necesarias: 25 000 ÷ 1 800 ≈ 14, más un margen: unas 20.

Mismo volumen, mismo objetivo, diez veces más direcciones —debido a una decisión de programación, no a un requisito de extracción de datos—.

Esa es la idea más útil de este artículo. El margen de tiempo que te concedes es la variable determinante. Antes de comprar más direcciones, pregúntate si el trabajo realmente tiene que terminarse rápido y cuánto vale esa rapidez. A menudo no vale nada en absoluto, porque los datos se consumen a la mañana siguiente.

Ejemplo práctico: comprobaciones geográficas

Una forma completamente diferente, y los cálculos se hacen al revés.

Requisito: comprobar los precios y la disponibilidad regionales en 30 mercados, cuatro veces al día, en 50 páginas por mercado.

Volumen: 30 × 4 × 50 = 6.000 solicitudes al día. Una bagatela.

Direcciones necesarias para el rendimiento: básicamente una. Seis mil solicitudes repartidas a lo largo de un día suponen una solicitud cada catorce segundos.

Direcciones necesarias para la cobertura: al menos una salida operativa en cada uno de los 30 países, en el momento en que la necesites.

Aquí la limitación no es en absoluto el volumen, sino la presencia. Lo que deberías evaluar es si el proveedor cuenta realmente con una cobertura fiable en los mercados específicos que necesitas, en los momentos en que operas, y no cuántas direcciones contiene el conjunto. Un conjunto de diez millones con una cobertura escasa en tres de tus mercados es peor que uno de diez mil que cubra los treinta.

Por eso «¿cuántas necesito?» es una pregunta errónea para el trabajo geográfico, y «¿a dónde se puede llegar de forma fiable y puedo probarlo?» es la correcta.

Ejemplo práctico: Trabajo basado en sesiones

El caso en el que la concurrencia y la identidad son lo mismo.

Requisito: gestionar 10 sesiones autenticadas en paralelo, cada una de las cuales realiza secuencias de varios pasos.

Direcciones necesarias: 10, y deben ser fijas —una dirección se mantiene durante toda la duración de cada sesión—.

El volumen es irrelevante en este caso. Lo que importa es que cada sesión tenga una identidad coherente: la misma dirección durante toda su duración, con la configuración regional y la zona horaria coincidentes. Una sesión cuyas peticiones procedan de cuatro países diferentes no es una sesión, es un patrón.

El error que hay que evitar es utilizar un punto final rotativo por solicitud para esto, que es la configuración predeterminada en la mayoría de las pasarelas. Las solicitudes se completan con éxito, se pierde el estado de la sesión y el síntoma parece un error de la aplicación hasta que alguien comprueba las direcciones de salida.

Ten en cuenta también que diez sesiones simultáneas no significan diez direcciones para siempre, sino diez a la vez. Una carga de trabajo que ejecute 200 sesiones de forma secuencial a lo largo del día solo necesita diez direcciones fijas, reutilizadas.

Por qué «más» no significa «más seguro»

La suposición en la que se basan la mayoría de las compras excesivas es errónea en tres aspectos concretos.

El bloqueo se realiza por subred, no por dirección. Los sitios suelen bloquear con una granularidad de /24. Cincuenta direcciones de un mismo bloque se comportan como una sola dirección cuando se bloquea dicho bloque, por lo que un gran conjunto de direcciones con una distribución deficiente no es realmente un gran conjunto en lo que realmente importa. La distribución es más importante que la cantidad, y ya hemos explicado el funcionamiento en ¿qué es un ID de subred?.

La señal es la frecuencia, no la identidad. Si tus solicitudes parecen automatizadas por su sincronización, sus encabezados o su huella TLS, distribuirlas entre más direcciones dispersa la señal sin eliminarla. Acabas marcando más direcciones en lugar de menos.

Las direcciones no utilizadas pierden vigencia. En un grupo rotativo, una dirección que no has utilizado no tiene ninguna relación con el objetivo, ni buena ni mala. Mantener «capacidad de reserva» no es acumular nada.

Hay una razón de peso para mantener más direcciones de las que requiere el rendimiento: la rotación. Si un objetivo marca direcciones con el tiempo, necesitas sustitutas para ir rotándolas. Ese es un requisito real, y su volumen viene determinado por la tasa de marcado observada más que por la intuición: mide cuántas direcciones se degradan al día y mantén una reserva para unos cuantos días.

Lo que realmente estás comprando

Vale la pena dejarlo claro, porque la respuesta varía según el modelo de precios y eso cambia incluso el significado de la pregunta.

En el modelo de precios por gigabyte, que es como se vende el tráfico residencial y, a menudo, el de los centros de datos, no estás comprando direcciones en absoluto. Lo que compras son datos, y el número de direcciones es una característica del fondo común, no de tu plan. Preguntar «¿cuántos proxies necesito?» en este contexto es un error de categoría: las preguntas reales son cuánto tráfico vas a transmitir y si el fondo común tiene cobertura donde la necesitas. Nuestro tráfico residencial empieza en 0,79 $/GB y el de centros de datos en 0,14 $/GB, según datos de septiembre de 2026 consultados en nuestra página de precios.

En cuanto a la tarificación por IP, que es como se venden los productos de los proveedores de servicios de Internet (ISP) y de muchos centros de datos, el recuento es, literalmente, lo que pagas, y todo este cálculo es una partida presupuestaria. La nuestra es de 1,25 $/IP. En este caso, la aritmética anterior se traduce en dinero, y merece la pena dedicar veinte minutos a hacerlo bien.

El modelo que más te convenga depende de la naturaleza de tu carga de trabajo más que de la tarifa nominal, y ambos aspectos no son comparables. Una carga de trabajo que requiera muchas direcciones favorece ligeramente la tarificación por tráfico; una que requiera pocas direcciones favorece claramente la tarificación por IP. Hemos analizado los cálculos en detalle en la guía de precios de proxies.

Reglas generales, con sus limitaciones

Si necesitas un punto de partida antes de realizar mediciones, estas son válidas. Tómalas como una primera aproximación que se sustituirá más adelante, no como una respuesta definitiva.

Dos cifras que conviene tener muy presentes. Casi ninguna carga de trabajo necesita más de unas pocas docenas de direcciones simultáneas, y las que realmente lo necesitan son o bien de carácter geográfico (muchas ubicaciones, con bajo volumen en cada una) o bien tienen un plazo autoimpuesto. Y lo que suele ser necesario modificar con mayor frecuencia no es el número de direcciones, sino el horario.

Señales de que has calculado mal la cifra

Demasiado poco se manifiesta así: aumento de los 429, aparición de errores, descenso de la tasa de éxito a medida que avanza la ejecución, y tareas que se completan más tarde de lo previsto. La solución es aumentar la concurrencia o ampliar el intervalo de tiempo.

Demasiado no se nota en nada. Por eso persiste el error. Un grupo de direcciones sobredimensionado no produce ningún síntoma en la tarificación por tráfico, por lo que nadie lo detecta. En la tarificación por IP, genera una factura, lo que al menos suscita la pregunta.

Dos situaciones que parecen «demasiado pocas» y no lo son:

Un grupo bloqueado. Si la tasa de éxito se desploma en todas las direcciones simultáneamente, añadir más no servirá de nada: algo ha cambiado en el destino, o el patrón de tus solicitudes está siendo identificado a través de una señal ajena a la dirección.

Un destino lento. Si las respuestas son lentas pero exitosas, una mayor concurrencia ayudará a aumentar el rendimiento hasta cierto punto y luego dejará de hacerlo. Mide las solicitudes completadas por segundo y deja de aumentar cuando esa cifra se estabilice, lo cual ocurrirá antes de lo esperado.

El diagnóstico general: aumenta la concurrencia por pasos y observa las respuestas útiles completadas por segundo. Aumenta, se estabiliza y luego cae. El punto óptimo es la estabilización, y suele ser una cifra menor de lo que nadie prevé.

Preguntas frecuentes

¿Cuántos proxies necesito para el web scraping?

Mide en lugar de adivinar: averigua la tasa de solicitudes a partir de la cual una sola dirección empieza a verse limitada en tu objetivo real, divide el rendimiento que necesitas por esa cifra y añade un margen. La mayoría de las cargas de trabajo se sitúan en cifras de un solo dígito o de dos dígitos bajos en cuanto a direcciones simultáneas, no en miles.

¿El uso de más proxies reduce la probabilidad de que me bloqueen?

Solo si el bloqueo es específico de una dirección. Si tus solicitudes se identifican como automatizadas por el tiempo de respuesta, la composición de los encabezados o la huella TLS, disponer de más direcciones distribuye la misma señal entre más direcciones de tu grupo, en lugar de evitarla. La frecuencia y la forma de las solicitudes importan más que el número.

¿Cuántos proxies se necesitan para 1 millón de solicitudes al día?

Depende totalmente del intervalo de tiempo. Si se distribuyen a lo largo de 24 horas, eso supone unas 12 solicitudes por segundo, lo que, a razón de una solicitud cada dos segundos por dirección, equivale aproximadamente a 25 direcciones simultáneas. Si se concentran en dos horas, la cifra se multiplica por doce. La variable es la distribución temporal, no el volumen.

¿Necesito un proxy por cuenta?

Para cualquier cosa basada en sesiones, una dirección fija por sesión simultánea —no por cuenta—. Diez cuentas gestionadas secuencialmente a lo largo del día solo necesitan diez direcciones si las diez están activas al mismo tiempo. Ten en cuenta que muchas plataformas prohíben explícitamente el uso de varias cuentas, así que comprueba los términos y condiciones antes de diseñar una estrategia en torno a ello.

¿Es mejor tener más direcciones IP o mejores direcciones IP?

«Mejores» significa que estén bien distribuidas entre subredes y sean adecuadas para el destino. El bloqueo suele producirse a nivel de /24, por lo que cincuenta direcciones de un mismo bloque se comportan como una sola. Un conjunto más pequeño y bien repartido ofrece mejores resultados que uno más grande y concentrado.

¿Cómo sé si tengo muy pocos proxies?

Aumento de los errores 429, aparición de páginas de verificación y disminución de la tasa de éxito a medida que avanza la ejecución. Si el éxito se desploma en todas las direcciones a la vez, se trata de un problema diferente: algo ha cambiado en el destino o tus solicitudes están siendo identificadas por una señal ajena a la dirección, y disponer de más direcciones no servirá de nada.

¿Influye el número de proxies en el precio?

En el modelo de precios por IP, sí, directamente: el número de direcciones es lo que compras. En el modelo de precios por gigabyte, en absoluto, porque pagas por los datos y el número de direcciones es una característica del conjunto. Por eso no se pueden comparar estos dos modelos basándose en las tarifas nominales.

¿Cuántos proxies se necesitan para la segmentación geográfica?

Una salida fiable por cada ubicación que necesites; el volumen suele ser irrelevante. La pregunta que debes hacerle a un proveedor no es cuántas direcciones tiene, sino si cuenta con una cobertura fiable en tus mercados específicos y si puedes probarla antes de comprometerte.

Conclusión

La cifra que necesitas se obtiene a partir de una medida y una división: averigua en qué punto una única dirección empieza a estar limitada en tu objetivo real y divide por ese valor tu requisito de rendimiento. Todo lo demás son ajustes.

La variable que determina el resultado no es el volumen, sino el margen que permites. Cincuenta mil páginas al día requieren un par de direcciones repartidas a lo largo de veinticuatro horas y veinte a lo largo de dos. Antes de adquirir capacidad para ir más rápido, comprueba si realmente hay algo que dependa de que el trabajo termine antes; a menudo no es así, y la optimización más barata disponible es la paciencia.

Y en el caso de los trabajos de carácter geográfico, la cuestión cambia por completo. El volumen es irrelevante, la presencia lo es todo, y lo que realmente importa es si un proveedor cubre de forma fiable tus mercados específicos, más que el tamaño de su red. Esto se puede comprobar en una prueba, lleva una tarde y te dirá más que cualquier cifra que un proveedor incluya en su página de inicio —incluida la nuestra—.