El proveedor promete "más de 10 millones de IP", pero en la práctica recibes la misma dirección cada pocos minutos. Esta es una situación clásica de cifras infladas en el marketing de servicios de proxy. Hay una forma simple y confiable de comprobar el tamaño real del pool: hacer una serie de solicitudes y contar cuántas IP únicas has recibido. En este artículo, analizaremos cómo hacerlo correctamente, sin errores que distorsionen el resultado.
Por qué comprobar el tamaño del pool de proxies
El tamaño del pool afecta directamente a la frecuencia con la que se repiten las direcciones IP en un gran número de solicitudes. Si eres un arbitrajista y gestionas 50 cuentas de Facebook Ads, una IP repetida en varios perfiles es un camino directo hacia el baneo en cadena de toda la serie de cuentas. Si eres un especialista en SMM y gestionas 30 cuentas de Instagram de clientes a través de Dolphin Anty, cada repetición de IP es un riesgo de vincular cuentas de diferentes clientes a los ojos del sistema antifraude de la plataforma.
Para los vendedores en Wildberries y Ozon, un pool real pequeño significa que el parser de precios de competidores rápidamente caerá bajo un límite de tasa o captcha: el sitio verá decenas de solicitudes desde la misma dirección y la bloqueará. Para los marketers que prueban la geotargeting de anuncios, es importante entender si las solicitudes realmente provienen de diferentes subredes y ciudades, y no de tres IP repetidas de un mismo centro de datos.
La comprobación toma de 10 a 15 minutos, y su resultado ahorra semanas de trabajo, que de otro modo se gastarían en desbloquear cuentas y averiguar por qué las "nuevas" IP resultaron ser viejos conocidos.
Por qué los proveedores inflan las cifras
El tamaño declarado del pool es a menudo el número total de direcciones que teóricamente están disponibles en la red del proveedor durante toda su existencia, incluyendo IP que hace tiempo no se asignan, están bloqueadas por plataformas objetivo o pertenecen a dispositivos inactivos en el caso de proxies residenciales y móviles. La muestra realmente disponible en el momento de tu solicitud puede ser mucho menor.
Hay otra razón: la rotación de IP en muchos proveedores funciona bajo el principio de "sesión - nueva IP", pero el pool de rotación puede estar limitado a un geo o subred específica del ISP. Si solicitas IP solo de EE. UU., y el pool general del proveedor se considera para todos los países a la vez, el número real de direcciones disponibles para ti puede diferir del publicitado por decenas de veces.
Es por eso que la prueba de 1000 solicitudes no es paranoia, sino una etapa obligatoria de la debida diligencia antes de construir un proceso de negocio en un proveedor de proxies con decenas de cuentas o un parser que funciona 24/7.
Método de comprobación: 1000 solicitudes y contador de IP únicas
La lógica del método es simple: haces N solicitudes a un servicio que devuelve tu IP externa actual (por ejemplo, httpbin.org/ip o api.ipify.org), en cada solicitud el proxy debe cambiar la IP de acuerdo a tus configuraciones de rotación. Todas las direcciones obtenidas se acumulan en un conjunto (set), que automáticamente filtra duplicados. Al final, divides el número de IP únicas por el número total de solicitudes: este es el coeficiente real de unicidad del pool.
Para una prueba correcta, son importantes tres condiciones:
- Las solicitudes deben hacerse con un intervalo que corresponda al escenario real de uso: no debes hacer 1000 solicitudes en 3 segundos, si en el trabajo real cambias IP cada 5 minutos;
- Cada solicitud debe iniciar una nueva sesión de proxy (para proxies residenciales y móviles, esto generalmente significa un nuevo token de sticky-session o la recreación completa de la conexión);
- Debes probar exactamente el geo y tipo de proxy que planeas usar en producción: una prueba en el pool general no mostrará la situación real para un país específico.
El número 1000 no se elige al azar: es una muestra suficiente para la significancia estadística del resultado, al mismo tiempo que la prueba se realiza en un tiempo razonable y no crea una carga excesiva para el proveedor.
Script listo en Python para la prueba
A continuación, un script funcional que realiza 1000 solicitudes a través de un proxy y cuenta IP únicas. Reemplaza las variables PROXY_HOST, PROXY_PORT, PROXY_USER y PROXY_PASS con los datos de tu panel personal de tu proveedor de proxies.
import requests
import time
from collections import Counter
PROXY_HOST = "proxy.example.com"
PROXY_PORT = "8000"
PROXY_USER = "login"
PROXY_PASS = "password"
proxy_url = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
proxies = {"http": proxy_url, "https": proxy_url}
TOTAL_REQUESTS = 1000
DELAY_SECONDS = 0.5 # pausa entre solicitudes
ip_counter = Counter()
errors = 0
for i in range(TOTAL_REQUESTS):
try:
response = requests.get(
"https://api.ipify.org?format=json",
proxies=proxies,
timeout=10
)
ip = response.json().get("ip")
ip_counter[ip] += 1
except Exception as e:
errors += 1
time.sleep(DELAY_SECONDS)
unique_ips = len(ip_counter)
success_requests = TOTAL_REQUESTS - errors
uniqueness_ratio = unique_ips / success_requests if success_requests else 0
print(f"Solicitudes exitosas: {success_requests}")
print(f"Errores: {errors}")
print(f"IP únicas: {unique_ips}")
print(f"Coeficiente de unicidad: {uniqueness_ratio:.2%}")
print("Top-5 IP más repetidas:")
for ip, count in ip_counter.most_common(5):
print(f" {ip}: {count} veces")
El script también muestra el top de IP repetidas: esto es útil para entender si hay una o dos direcciones que "se quedan pegadas" y son proporcionadas por el proveedor de manera anómala frecuente. Si hay tales direcciones y su proporción es mayor al 5-7% de todas las solicitudes, es una señal de problemas con la rotación en el lado del proveedor.
Comprobación rápida a través de cURL sin código
Si no quieres escribir un script, puedes hacer una comprobación simplificada a través de la terminal. El siguiente comando en bash hará 50 solicitudes y guardará todas las IP obtenidas en un archivo, lo que proporciona una evaluación rápida sin instalar Python:
for i in {1..50}; do
curl -s -x "http://login:[email protected]:8000" \
https://api.ipify.org >> ip_list.txt
echo "" >> ip_list.txt
sleep 0.5
done
sort ip_list.txt | uniq -c | sort -nr
El comando sort | uniq -c mostrará una lista de IP únicas con el número de repeticiones de cada una: este es el mismo principio que en el script de Python, pero sin escribir un programa. Para una comprobación rápida, 50-100 solicitudes son suficientes para notar problemas evidentes con la rotación.
Cómo interpretar los resultados de la prueba
El coeficiente de unicidad depende del tipo de proxy. No debes esperar un 100% de unicidad de proxies de centros de datos baratos y no debes asustarte si los proxies residenciales muestran un poco menos del 95%: algunos proveedores utilizan pools con geo limitado, donde físicamente no puede haber un número ilimitado de IP domésticas.
| Tipo de proxy | Unicidad esperada en 1000 solicitudes | Evaluación |
|---|---|---|
| Proxies residenciales | 90-99% | Norma |
| Proxies móviles | 70-95% | Norma (depende de la densidad de operadores en el geo) |
| Proxies de centros de datos | 50-90% | Norma, pero depende del pool declarado de una subred específica |
| Cualquier tipo | menos del 30% | Problema: el pool está muy inflado en la publicidad o la rotación está rota |
Además del coeficiente general, observa la distribución: si 900 de 1000 solicitudes dieron diferentes IP, y 100 solicitudes fueron a la misma dirección, esto es peor que una distribución uniforme con el mismo coeficiente promedio. La uniformidad es más importante que el porcentaje general de unicidad, especialmente para tareas de multi-cuentas, donde cada vinculación repetida de IP a un perfil es crítica.
Comprobación del pool en Dolphin Anty y AdsPower sin código
Si no deseas trabajar con scripts, los navegadores anti-detección ofrecen herramientas integradas para una comprobación similar, aunque a menor escala. En Dolphin Anty, abre la sección "Proxies" → selecciona el proxy deseado → presiona el botón de comprobación de IP varias veces seguidas con un intervalo de un par de minutos y registra el resultado manualmente en una tabla. En AdsPower, de manera similar: en la sección de gestión de proxies hay un botón "Check", que muestra la IP actual, el país y el proveedor de la red: las comprobaciones repetidas con intervalo mostrarán si la dirección cambia.
Este método manual es adecuado para una comprobación rápida y selectiva antes de comprar un gran volumen de proxies, pero no reemplaza una prueba completa de 1000 solicitudes si planeas escalar el proceso a decenas o cientos de cuentas. Para una comprobación seria antes de un uso a largo plazo, es mejor ejecutar el script de la sección anterior y obtener datos estadísticamente significativos.
Errores comunes al probar el pool
El primer error es hacer solicitudes demasiado rápido, sin pausas. Algunos proveedores devuelven la misma IP dentro de una ventana de tiempo corta intencionadamente (sesión pegajosa), y una prueba rápida sin pausas mostrará una unicidad distorsionadamente baja, aunque en los intervalos reales de uso todo esté bien.
El segundo error es probar a través de un servicio de comprobación de IP que en sí mismo almacena en caché las respuestas o devuelve geolocalización en lugar de la dirección real. Utiliza servicios probados como ipify.org o httpbin.org/ip, que devuelven JSON limpio sin almacenamiento en caché de su lado.
El tercer error es no tener en cuenta los tiempos de espera y errores de conexión en la estadística general. Si 200 de 1000 solicitudes terminaron con error, y cuentas la unicidad a partir de 1000, en lugar de 800 exitosas, el coeficiente resultará distorsionado en el peor de los casos.
El cuarto error es probar un geo que realmente no necesitas en el trabajo. El pool puede ser enorme a nivel global, pero diminuto para una ciudad o estado específicos: y precisamente el geo local es a menudo crítico para la publicidad geotargeted o SMM local.
Qué hacer si el pool resultó pequeño
Si la prueba mostró un bajo coeficiente de unicidad, el primer paso es escribir al soporte del proveedor con cifras específicas de la prueba y pedir que expliquen la razón. Los proveedores de buena fe suelen explicar de manera transparente la estructura del pool por geo y tipo de proxy y pueden ofrecer una muestra más ajustada, pero realmente funcional.
La segunda opción es reconsiderar el tipo de proxy para la tarea. Para la creación de cuentas y el trabajo con plataformas publicitarias, a menudo es más efectivo no aumentar la intensidad de rotación de IP de centros de datos, sino cambiar a proxies residenciales o móviles, donde la propia naturaleza de la red proporciona una distribución de direcciones más natural y menor visibilidad para los sistemas antifraude.
La tercera opción es reducir la carga en el pool: aumentar el intervalo entre cambios de IP, distribuir tareas entre varias subredes o geos, si la plataforma permite trabajar no desde un país específico. A veces, la solución no está en aumentar el pool, sino en cambiar el patrón de solicitudes para que se ajuste al volumen realmente disponible de direcciones únicas.
Conclusión
La prueba de 1000 solicitudes con el conteo de IP únicas es una forma rápida y objetiva de comprobar si el pool real de proxies corresponde a las cifras declaradas por el proveedor. Un script listo en Python o una comprobación simplificada a través de cURL requieren un mínimo de tiempo, y el resultado ayuda a evitar baneos de cuentas, bloqueos al parsear marketplaces y gastos innecesarios en proxies que no se ajustan a la tarea.
Si planeas crear cuentas publicitarias de Facebook Ads o TikTok Ads, gestionar decenas de perfiles de Instagram a través de Dolphin Anty o AdsPower, presta atención a proxies móviles: suelen mostrar una distribución de IP más natural y caen menos bajo los sistemas antifraude de las plataformas. Para parsear precios en Wildberries y Ozon o tareas donde la velocidad y estabilidad son importantes, vale la pena probar proxies residenciales con el método de este artículo antes de construir un proceso de trabajo permanente sobre ellos.