La latencia y la velocidad de un proxy son, quizá, las dos métricas más decisivas a la hora de elegir proveedor. Y sin embargo, muchas veces se compran proxies «a ciegas», confiando en lo que dice la web del vendedor. En este artículo te enseñamos a medir por tu cuenta, con scripts de benchmark en Python, el rendimiento real de un proxy: tiempo de conexión, TTFB (Time To First Byte) y throughput de descarga. Podrás aplicar estas pruebas tanto a proxies HTTP/s como SOCKSv5, comparar varios proveedores de forma objetiva y detectar cuellos de botella antes de que afecten a tu SEO, tu scraping o tus agentes de IA.
Por qué medir la latencia y velocidad de un proxy antes de comprarlo
Un proxy lento arruina cualquier proyecto. No exagero: un crawler que tarda 8 segundos por página en lugar de 1,5 puede multiplicar por cinco el tiempo de una auditoría SEO, y un agente de IA que dependa de ese proxy verá degradadas sus respuestas en tiempo real. ¿Dónde se nota la latencia? Aquí:
- Scraping masivo: con 10.000 peticiones diarias, pasar de 300 ms a 1.200 ms de latencia significa más de 2,5 horas extra de procesamiento al día. Cada día.
- Verificación de anuncios y SERPs: los timeouts provocan huecos en tus datos y falsos errores que ensucian los informes.
- Agentes IA con soporte MCP: si tu agente encadena llamadas a través del proxy, cada milisegundo se acumula en el coste total de la operación.
Hay algo más. Medir antes de comprar te permite detectar problemas típicos: saturación del nodo en horas punta, rutas de red subóptimas (el clásico proxy «español» que en realidad hace routing por Frankfurt) o limitaciones ocultas de ancho de banda. Por eso en ProxySEO publicamos nuestras métricas de latencia media y ofrecemos proxies dedicados con IPs españolas y tráfico ilimitado, para que puedas benchmarkearlos tú mismo antes de comprometerte. Que las cifras las pongas tú, no el marketing.
Preparando el entorno: librerías Python y proxies de prueba
Necesitarás Python 3.9 o superior y estas librerías, instalables con un simple pip install requests aiohttp statistics (statistics ya viene incluida en la librería estándar):
- requests: para pruebas síncronas simples y medición de TTFB vía stream=True.
- aiohttp: para benchmarks concurrentes que simulen carga real.
- statistics: para calcular media, mediana y desviación típica de tus mediciones.
También conviene preparar una lista de URLs de prueba estables y ligeras, como https://httpbin.org/get o https://www.google.com/generate_204, que devuelven respuestas mínimas y no penalizan el resultado con contenido pesado. Un consejo práctico: si vas a testear proxies SOCKSv5, añade también PySocks (pip install requests[socks]) para que requests soporte el esquema socks5://.
Tip: si tu proveedor ofrece credenciales de prueba, genera 3-5 proxies distintos y mide todos. Un solo proxy puede haber pillado un nodo en mal momento; el patrón entre varios te da la imagen real del servicio.
Una última cosa antes de empezar: verifica que tu conexión local sea estable. Una caída de tu propia red contaminará todas las mediciones y te hará culpar injustamente al proxy. Ha pasado más veces de las que uno querría admitir.
Script de benchmark para medir latencia (ping, TTFB y tiempo de conexión)
Este primer script mide, para cada petición a través del proxy, el tiempo de conexión TCP, el TTFB y el tiempo total, haciendo 10 iteraciones por proxy:
Código de medición síncrona
La idea clave es usar requests.get(…, stream=True) para separar el tiempo hasta las cabeceras (TTFB) del tiempo de descarga completa. Los pasos:
- Define un diccionario proxies = {«http»: «http://usuario:password@ip:puerto», «https»: «http://usuario:password@ip:puerto»}.
- Lanza la petición con stream=True y cronometra con time.perf_counter().
- Registra el TTFB justo después de response.raw.read(1) o accediendo a las cabeceras.
- Calcula el tiempo de conexión restando el TTFB del tiempo hasta la respuesta, o usa una sesión con session.get() sin pool para forzar conexión nueva en cada iteración.
- Acumula los resultados en una lista y calcula media y mediana con statistics.mean() y statistics.median().
Importante: usa siempre perf_counter() y no time.time(). El primero tiene mayor resolución y no depende del reloj del sistema, algo crítico cuando mides diferencias de milisegundos en la latencia de un proxy.
Un ejemplo simplificado del núcleo del script sería:
import requests, time, statistics
proxies = {«https»: «http://user:pass@ip-proxy:puerto»}
ttfbs = []
for i in range(10):
inicio = time.perf_counter()
r = requests.get(«https://www.google.com/generate_204», proxies=proxies, stream=True, timeout=10)
r.raw.read(1)
ttfbs.append((time.perf_counter() – inicio) * 1000)
print(f»TTFB medio: {statistics.mean(ttfbs):.0f} ms | Mediana: {statistics.median(ttfbs):.0f} ms»)
Con este primer bloque ya tienes la mitad de la ecuación: la latencia. En la siguiente parte del artículo completaremos el análisis con un script asíncrono para medir el throughput de descarga y una plantilla de interpretación de resultados.
Script de benchmark para medir velocidad de descarga real (throughput)
La latencia te dice lo rápido que responde el proxy en el primer byte. Bien. Pero para scraping masivo, descarga de ficheros o agents IA que procesan volumen, lo que de verdad importa es otra cosa: el throughput, los megabits por segundo sostenidos durante toda la conexión. Para medirlo de forma asíncrona y con concurrencia real, aiohttp va como anillo al dedo:
La idea del script es sencilla: descargas un fichero de prueba de tamaño conocido (por ejemplo, 10 MB desde un endpoint estable como el test de velocidad de Cloudflare) a través de cada proxy, con 5 descargas paralelas por proxy, y calculas los Mbps efectivos. Algunos detalles a vigilar:
- Configuración del proxy: en aiohttp se define con aiohttp.ProxyConnector o pasando la URL del proxy a proxy= en la petición. ¿SOCKS5? Necesitarás aiohttp-socks, que funciona igual cambiando el conector.
- Cálculo del throughput: lee la respuesta en chunks de 64 KB, acumula los bytes con response.content.read() y divide entre el tiempo transcurrido. Multiplica por 8 para pasar de MB/s a Mbps.
- Concurrencia: lanza las descargas con asyncio.gather() para simular carga real; un proxy dedicado de calidad apenas debería degradar el resultado individual.
- Métrica de salida: reporta la media y el mínimo de Mbps. Ojo al mínimo. Un proxy con picos buenos pero caídas graves te arruinará las tareas de larga duración.
Con ambos scripts (latencia síncrona + throughput asíncrono) tienes una foto completa. Y si automatizas los tests con cron o como paso previo en tu pipeline, detectarás las degradaciones antes de que afecten a tus campañas. Quien use ProxySEO puede integrarlos sin cambios gracias al soporte MCP para agentes IA: se lanza el benchmark desde el propio agente y las métricas llegan en formato estructurado.
Comparando proxies HTTP/s y SOCKS5: cómo interpretar los resultados
Con los números sobre la mesa, toca interpretarlos. ¿Qué patrones son normales? Estos, más o menos:
- Latencia HTTP/s ligeramente menor: el protocolo HTTP está optimizado para tráfico web y el handshake es más directo. Diferencias de 5-15 ms son lo habitual.
- SOCKS5 más versátil pero algo más lento en el primer byte: al operar a nivel de transporte soporta cualquier tipo de tráfico (no solo HTTP), a cambio de una sobrecarga mínima.
- Throughput casi idéntico: una vez establecida la conexión, la velocidad de descarga depende más del ancho de banda del proveedor y de la saturación que del protocolo en sí.
Un criterio práctico para decidir: si trabajas con tráfico web y SEO (verificaciones de SERP, rank tracking, monitorización de anuncios), el proxy HTTP/s dedicado suele ser la opción más eficiente. ¿Necesitas tráfico no HTTP, P2P o clientes sin autenticación a nivel de aplicación? Entonces SOCKS5.
Umbral de referencia: latencia por debajo de 100 ms y throughput superior al 80% de tu línea sin proxy son cifras excelentes. Si un proxy se desvía mucho de su línea base habitual durante días, pide un cambio de IP.
Conclusión: monitoriza siempre la latencia y velocidad de un proxy
Medir la latencia y velocidad de un proxy no es algo que se haga una vez y ya está. Es un proceso continuo, y es justamente lo que separa a los profesionales serios del marketing digital de los aficionados. Los dos scripts que hemos visto —uno síncrono para TTFB y otro asíncrono para throughput— te dan una base sólida y reproducible para evaluar cualquier proveedor con datos objetivos. No con promesas de landing page.
Me quedo con unos cuantos puntos clave: mide siempre varias veces y usa la mediana para filtrar outliers, compara contra tu línea base sin proxy, automatiza los tests periódicamente y combina ambas métricas. Un proxy con 20 ms de latencia y 2 Mbps de descarga es tan inútil como uno rápido pero errático. Y sobre todo, elige un proveedor que rinda igual de bien en la práctica: con los proxies dedicados, anónimos y de IP española de ProxySEO.es, con tráfico ilimitado y soporte para HTTP/s y SOCKSv5 (además de integración MCP para tus agentes IA), los números de tus benchmarks hablarán solos.