Prueba de Velocidad de Proxy: Una Guía Práctica para 2026

Tu proxy pasó el verificador. Devolvió una IP. Incluso cargó una página.

Luego tu automatización comenzó a fallar.

Ese vacío es donde la mayoría de las pruebas de velocidad de proxy fallan. Una sola solicitud exitosa no te dice casi nada sobre si un proxy puede sobrevivir a flujos de inicio de sesión, cargas de página repetidas, solicitudes pesadas en medios o patrones de navegación similares a los de una aplicación móvil. Esto es aún más obvio con proxies móviles, donde la rotación, las condiciones de radio y el uso compartido pueden cambiar la forma del tráfico de un minuto a otro.

Si estás ejecutando creación de cuentas, calentamiento, verificaciones de anuncios, QA geográfico o flujos de trabajo en redes sociales, no necesitas un número de velocidad vanidoso. Necesitas un método de prueba que muestre si un proxy sigue siendo utilizable cuando la tarea se vuelve real.

Por qué tu prueba de velocidad de proxy probablemente esté equivocada

Sigue siendo común probar proxies como si fuera una pregunta binaria. Funciona o no funciona. Esa mentalidad está desactualizada.

Las pruebas modernas de proxy han pasado de una simple verificación de conectividad a un flujo de trabajo de medición más amplio que incluye el tiempo de carga de página, verificaciones de anonimato y pruebas por lotes. El punto más amplio es operativo. Los equipos necesitan mediciones repetibles para el tiempo de actividad, el tiempo de respuesta y las tasas de error, no un éxito afortunado en un verificador público, como se señala en esta visión general de los flujos de trabajo de verificación de proxies en línea.

Una marca de verificación verde no es un resultado de rendimiento

Un proxy puede pasar una prueba básica y aún así ser malo para producción. Eso sucede todo el tiempo con:

• Tareas pesadas en inicio de sesión donde la conexión TCP inicial funciona, pero las solicitudes posteriores se ralentizan lo suficiente como para activar reintentos o verificaciones de comportamiento sospechoso.
• Puntos finales móviles rotativos donde una solicitud aterriza en una ruta limpia y la siguiente toma un camino diferente con diferente latencia.
• Puertos compartidos donde el tráfico de otro usuario cambia tu experiencia sin previo aviso.
• QA geográfico sensible donde el sitio de destino es accesible, pero los activos de la página, scripts o llamadas a la API se cargan de manera inconsistente a través de la ruta.

Si tu prueba termina después de "la solicitud tuvo éxito", solo has confirmado que el proxy no estaba muerto por un momento.

Regla práctica: Si tu aplicación realiza más de una solicitud por acción de usuario, una prueba de velocidad de proxy de una sola solicitud es demasiado superficial.

Los proxies móviles hacen que las pruebas débiles se vean mejor de lo que son

Los proxies móviles son a menudo más tolerantes desde una perspectiva de confianza en plataformas sociales, pero eso no significa que se comporten como una infraestructura cableada. Una buena ruta móvil puede parecer más lenta en un benchmark genérico mientras sigue entregando mejores resultados en la plataforma que una ruta más rápida y menos confiable.

Esa distinción importa en flujos de trabajo al estilo de Instagram. La pregunta no es solo cuán rápido se mueven los bytes. La pregunta clave es si la sesión se completa de manera limpia, si las transiciones de página se mantienen estables y si el proxy evita que la plataforma aumente la fricción.

El objetivo de prueba incorrecto crea confianza falsa

Muchas pruebas de proxy apuntan a un punto final genérico que no tiene nada que ver con la carga de trabajo real. Eso produce números, pero no números de calidad para la toma de decisiones.

Una prueba útil refleja el destino y el comportamiento:

• Misma región que la plataforma objetivo o la página de destino
• Mismo protocolo que usa tu aplicación
• Mismo patrón de solicitud que genera tu automatización
• Mismo tiempo de sesión que esperas en producción

