La velocidad de un proxy no es un solo número: es latencia (cuánto tarda en llegar el primer byte), rendimiento (a qué velocidad llegan los bytes) y tasa de éxito (con qué frecuencia obtienes una respuesta utilizable) — y cada uno varía según la hora, el objetivo y la IP de salida. Una sola prueba en un momento dado no te dice casi nada, por eso los números de marketing de los proveedores y las reseñas puntuales son tan fáciles de producir y tan difíciles de usar. Este es el método que usamos para nuestras propias clasificaciones: qué medir, cómo, con qué frecuencia y cómo resumirlo para que el resultado signifique algo.

Los cuatro números

MétricaQué respondeCómo obtenerlaValor bueno típico
Latencia (TTFB)Cuánto espera cada solicitud antes de que comiencen los datoscurl -w %{time_starttransfer} en un recurso pequeñoDatacenter: +10–50 ms sobre directo; residencial/móvil: +80–300 ms
RendimientoQué tan rápido se mueven los datos masivosMide el tiempo de una descarga de tamaño fijo (1–10 MB)Datacenter: cerca de la velocidad de línea; residencial: 5–50 Mbit/s; móvil: 5–30 Mbit/s
Tasa de éxitoCon qué frecuencia una solicitud se completa con un 2xx realCuenta los resultados de muchas solicitudes>98% en objetivos neutrales; más bajo en objetivos protegidos es culpa del objetivo
Tiempo de actividadCon qué frecuencia el proxy es alcanzable en absolutoSonda de conectividad periódica durante días>99.5% para datacenter/ISP; los pools rotativos enmascaran cortes individuales

Los informes que dan una sola cifra de “velocidad” suelen informar el rendimiento en una descarga grande desde un proxy de datacenter en una hora tranquila — la combinación más favorecedora posible.

Principios antes que comandos

  1. Mide la diferencia, no el absoluto. Siempre ejecuta la misma solicitud directa y a través del proxy, una tras otra, e informa el delta. De lo contrario, la variabilidad de tu propia conexión se mezcla con la del proxy.
  2. Mismo objetivo, siempre. Usa un endpoint pequeño, rápido y estable que no limite la velocidad — un archivo estático en un CDN importante, o tu propio servidor. Nunca hagas benchmark contra el sitio que pretendes hacer scraping; su respuesta anti-bot es una medición diferente.
  3. Muchas muestras, distribuidas en el tiempo. Al menos 20 solicitudes por ejecución; ejecuciones en varias horas del día y a lo largo de una semana. Los proxies son infraestructura compartida y la carga sigue las horas de negocio en las regiones del proveedor y de las IPs de salida.
  4. Informa percentiles, no promedios. Un timeout de 30 segundos destruye una media. La mediana (p50) te dice la experiencia típica; p95 te dice la experiencia en un mal día; ambos importan más que el promedio.
  5. Calienta. Descarta la primera solicitud de cada ejecución — la configuración de DNS y sesión TLS la hace más lenta que el resto.
  6. Cambia una cosa a la vez. Comparar el datacenter del proveedor A con el residencial del proveedor B compara tipos, no proveedores.

Latencia con curl

# directo
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# con proxy
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

A través de un proxy, time_connect es el tiempo para llegar al proxy; el connect y TLS del destino ocurren dentro del túnel y se reflejan en time_appconnect/time_starttransfer. El número a comparar es ttfb: proxied menos directo es la latencia añadida por el proxy. Haz un bucle:

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

Rendimiento

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

Usa un archivo lo suficientemente grande para que la configuración de la conexión sea una fracción pequeña (5–10 MB), pero lo suficientemente pequeño para no gastar la asignación residencial por GB en muchas ejecuciones. En pools rotativos, el rendimiento varía con la conexión del host de salida; ejecuta suficientes muestras para ver la distribución, y recuerda que en planes por GB, el rendimiento también determina qué tan rápido gastas dinero.

Tasa de éxito

Cada solicitud termina en uno de: un 2xx con un cuerpo del tamaño esperado; un 4xx/5xx del objetivo; un error del proxy (407, conexión rechazada, timeout); o una página de desafío (CAPTCHA/interstitial) con estado 200 — el último es el que los contadores ingenuos pasan por alto, así que verifica el cuerpo, no solo el código. En Python:

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

Separa los fallos del proxy (407, errores de conexión, timeouts al proxy) de los fallos del objetivo (403, 429, desafíos). Los primeros son problema del proveedor; los segundos son sobre la reputación de la IP en ese objetivo y pertenecen a una prueba diferente — ver cómo los sistemas anti-bot puntúan las solicitudes.

Tiempo de actividad