Cuando los equipos tratan el QA de proxies como una disciplina continua en lugar de una verificación única, dejan de preguntar "¿está vivo este proxy?" y comienzan a preguntar "¿es este proxy adecuado para este trabajo?"

Ahí está la diferencia entre una lista de proxies y un sistema de proxies.

Elegir tus métricas clave de rendimiento

Antes de ejecutar una prueba de velocidad de proxy, define lo que significa "suficientemente rápido" para tu carga de trabajo. Los usuarios a menudo saltan directamente a la velocidad de descarga porque es fácil de entender. Para la automatización y el uso de proxies móviles, eso generalmente no es el principal cuello de botella.

Latencia para acciones interactivas

La latencia es el retraso antes de que el lado remoto comience a responder. En la práctica, a menudo es la señal más clara para el trabajo interactivo.

Si estás abriendo feeds, avanzando en la configuración de cuentas, revisando vistas previas de anuncios o ejecutando automatización de navegador con muchas solicitudes pequeñas, la alta latencia se acumula rápidamente. Un viaje de ida y vuelta lento puede parecer inofensivo. Un flujo de página completo puede contener muchos de ellos.

Usa la latencia como una métrica principal cuando la tarea sea densa en solicitudes en lugar de pesada en ancho de banda.

Buen ajuste para pruebas centradas en latencia:

• Calentamiento de cuentas: Las acciones secuenciales se descomponen cuando cada paso espera demasiado.
• Simulación de navegación social: Las cargas de feed dependen de muchas llamadas pequeñas, no de una gran transferencia.
• Verificaciones de QA geográfico: Quieres que la ruta se sienta lo suficientemente estable como para inspeccionar el comportamiento de la página, no solo para obtener HTML.

Rendimiento para trabajo pesado en carga útil

El rendimiento mide cuántos datos puede transportar el proxy a lo largo del tiempo. Es importante, pero principalmente cuando el tamaño de la carga útil es el problema.

Si estás validando páginas pesadas en medios, recopilando cuerpos de respuesta grandes o moviendo muchos activos a través de la ruta, el bajo rendimiento se vuelve visible. Sin embargo, para muchas tareas en redes sociales, el rendimiento es secundario a la consistencia.

Un proxy con rendimiento modesto aún puede funcionar bien para automatización basada en sesiones si sus respuestas son constantes y su configuración de conexión es limpia.

Tiempo de conexión y tasa de éxito para la realidad

La mayoría de las pruebas serias deberían priorizar aspectos como conexiones confiables y secuencias de solicitudes completas. La velocidad bruta no te dice si el proxy se conecta de manera confiable o completa secuencias de solicitudes completas sin romperse.

Un marco práctico:

Prueba para el modo de falla que realmente te importa. Si las solicitudes bloqueadas te perjudican más que las páginas lentas, haz que la tasa de éxito sea la métrica principal.

Empareja la métrica con la tarea

No trates cada flujo de trabajo de la misma manera. Un benchmark limpio de proxy comienza con la carga de trabajo.

• Para automatización de navegador: prioriza latencia, tiempo de conexión y éxito repetido.
• Para recuperación de contenido masivo: prioriza rendimiento y comportamiento de tiempo de espera.
• Para operaciones de cuentas en proxies móviles: prioriza la estabilidad de la sesión y si la ruta sigue siendo utilizable a través de acciones repetidas en sitios reales.
• Para verificación de anuncios y pruebas geográficas: prioriza la finalización de la página, la carga de activos y la consistencia a través de múltiples ejecuciones.

La prueba de velocidad de proxy más sólida no es la que tiene más columnas. Es la que se mapea directamente a la tarea que necesitas mantener activa.

Métodos prácticos de línea de comandos para pruebas precisas

Un proxy puede verse bien en un verificador de navegador y aún así fallar en el trabajo que más te importa. Eso sucede todo el tiempo con proxies móviles. Un solo acceso rápido a una URL de prueba dice muy poco sobre si una ruta 4G seguirá siendo utilizable a través de acciones repetidas en Instagram, sobrevivirá a una rotación o se mantendrá cuando varios trabajadores compartan el mismo puerto.

Comienza con curl y registra los campos correctos

curl es el primer paso correcto porque expone los tiempos que importan y mantiene la prueba fácil de repetir.

Usa un comando como este:

curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w 'code=%{http_code} connect=%{time_connect} starttransfer=%{time_starttransfer} total=%{time_total} size=%{size_download} speed=%{speed_download}\n' \
  https://TARGET_URL

Esos campos responden a diferentes preguntas:

• time_connect muestra la velocidad del apretón de manos del proxy.
• time_starttransfer muestra la espera del servidor más cualquier retraso introducido por la ruta.
• time_total muestra el costo total de la solicitud.
• speed_download proporciona una lectura aproximada del rendimiento de la transferencia para esa respuesta.
• http_code muestra si la solicitud se completó de manera utilizable.

Para SOCKS5, cambia la bandera del proxy:

curl --proxy socks5h://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w 'code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n' \
  https://TARGET_URL

Un tiempo de espera de conexión de 15 segundos es un punto de partida razonable para grupos de proxies mixtos. Es lo suficientemente largo como para capturar apretones de manos móviles lentos sin permitir que rutas muertas desperdicien demasiado tiempo de prueba. Ajusta más tarde si tus trabajos de producción fallan más rápido.

Realiza solicitudes repetidas en lugar de disparos únicos

Una solicitud casi no prueba nada. Diez solicitudes comienzan a mostrar comportamiento.

for i in $(seq 1 10); do
  curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
    -s -o /dev/null \
    --connect-timeout 15 \
    -w 'run='$i' code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n' \
    https://TARGET_URL
done

Lee el conjunto de ejecuciones como un operador, no como un gráfico de referencia.

• ¿Los tiempos de conexión se mantienen en la misma banda?
• ¿Algunas solicitudes se detienen cerca del tiempo de espera?
• ¿Los códigos de estado cambian durante la serie?
• ¿El rendimiento disminuye después de la rotación o después de varios accesos desde el mismo puerto?

Esos patrones importan más en proxies móviles que el resultado único más rápido. Un puerto LTE compartido puede mostrar un tiempo fuerte y aún así producir una tasa de éxito débil una vez que otro usuario carga la misma puerta de enlace. Un proxy móvil personal a menudo parece menos impresionante en rendimiento bruto, pero generalmente ofrece una repetibilidad más limpia, que es lo que mantiene vivos los flujos de trabajo de cuentas.

Agrega concurrencia con cuidado

La carga cambia la historia rápidamente. Un proxy que maneja una solicitud de manera limpia puede volverse inestable una vez que empujas tráfico paralelo a través de él.

Un patrón simple de shell:

seq 5 | xargs -I{} -P 5 sh -c '
curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w "job={} code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n" \
  https://TARGET_URL
'

Luego aumenta el paralelismo:

seq 10 | xargs -I{} -P 10 sh -c '
curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w "job={} code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n" \
  https://TARGET_URL
'

Comienza bajo y aumenta. Eso refleja mejor la producción que saltar directamente a una prueba de estrés.

Para proxies móviles, los resultados de concurrencia necesitan contexto. Si usas un puerto 4G personal por trabajador de automatización, una carga paralela pesada en un solo proxy no es realista y la prueba puede engañarte. Si compras acceso móvil compartido y distribuyes múltiples sesiones a través de la misma salida, las pruebas de concurrencia importan mucho porque la contención es parte del producto.

Si tu flujo de trabajo de Instagram ejecuta una sesión por puerto, prueba una sesión por puerto. Si tu scraper se distribuye a través de salidas móviles compartidas, prueba de la misma manera.