El tiempo de actividad es la tasa de éxito a lo largo del tiempo calendario. Programa una sonda ligera — el comando de latencia anterior, o un CONNECT simple — cada 5–15 minutos durante al menos una semana, registra el resultado con una marca de tiempo y calcula la fracción de sondas que tuvieron éxito. Dos sutilezas:

  • Los pools rotativos ocultan cortes. Si una salida muere, obtienes otra; el gateway en sí es lo que tiene tiempo de actividad. Prueba el gateway y, por separado, rastrea con qué frecuencia cambia la IP asignada cuando pediste una sesión fija — un cambio inesperado es un corte suave.
  • Las IPs estáticas (datacenter, ISP) son para las que normalmente se afirma “99.9%”. 99.9% es 43 minutos de inactividad al mes; 99.5% es 3.6 horas. Ambos son fáciles de distinguir con una semana de sondas de 15 minutos.

Programando las ejecuciones

Un horario mínimo pero significativo: latencia + éxito (20–50 solicitudes) a las 03:00, 09:00, 14:00 y 20:00 en la hora local de las IPs de salida, todos los días durante siete días; rendimiento una vez por ejecución; una sonda de conectividad cada 15 minutos durante todo el tiempo. Eso son unos pocos cientos de kilobytes al día por proxy para latencia y unas decenas de megabytes para rendimiento — asequible incluso en planes por GB si usas un archivo pequeño. Ejecútalo desde una máquina que permanezca encendida (un VPS pequeño es ideal) con cron, y escribe una línea CSV por solicitud. Nuestras clasificaciones publicadas — por ejemplo, la clasificación de velocidad y la clasificación de fiabilidad — se construyen exactamente con este tipo de series de una semana, no con una sola tarde.

Interpretando los resultados

  • Latencia p50 cercana a la norma del tipo y p95 dentro de ~3× p50: saludable. Un p95 muchas veces el p50 significa congestión intermitente — el proveedor está sobresuscrito en horas punta.
  • Tasa de éxito por debajo de ~97% en un objetivo neutral debido a errores del lado del proxy: problema de infraestructura, no tuyo.
  • Mucho peor de día que de noche: capacidad compartida; pregunta por opciones dedicadas o acéptalo en la programación.
  • Grandes números en datacenter, pobres en residencial del mismo proveedor: normal — productos diferentes; compara residencial con residencial.
  • Tiempo de actividad por debajo de lo afirmado: ahora tienes un registro para mostrar al soporte, que vale más que una queja.

Finalmente, ten en cuenta el tipo. Los proxies residenciales y móviles son más lentos por construcción — el tráfico realmente atraviesa una línea doméstica o una torre de telefonía — y comprarlos por velocidad es un error de categoría; ver la comparación de tipos de proxy. Mídelos contra su propia clase y contra lo que tu tarea realmente necesita. Ten en cuenta también que una conexión proxied usa HTTP/2, no HTTP/3, así que compara cosas similares cuando la línea base directa esté en un sitio con QUIC habilitado (detalles).

Preguntas frecuentes

¿Cómo pruebo la velocidad de un proxy?

Solicita el mismo recurso pequeño directamente y a través del proxy, muchas veces, a varias horas del día; compara el tiempo hasta el primer byte (latencia) y, por separado, mide el tiempo de una descarga de tamaño fijo (rendimiento). Informa medianas y percentiles 95, no promedios.

¿Cuál es una buena latencia de proxy?

Relativa a una conexión directa: los proxies de datacenter añaden decenas de milisegundos; los residenciales y móviles añaden aproximadamente 80–300 ms porque el tráfico pasa por una conexión de consumo. Juzga cada tipo contra su propia norma.

¿Cómo verifico el tiempo de actividad de un proxy?

Pruébalo en un horario (cada 5–15 minutos) durante al menos una semana, registra cada resultado y calcula la fracción de sondas exitosas. Para pools rotativos, prueba el gateway; para IPs estáticas, prueba la IP misma.

¿Por qué mis resultados difieren de las afirmaciones del proveedor?

Las afirmaciones suelen ser el mejor caso: producto de datacenter, hora tranquila, descarga grande, muestra única. Tu medición incluye horas punta, las IPs de salida específicas que recibes y percentiles. El tuyo es el número que predice tu experiencia.

¿Debo hacer benchmark contra el sitio que quiero hacer scraping?

No para velocidad. Su capa anti-bot añadirá desafíos y bloqueos que miden la reputación de la IP, no el rendimiento del proxy. Usa un recurso estático neutral para velocidad y ejecuta pruebas de reputación por separado.

¿Cuántas muestras necesito?

Al menos 20 por ejecución para obtener una mediana estable, varias ejecuciones al día durante una semana para ver efectos de hora del día y día de la semana. El tiempo de actividad necesita la semana de todos modos.