Prueba la ruta de solicitud real, no solo una URL estática

Una solicitud GET simple es útil para el tiempo. No es suficiente para flujos de trabajo que inician sesión, siguen redirecciones, cargan APIs o reutilizan cookies.

Empuja tus trabajos de línea de comandos reales a través de la ruta del proxy cuando sea posible. Prueba los mismos encabezados, el mismo comportamiento de sesión y la misma longitud de secuencia que tu trabajador usa en producción. Para proxies móviles, tales pruebas exponen rutas débiles. El proxy puede devolver un estado limpio en una página de destino simple pero fallar una vez que la plataforma solicita múltiples solicitudes encadenadas desde la misma sesión.

Esa diferencia es común en plataformas sociales. Una ruta con velocidad bruta promedio aún puede superar a una más rápida si completa más acciones reales sin reinicios, páginas de desafío o sesiones caídas.

Usa pruebas al estilo iperf solo para una pregunta específica

Las pruebas de ancho de banda de bajo nivel responden a una pregunta específica. ¿Está restringido el camino de transporte?

Eso puede ayudar durante la solución de problemas, especialmente si las cargas o descargas están claramente limitadas. No te dice si un proxy móvil rotativo mantendrá la misma sesión el tiempo suficiente para acciones de cuenta, si un puerto compartido se degrada bajo tráfico vecino, o si la ruta sigue siendo confiable por el destino.

Para operaciones de proxy, el tiempo a nivel de aplicación y el éxito repetido suelen dar una mejor señal que el ancho de banda bruto.

Interpretando los Resultados de la Prueba de Velocidad de Proxy Móvil

Un proxy móvil puede perder cada comparación de velocidad bruta y aún así ganar el trabajo.

Eso sucede todo el tiempo con la automatización de Instagram. Un proxy 4G o LTE puede mostrar mayor latencia y menor rendimiento que una ruta de centro de datos, pero aún completar más inicios de sesión, mantener sesiones más tiempo y activar menos puntos de control. Si la prueba solo mide velocidad, se pierde la parte que afecta la salida.

Lee los resultados móviles como rangos operativos

Los números de una sola ejecución son señales débiles en redes móviles. Las rutas de los operadores cambian. Las condiciones de radio cambian. Los puertos compartidos recogen ruido de otros usuarios. La rotación puede reiniciar el camino en medio de tu ventana de muestra.

Usa ejecuciones repetidas y busca un rango utilizable, no un resultado perfecto.

Un resultado saludable de proxy móvil generalmente se ve así:

• La latencia se mantiene dentro de una banda a través de múltiples ejecuciones, incluso si el número exacto varía
• El tiempo hasta el primer byte se mantiene predecible lo suficiente para el flujo de trabajo objetivo
• Las fallas se agrupan alrededor de eventos de rotación en lugar de aparecer aleatoriamente
• Los puertos personales muestran una variación más ajustada que los puertos compartidos bajo la misma prueba

Para proxies móviles, la variación importa tanto como la velocidad. Una ruta que oscila entre aceptable e inutilizable romperá las acciones de cuenta de maneras que una puntuación promedio oculta.

La rotación cambia cómo puntúas el proxy

La rotación afecta más que la frescura de la IP. Cambia lo que significa un resultado de tiempo.

Si pruebas a través de una rotación forzada o un cambio de operador programado, estás midiendo dos estados a la vez. Eso hace que el promedio sea casi inútil para trabajos basados en sesiones. Divide los datos en ventanas antes de la rotación y después de la rotación, luego compara cada ventana por separado.

Usa esta tabla como una lectura práctica:

Para el trabajo de Instagram, me importa más si el proxy puede completar un inicio de sesión, cargar un perfil y hacer algunas solicitudes de seguimiento en la misma sesión que si recortó unos cientos de milisegundos de una recuperación estática.

Puertos compartidos versus personales

Los puertos móviles compartidos y personales no deben ser juzgados por el mismo estándar.

Los puertos compartidos son adecuados para verificaciones de bajo costo, muestreo amplio de grupos y tareas desechables. También llevan más variación. El tráfico de otro cliente puede afectar el tiempo de apretón de manos, el tiempo de respuesta y si tu ruta parece estable a lo largo de una secuencia corta.

Los puertos personales suelen tener un rendimiento más limpio porque cambian menos variables a la vez. Eso los hace más fáciles de evaluar para la creación de cuentas, el calentamiento, las verificaciones de bandeja de entrada o cualquier flujo de Instagram donde la sesión debe sobrevivir a varias solicitudes vinculadas.

Un proveedor en esta categoría, Evoproxy, ofrece tanto puertos móviles compartidos como personales con un comportamiento de rotación configurable para casos de uso de IP móviles franceses. Esa división es útil durante las pruebas porque te permite medir el precio de la consistencia directamente en lugar de adivinar.

Un puerto personal más lento a menudo produce una mejor tasa de finalización de acciones que un puerto compartido más rápido. En producción, la tasa de finalización paga la factura.

Mapear datos de velocidad a éxito de acción

La latencia bruta, la velocidad de descarga y el ping son métricas de apoyo. La métrica de decisión es si el proxy termina el trabajo.

Para proxies móviles, empareja los datos de tiempo con los datos de resultado de la tarea objetivo:

• Tasa de finalización de inicio de sesión
• Frecuencia de puntos de control o desafíos
• Tasa de éxito en una secuencia de acciones corta
• Supervivencia de la sesión después de la rotación
• Conteo de reintentos necesarios para terminar el trabajo

Un ejemplo simple hace que la compensación sea clara. Supongamos que un proxy promedia tiempos de respuesta más rápidos pero pierde la sesión durante la segunda o tercera solicitud. Otro proxy es más lento, pero logra iniciar sesión, cargar el feed y realizar acciones de perfil sin interrupciones. El segundo proxy es la mejor opción para la automatización de Instagram, aunque el gráfico de velocidad se vea peor.

Lee las pruebas de proxies móviles de la misma manera que lees los sistemas de producción. Prefiere la ruta que completa el flujo de trabajo de manera consistente, sobrevive al comportamiento normal de rotación y falla de maneras predecibles que puedes manejar.

Cómo automatizar el monitoreo del rendimiento de tu proxy

Una prueba de velocidad de proxy única ayuda con la selección. El monitoreo ayuda con las operaciones.

Quieres un trabajo simple que lea una lista de proxies, acceda a un objetivo que coincida con tu carga de trabajo real y escriba los resultados en un CSV que puedas inspeccionar más tarde. Mantenlo aburrido. Los scripts aburridos sobreviven.

Una plantilla práctica de Bash

Utiliza un archivo de proxies en un formato estándar que tu equipo pueda mantener. Luego, recorre los proxies y registra el tiempo más el estado.

#!/usr/bin/env bash

TARGET_URL="https://TARGET_URL"
PROXY_LIST="proxies.txt"
OUTPUT_FILE="proxy_results.csv"
TIMEOUT=15

if [ ! -f "$OUTPUT_FILE" ]; then
  echo "timestamp,proxy,http_code,time_connect,time_starttransfer,time_total,size_download,speed_download" > "$OUTPUT_FILE"
fi

while IFS= read -r PROXY; do
  [ -z "$PROXY" ] && continue

  TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

  RESULT=$(curl -x "$PROXY" \
    -s -o /dev/null \
    --connect-timeout "$TIMEOUT" \
    -w "%{http_code},%{time_connect},%{time_starttransfer},%{time_total},%{size_download},%{speed_download}" \
    "$TARGET_URL")

  echo "$TIMESTAMP,$PROXY,$RESULT" >> "$OUTPUT_FILE"
done < "$PROXY_LIST"

Algunas notas prácticas:

• Mantén el objetivo relevante: prueba la página o el endpoint que se asemeje a tu tarea de producción.
• Registra las marcas de tiempo en UTC: facilita la revisión de tendencias y la comparación de incidentes.
• Preserva las ejecuciones fallidas: las filas vacías o malas aún te dicen algo.

Agrega lógica de lote ligera

Para proxies móviles, una sola pasada no es suficiente. Ejecuta el script repetidamente en un horario y compara ventanas. Quieres ver si un proxy se comporta de manera diferente en diferentes momentos o alrededor de intervalos de rotación planificados.

Adiciones útiles incluyen:

• Grupos de destino separados: un archivo para páginas de inicio de sesión, uno para páginas de contenido, uno para endpoints de estilo API.
• Etiquetado de tipos de proxy: agrega una columna para compartido, personal, rotativo o pegajoso.
• Filtros de falla simples: marca filas con códigos de estado malos o tiempo total cerca del tiempo de espera.
• Resumen rodante: calcula medianas y conteos de fallas fuera de línea si es necesario.

Monitorea lo que tu aplicación realmente experimenta

Si tu automatización abre cinco páginas en secuencia, no midas solo una solicitud. Envuelve el script para que realice una cadena corta y registre si la cadena se completa. Eso generalmente revela problemas operativos más rápido que las mediciones de velocidad sintéticas por sí solas.

Una configuración de monitoreo sólida responde preguntas simples rápidamente:

• ¿Qué proxies se volvieron más lentos?
• ¿Cuáles comenzaron a fallar?
• ¿Qué URLs objetivo exponen el problema primero?
• ¿Está el problema vinculado a un tipo de proxy o a un destino?

Esas respuestas importan más que un número de ancho de banda aislado.

Errores comunes y cómo evitarlos

La mayoría de las malas decisiones sobre proxies provienen de un mal diseño de prueba, no de proxies malos. El propio benchmark introduce sesgo, y luego los equipos compran o descartan rutas basándose en ruido.

Los errores que distorsionan los resultados

• Probar desde una máquina local débil: tu laptop, Wi-Fi o enlace de oficina pueden ser el cuello de botella. Si el host del cliente es inestable, el proxy es culpado por el problema de otra persona.
• Usar un destino irrelevante: un proxy puede funcionar de una manera contra un endpoint ligero cercano y de otra manera contra la pila de destino real.
• Mezclar protocolos descuidadamente: si tu aplicación utiliza un protocolo de proxy y tu benchmark utiliza otro, no estás midiendo el mismo camino.
• Confiar en una sola ejecución: una solicitud limpia puede ocultar inestabilidad de ruta, efectos de rotación o fallas intermitentes.
• Ignorar los resultados de la sesión: un proxy que parece rápido en aislamiento aún puede desencadenar errores de acceso durante flujos de trabajo reales.

Un mejor estándar a seguir

Utiliza un host de prueba cerca de tu audiencia objetivo o plataforma objetivo. Repite el benchmark. Aumenta la concurrencia con cuidado. Empareja el resultado sintético con una verificación de sitio real que coincida con tu carga de trabajo.

Ese último punto es el más importante para proxies móviles. Si la ruta está destinada a plataformas sociales, una prueba de velocidad de proxy útil debe responder más que "qué tan rápido". Debe responder "qué tan utilizable".

Una prueba de velocidad de proxy significativa es contextual. Respeta el protocolo, el destino, el nivel de concurrencia y la forma de tarea que utiliza tu aplicación. Una vez que pruebas de esa manera, los proxies débiles se vuelven obvios, y las buenas rutas móviles dejan de verse "lentas" solo porque no están cableadas.

Si necesitas IP móviles franceses para evaluar el comportamiento real de la plataforma, Evoproxy vale la pena considerar para equipos que desean probar puertos compartidos frente a personales, intervalos de rotación y consistencia de rutas móviles en una configuración práctica en lugar de un verificador genérico.