Cómo medir la calidad de un proxy móvil: 7 métricas, protocolo y scripts

Introducción: por qué una sola cifra de velocidad no lo resuelve todo

Imagina que estás eligiendo un proxy móvil y ves una cifra atractiva: velocidad de 50 megabits. Suena convincente, ¿verdad? Pero ese número casi no dice nada sobre cómo se comportará el proxy en el trabajo real. La velocidad es solo una faceta de la calidad, y ni siquiera la más importante. Mucho más a menudo, lo que falla no es un canal lento, sino la inestabilidad: el proxy respota instantáneamente y luego se cuelga durante varios segundos.

En esta guía aprenderás a medir la calidad de un proxy móvil de forma honesta y sistemática. Dominarás las siete métricas clave, obtendrás scripts listos en bash y Python, conocerás un protocolo unificado de medición y aprenderás a interpretar correctamente los resultados. Al final podrás resumir los datos en una tabla y comparar objetivamente dos proveedores.

Lo que obtendrás al final: tu propia metodología de verificación, herramientas listas y comprensión de qué números considerar alarmantes. Dejarás de creer en las cifras publicitarias y empezarás a basarte en tus propias mediciones.

Para quién es esta guía: para quienes compran o ya usan proxies móviles y quieren entender por qué pagan. Es adecuada para principiantes porque cada paso se explica en detalle. También tiene elementos avanzados: percentiles, pruebas largas, interpretación de distribuciones.

Qué necesitas saber de antemano: basta con saber abrir una terminal y copiar comandos. No se requiere experiencia en programación. Todo lo necesario lo explicaremos sobre la marcha.

Cuánto tiempo tomará: las mediciones básicas llevarán alrededor de dos o tres horas. Una prueba completa de 24 horas, por supuesto, dura 24 horas, pero funciona en segundo plano y no requiere tu atención constante. Para leer y configurar, reserva una tarde tranquila.

Por qué una sola prueba no demuestra nada. La red móvil vive su propia vida. En un segundo la torre está libre, en otro está congestionada. Si haces una sola solicitud y resulta rápida, es casualidad. La imagen real solo la da una serie de decenas y cientos de mediciones distribuidas en el tiempo. Por eso mediremos no una vez, sino en series, y miraremos no el promedio, sino la distribución.

Preparación previa: herramientas y protocolo unificado

Antes de presionar botones, armemos un conjunto de trabajo. Una preparación adecuada garantiza que tus números sean comparables entre sí.

Herramientas necesarias

• curl – utilidad para enviar solicitudes desde la línea de comandos. En la mayoría de los sistemas ya está instalada.
• Python versión 3.8 o superior – para el script que calcula métricas y percentiles.
• Terminal – la línea de comandos de tu sistema operativo.
• Editor de texto – para guardar scripts y notas.
• Accesos al proxy – dirección, puerto, usuario y contraseña de tu proxy móvil.

Cómo verificar que todo está instalado

1. Abre la terminal.
2. Escribe el comando curl --version y presiona Enter.
3. Si ves el número de versión, curl está listo.
4. Escribe python3 --version y presiona Enter.
5. Si ves algo como Python 3.11, todo está bien.

Consejo: si python3 no se encuentra, descarga Python del sitio oficial de los desarrolladores. Al instalarlo en Windows, asegúrate de marcar la casilla Add Python to PATH, de lo contrario la terminal no reconocerá el comando.

Conjunto de endpoints de referencia

Un endpoint es la dirección a la que enviamos solicitudes. Es crucial elegir objetivos reales, similares a aquellos con los que trabajarás. No pruebes el proxy solo en servidores especiales de velocidad: no reflejan la carga real.

Prepara tres o cuatro direcciones diferentes. Por ejemplo, una página de verificación de IP, una página de texto ligera y uno o dos recursos con los que planeas trabajar. Diferentes objetivos dan diferentes imágenes, y eso es normal.

⚠️ Atención: utiliza solo aquellos recursos cuyo acceso esté permitido por sus reglas y no viole la legislación. No uses proxies ni scripts de prueba para acciones contrarias a la ley o a las condiciones de los servicios.

Protocolo unificado de medición

Para que la comparación sea justa, fija las condiciones y no las cambies entre las pruebas de diferentes proveedores.

• Hora fija del día. Mide ambos proxies en el mismo intervalo horario. La red móvil al mediodía y de noche se comporta de manera diferente.
• Número mínimo de ejecuciones. Haz una serie de al menos varias decenas de solicitudes por cada métrica. Cuantas más muestras, más fiable el resultado.
• Los mismos endpoints. Prueba ambos proxies con el mismo conjunto de direcciones.
• Misma configuración de tiempos de espera. Establece un límite de espera único para todas las solicitudes.
• Mismo ordenador y canal. No cambies de dispositivo a mitad de la prueba.

Consejo: crea una carpeta separada para cada proveedor y guarda allí los registros. Así no confundirás nada al comparar.

✅ Verificación: tienes curl y Python instalados, preparaste la lista de endpoints y anotaste el protocolo de condiciones. Ahora puedes pasar a la teoría.

Conceptos básicos en lenguaje sencillo

Analicemos los términos que aparecerán en cada paso. Entender estas palabras es la mitad del éxito.

Latencia

La latencia es el tiempo entre el envío de una solicitud y la recepción de la respuesta. Se mide en milisegundos. Cuanto menor, mejor. Imagina que gritas en las montañas y esperas el eco: la latencia es la pausa hasta el primer sonido.

TTFB

TTFB significa tiempo hasta el primer byte. Es el momento en que el servidor comienza a enviar la respuesta. Es la parte más importante de la latencia porque muestra qué tan rápido reaccionaron el proxy y el servidor a tu solicitud, incluso antes de transferir el contenido principal.

Ancho de banda

El ancho de banda es cuántos datos puede transferir el proxy por segundo. Es la misma velocidad que suelen destacar en la publicidad. Es importante, pero solo junto con las demás métricas.

Jitter

Jitter es la variación de la latencia de una solicitud a otra. Si una respuesta llegó en 100 milisegundos, la siguiente en 105 y la tercera en 98, el jitter es pequeño y eso es bueno. Si los valores saltan de 80 a 900, el jitter es enorme y el trabajo será entrecortado.

Tasa de respuestas exitosas

Es el porcentaje de solicitudes que se completaron con éxito, sin errores ni interrupciones. Esta métrica muestra la fiabilidad. El proxy puede ser rápido, pero si una de cada diez solicitudes falla, trabajar con él es frustrante.

Percentiles p50, p95 y p99

Es una forma de describir la distribución de valores. El percentil p50 es la mediana: la mitad de las solicitudes son más rápidas que este valor, la mitad más lentas. El percentil p95 indica que el 95% de las solicitudes estuvieron dentro de ese tiempo, y el 5% fueron peores. El percentil p99 muestra el comportamiento de los casos más lentos.

Consejo: recuerda la regla principal. El promedio engaña, los percentiles dicen la verdad. Si tienes nueve respuestas rápidas y una colgada durante diez segundos, el promedio parece tolerable, pero p99 mostrará el problema de inmediato.

En qué se diferencia lento de inestable

Un proxy lento da valores grandes de latencia de manera estable. Es predecible. Un proxy inestable da resultados a veces excelentes, a veces pésimos. A menudo la inestabilidad es peor que una lentitud constante porque no se puede planificar.

✅ Verificación: entiendes qué es latencia, TTFB, ancho de banda, jitter, tasa de respuestas exitosas y percentiles. Genial, pasemos a la práctica.

Paso 1: medir la disponibilidad y la tasa de respuestas exitosas

Objetivo de la etapa: saber qué tan fiablemente responde el proxy a las solicitudes y entender qué errores ocurren.

Qué hacemos

Enviamos una serie de varias decenas de solicitudes idénticas y contamos cuántas se completaron con éxito. Además, recopilamos errores por tipo: tiempos de espera, cortes de conexión, respuestas con códigos de error.

Instrucciones paso a paso

1. Abre la terminal.
2. Prepara la cadena de acceso al proxy en el formato usuario, contraseña, dirección y puerto.
3. Ejecuta una serie de solicitudes con un bucle simple, donde el comando curl se comunica con tu endpoint a través del proxy.
4. Para cada solicitud, registra el código de respuesta y si fue éxito o error.
5. Después de completar la serie, calcula el porcentaje de respuestas exitosas.

El comando básico para una solicitud se ve así: curl con la bandera de proxy, bandera de tiempo de espera y dirección. La bandera --max-time limita el tiempo de espera para que una solicitud colgada no detenga toda la serie.

Cómo interpretar el resultado

Divide las respuestas en grupos. Exitosas son las que tienen códigos normales. Por separado, cuenta los tiempos de espera (cuando el servidor no respondió a tiempo). Por separado, los cortes de conexión. Por separado, las respuestas con códigos de error del servidor.

Atención: la distribución de errores es más importante que su número total. Si todas las fallas son tiempos de espera, el problema es la velocidad o la congestión de la red. Si son cortes de conexión, quizás el proxy es inestable a nivel del canal móvil.

Consejo: no saques conclusiones con solo cinco solicitudes. La serie mínima significativa es de varias decenas. Para una decisión importante, usa cientos.

Posibles problemas

• Todas las solicitudes fallan. Verifica la corrección del usuario, contraseña, dirección y puerto. Un solo error tipográfico lo rompe todo.
• Parte de las solicitudes se cuelga para siempre. Usa obligatoriamente un límite de tiempo, de lo contrario la serie no terminará.
• Los códigos de error del servidor varían. Quizás el recurso de destino es inestable. Prueba con otro endpoint de control.

✅ Verificación: tienes el número de respuestas exitosas, el número de errores de cada tipo y entiendes dónde tropieza el proxy.

Paso 2: medir la latencia y TTFB mediante percentiles

Objetivo de la etapa: obtener una imagen honesta de la latencia, basándose en la distribución y no en el engañoso promedio.

Por qué el promedio induce a error

Supongamos que tienes diez solicitudes. Nueve llegaron en cien milisegundos y una se colgó durante cinco segundos. El promedio mostrará unos seiscientos milisegundos, y eso será mentira en ambos sentidos. En realidad, casi siempre el proxy es rápido, pero a veces es catastróficamente lento. Los percentiles muestran esto con honestidad.

Formato de salida de curl con la bandera -w

La utilidad curl puede mostrar un desglose detallado de tiempos. La bandera -w permite solicitar indicadores específicos. Las variables más útiles para nosotros: time_starttransfer – que es efectivamente TTFB, tiempo hasta el primer byte. También están time_connect – tiempo de establecimiento de conexión, y time_total – tiempo total de la solicitud.

1. Compón el comando curl con la bandera -o para enviar el cuerpo de la respuesta a la nada, para que no interfiera.
2. Agrega la bandera -s para eliminar el indicador de progreso.
3. Agrega la bandera -w con las variables de tiempo necesarias.
4. Ejecuta el comando en un bucle el número de veces necesario a través de tu proxy.
5. Guarda todos los valores de TTFB en un archivo, un número por línea.

Cómo calcular los percentiles

Ordena los números recopilados de menor a mayor. El valor en la posición media de la lista es p50. El valor en la posición del noventa y cinco por ciento de la longitud de la lista es p95. El valor en la posición del noventa y nueve por ciento es p99. En el script de Python al final de la guía, esto se hace automáticamente.

Consejo: mira siempre el par p50 y p95 juntos. Si están cerca, el proxy es estable. Si hay un abismo entre ellos, el proxy tiene fallos raros pero dolorosos.

Posibles problemas

• Los valores de TTFB son sospechosamente pequeños. Puede que haya actuado la caché. Desactiva la reutilización de conexión con la bandera que desactiva keep-alive y agrega un parámetro único a la dirección.
• Los valores varían mucho entre ejecuciones. Es normal en una red móvil. Por eso hacemos series, no mediciones puntuales.

✅ Verificación: tienes un archivo con valores de TTFB y tres números de percentiles que describen el comportamiento real de la latencia.

Paso 3: medir el ancho de banda de forma honesta

Objetivo de la etapa: conocer la velocidad real de transferencia de datos sin autoengaño.

Cómo medir honestamente

Descarga a través del proxy un archivo de tamaño conocido y mide cuánto tiempo tomó. Divide el tamaño entre el tiempo y obtienes la velocidad. Suena simple, pero hay matices que es fácil pasar por alto.

1. Elige varios archivos de diferentes tamaños en recursos reales.
2. Descarga cada uno a través del proxy con curl, midiendo el tiempo con la bandera -w con la variable time_total y la variable size_download.
3. Repite la descarga varias veces para cada archivo.
4. Calcula la velocidad para cada ejecución y mira la distribución.

Por qué varios archivos y endpoints

Un solo archivo de un solo servidor puede estar limitado por la capacidad del propio servidor, no por tu proxy. Diferentes fuentes dan diferentes imágenes. Si a través de todas las fuentes la velocidad es igualmente baja, el problema es el proxy. Si varía, el cuello de botella puede estar en un servidor específico.

Influencia de las limitaciones del plan

Muchos planes móviles tienen limitaciones de velocidad o volumen de tráfico. Después de cierto umbral, la velocidad puede caer drásticamente. Tenlo en cuenta: si descargas muchos datos seguidos, la ralentización puede ser consecuencia del plan, no de la calidad del proxy.

⚠️ Atención: no descargues grandes volúmenes de datos solo para la prueba si tu plan tiene límites. Corres el riesgo de agotar el paquete de datos. Usa archivos de tamaño moderado.

Consejo: mide el ancho de banda en la misma hora del día que las demás métricas. La carga de la red influye mucho en el resultado.

Posibles problemas

• La velocidad es inestable. Es típico en redes móviles. Mira la mediana de la velocidad, no un resultado puntual óptimo.
• La velocidad cayó bruscamente en medio de la prueba. Puede que haya actuado el límite del plan o haya cambiado el modo de red.

✅ Verificación: tienes valores de velocidad de varias fuentes y entiendes dónde está el cuello de botella.

Paso 4: medir el jitter y la estabilidad

Objetivo de la etapa: entender qué tan uniforme funciona el proxy, no solo qué tan rápido.

Qué hacemos

Tomamos la serie de mediciones de latencia de los pasos anteriores y observamos la dispersión. El jitter es esencialmente una medida de cuánto difieren los valores vecinos entre sí.

1. Toma el archivo con los valores de latencia recopilados en el segundo paso.
2. Calcula la diferencia entre mediciones consecutivas.
3. Promedia el valor absoluto de esas diferencias: esa será una estimación del jitter.
4. Adicionalmente, mira la desviación estándar de toda la serie.

Qué considerar normal

No existen números universales concretos, porque la normalidad depende de la tarea. El principio general es: cuanto menor sea el jitter en relación con la latencia misma, mejor. Si la latencia es de cien milisegundos y el jitter de cinco, es excelente. Si el jitter es comparable a la latencia, el trabajo será entrecortado.

Consejo: visualiza la serie de mediciones con un gráfico simple. Una línea plana es buena señal. Una sierra con picos bruscos es alarmante.

Dispersión de valores

Presta atención a los valores atípicos raros. Un pico aislado cada cien solicitudes puede ser tolerable. Picos regulares significan que el proxy sufre fluctuaciones de la red móvil más de lo normal.

✅ Verificación: tienes una estimación del jitter y entiendes si el proxy es estable o salta.

Paso 5: verificar el comportamiento al cambiar de IP

Objetivo de la etapa: entender qué tan rápido y con qué calidad el proxy cambia de dirección IP.

Qué medimos

Los proxies móviles pueden cambiar de IP a petición o según un cronograma. Nos interesan varias cosas: cuánto tarda el cambio, si la nueva dirección permanece en la misma red y ciudad, y cuántas direcciones únicas se obtienen en una hora.

1. Solicita la IP actual a través de un endpoint de verificación de IP.
2. Inicia el cambio de IP mediante el método que proporciona tu proveedor.
3. Mide el tiempo hasta que la nueva dirección esté disponible.
4. Vuelve a solicitar la IP y regístrala.
5. Repite el ciclo muchas veces durante una hora.
6. Cuenta el número de direcciones únicas y el tiempo de cada cambio.

Cómo evaluar el resultado

Observa varios parámetros. La velocidad de cambio muestra qué tan rápido obtienes una dirección fresca. El número de direcciones únicas por hora indica la diversidad del pool. La pertenencia a la misma red y ciudad confirma que permaneces en el segmento esperado.

Consejo: registra no solo la dirección en sí, sino también los datos de su red y ciudad que devuelve el endpoint de verificación. Así verás si la geografía es estable al cambiar.

⚠️ Atención: usa el cambio de IP solo con fines legales y dentro de las reglas de los servicios con los que trabajas. Las capacidades técnicas del proxy no anulan los requisitos legales ni los acuerdos de usuario.

Posibles problemas

• El cambio tarda demasiado. Verifica si estás usando el método correcto. Consulta con el proveedor el método estándar.
• Las direcciones se repiten. Una pequeña repetición es habitual, pero duplicados constantes indican un pool pequeño.

✅ Verificación: tienes el tiempo de cambio, el número de direcciones únicas por hora y datos sobre su geografía.

Paso 6: verificar la coincidencia de geografía y tipo de conexión

Objetivo de la etapa: asegurarse de que el proxy realmente coincide con las características declaradas.

Qué verificamos

El proveedor suele indicar el país, la región y el tipo de conexión, por ejemplo, red móvil. Nuestra tarea es comparar lo declarado con lo real.

1. Accede a través del proxy a un endpoint que devuelva datos sobre tu dirección.
2. Registra el país y la región determinados.
3. Registra el tipo de conexión que determina el servicio.
4. Repite la verificación varias veces con diferentes direcciones IP.
5. Compara los resultados con lo que prometió el proveedor.

Cómo interpretar el resultado

Si la geografía y el tipo de conexión coinciden establemente con lo declarado, excelente. Si de vez en cuando aparecen otras regiones o el tipo de conexión no coincide, es motivo para preguntar al proveedor.

Consejo: verifica la geografía con varias fuentes independientes de geolocalización. Las bases de datos de asignación de direcciones a veces difieren, y una sola fuente puede equivocarse.

✅ Verificación: confirmaste o refutaste la coincidencia de geografía y tipo de conexión con lo declarado.

Paso 7: ejecutar una prueba larga de 24 horas

Objetivo de la etapa: ver lo que es imposible notar en cinco minutos.

Por qué es necesaria una prueba de 24 horas

Una prueba corta captura solo el estado actual de la red. Una prueba de 24 horas muestra el comportamiento del proxy en diferentes momentos: por la mañana, en la hora punta del mediodía, por la noche. Verás cómo cambian la latencia, la tasa de respuestas exitosas y la estabilidad a lo largo del día.

1. Configura un script para mediciones periódicas, por ejemplo, cada pocos minutos.
2. Ejecútalo en segundo plano y déjalo funcionar durante 24 horas.
3. Asegúrate de que los resultados se escriban en un archivo con marca de tiempo.
4. Después de 24 horas, recopila los datos y construye una imagen por horas.

Qué muestra una prueba larga

Verás caídas en las horas punta, cuando la red móvil está congestionada. Notarás ventanas de estabilidad nocturnas. Descubrirás picos de errores poco frecuentes que en cinco minutos simplemente no habrían tenido tiempo de manifestarse. Precisamente la prueba de 24 horas separa un buen proxy de uno mediocre.

⚠️ Atención: controla el consumo de tráfico durante la prueba de 24 horas. Haz solicitudes ligeras para no agotar el límite del plan en un día de trabajo continuo.

Consejo: no ejecutes la prueba de 24 horas en un ordenador que pueda entrar en modo de suspensión. Desactiva la suspensión, de lo contrario las mediciones se interrumpirán.

✅ Verificación: tienes un registro de 24 horas con marcas de tiempo, que muestra el comportamiento del proxy en dinámica.

Scripts listos para las mediciones

A continuación se presentan plantillas que calculan las métricas descritas. Adáptalas a tus datos de acceso y endpoints.

Script en bash

Este script hace una serie de solicitudes, recopila TTFB y códigos de respuesta, y los guarda en un archivo. La lógica es la siguiente: en un bucle se ejecuta curl a través del proxy, la bandera -w muestra el tiempo hasta el primer byte y el código de respuesta, y el resultado se añade al registro.

Elementos principales del script: variable con la dirección del proxy en el formato protocolo, usuario, contraseña, dirección y puerto. Variable con el endpoint de destino. Bucle con un número determinado de repeticiones. Dentro del bucle, llamada a curl con las banderas -s para silencio, -o para desechar el cuerpo, --max-time para limitar el tiempo de espera y -w con las variables time_starttransfer y http_code. Cada línea de resultado se añade a un archivo de texto. Después del bucle, bash puede calcular estadísticas simples o pasar el archivo a Python.

Para desactivar la caché, agrega un parámetro único a la dirección y usa la bandera que desactiva la reutilización de conexión. Esto garantiza que cada medición sea honesta, no tomada de la memoria.

Script en Python

El script de Python es más conveniente para calcular percentiles y jitter. Lee el archivo con valores o realiza las solicitudes por sí mismo usando la biblioteca de trabajo con HTTP que admite proxy.

La lógica del script es la siguiente. Primero se definen los parámetros: dirección del proxy, lista de endpoints, número de repeticiones y tiempo de espera. Luego, en un bucle, se ejecutan las solicitudes, registrando para cada una el tiempo hasta el primer byte, el tiempo total y el código de respuesta. Las respuestas exitosas y fallidas se cuentan por separado. Todos los valores de latencia se almacenan en una lista.

Después de recopilar los datos, el script ordena la lista de latencias y calcula los percentiles. La mediana se toma de la mitad de la lista ordenada. El percentil p95 se toma de la posición del noventa y cinco por ciento de la longitud. El percentil p99 de la posición del noventa y nueve por ciento. El jitter se calcula como el promedio de los valores absolutos de las diferencias entre mediciones consecutivas. La tasa de respuestas exitosas es el número de éxitos dividido por el número total de solicitudes.

Al final, el script imprime un informe final: tasa de respuestas exitosas, percentiles de latencia, estimación de jitter y distribución de errores por tipo. Para una prueba de 24 horas, agrega una marca de tiempo a cada registro y envuelve las mediciones en un bucle con una pausa entre series.

Consejo: guarda los datos sin procesar, no solo los números finales. Si luego necesitas recalcular una métrica de otra manera, tendrás los originales.

⚠️ Atención: guarda el usuario y la contraseña del proxy en un archivo de configuración separado, no directamente en el script que podrías mostrar accidentalmente a alguien.

Cómo resumir los resultados en una tabla

Cuando tengas los datos recopilados, es importante presentarlos de forma visual. Una tabla unificada permite comparar proveedores de manera honesta.

Estructura de la tabla final

Haz una tabla donde las filas sean las métricas y las columnas los proveedores. Para cada métrica, indica el valor y, cuando corresponda, los percentiles. Así verás de inmediato quién es más fuerte en qué.

• Tasa de respuestas exitosas – porcentaje por cada proveedor.
• TTFB – tres números: p50, p95, p99.
• Ancho de banda – mediana de velocidad.
• Jitter – estimación de dispersión.
• Cambio de IP – tiempo de cambio y número de direcciones únicas por hora.
• Geografía y tipo de conexión – coincide o no con lo declarado.
• Comportamiento en 24 horas – si hay caídas en horas punta.

Tabla de interpretación de métricas

Presentamos una tabla descriptiva del tipo métrica, cómo se mide, qué significa un valor malo. No inventamos cifras concretas: los estándares dependen de la tarea.

• Tasa de respuestas exitosas. Se mide con una serie de solicitudes y conteo de éxitos. Un valor malo es una proporción notable de errores, especialmente cortes, lo que indica falta de fiabilidad.
• TTFB y percentiles. Se mide con curl usando la variable de tiempo hasta el primer byte en una serie grande. Un valor malo es una gran brecha entre p50 y p99, lo que indica fallos raros pero dolorosos.
• Ancho de banda. Se mide descargando archivos de tamaño conocido. Un valor malo es una velocidad que no cubre tus necesidades o que cae bruscamente.
• Jitter. Se mide como la dispersión de latencias consecutivas. Un valor malo es un jitter comparable a la latencia misma, lo que significa un trabajo entrecortado.
• Cambio de IP. Se mide con un ciclo de cambios midiendo el tiempo. Un valor malo es un cambio lento y pocas direcciones únicas.
• Geografía y tipo de conexión. Se mide contrastando con un endpoint de geolocalización. Un valor malo es la no coincidencia con lo declarado.
• Estabilidad en 24 horas. Se mide con una prueba larga. Un valor malo son fuertes caídas de métricas en horas punta.

Consejo: al comparar, no saques conclusiones por una sola fila. Pondera las métricas según su importancia para tu tarea específica. Para unos es crítica la estabilidad, para otros la velocidad de cambio de dirección.

Verificación del resultado: lista de verificación de calidad de la medición

Antes de confiar en tus números, revisa esta lista. Garantiza que las mediciones sean correctas.

• Cada métrica se midió en serie, no con una sola solicitud.
• Ambos proveedores se probaron en la misma hora del día.
• Se usaron los mismos endpoints y tiempos de espera.
• Para la latencia se calcularon percentiles, no solo el promedio.
• La caché y la reutilización de conexión se desactivaron donde es importante.
• Las pruebas se realizaron en objetivos reales, no solo en servidores de velocidad.
• Se realizó al menos una prueba de 24 horas.
• Los datos sin procesar se guardaron por si se necesita un recálculo.

✅ Verificación: si todos los puntos están marcados, tus resultados son una base fiable para tomar decisiones.

Errores típicos en las mediciones y sus soluciones

Aquí se recogen los errores más comunes. Cada uno se describe como problema, causa y solución.

Error uno: una sola ejecución

Problema: conclusión basada en una o dos solicitudes. Causa: deseo de obtener una cifra rápida. Solución: siempre haz una serie de decenas o cientos de solicitudes y mira la distribución.

Error dos: prueba solo en hora punta

Problema: los resultados parecen terribles o, por el contrario, ideales. Causa: la medición se hizo en un momento de carga máxima o mínima de la red. Solución: mide en diferentes momentos y realiza obligatoriamente una prueba de 24 horas.

Error tres: medir solo con servidores de velocidad

Problema: las cifras son bonitas, pero en el trabajo real todo es diferente. Causa: los servidores especiales de velocidad no reflejan los objetivos reales. Solución: prueba con los recursos con los que trabajarás.

Error cuatro: ignorar la caché

Problema: la latencia es sospechosamente baja y estable. Causa: las respuestas provienen de la caché, no de la red. Solución: agrega un parámetro único a la dirección y prohíbe el almacenamiento en caché.

Error cinco: keep-alive distorsiona la imagen

Problema: la primera solicitud es lenta, las siguientes instantáneas. Causa: la conexión se reutiliza y las mediciones posteriores no consideran el establecimiento de conexión. Solución: para una medición honesta, desactiva la reutilización de conexión si quieres ver la latencia completa.

Error seis: comparar promedios en lugar de percentiles

Problema: dos proxies parecen iguales en promedio, pero en la práctica uno es notablemente peor. Causa: el promedio oculta las caídas. Solución: compara p95 y p99.

Error siete: condiciones diferentes para distintos proveedores

Problema: la comparación no es justa. Causa: un proxy se probó de día con un endpoint, otro de noche con otro. Solución: sigue estrictamente el protocolo unificado.

Posibilidades adicionales y optimización

Cuando domines la metodología básica, puedes profundizar.

Automatización de comprobaciones periódicas

Configura el script para que se ejecute según un horario, por ejemplo, diariamente. Así verás si el proxy se degrada con el tiempo. Acumula historial y construye una tendencia.

Mediciones paralelas

Los usuarios avanzados pueden ejecutar varios hilos simultáneamente para evaluar el comportamiento bajo carga. Hazlo con cuidado y dentro de las reglas del proveedor.

Visualización de datos

Construye gráficos con los datos recopilados. Un gráfico de latencia por hora del día mostrará claramente las horas punta. Un histograma de distribución de latencia mostrará si hay una cola larga de respuestas lentas.

Consejo: incluso un gráfico simple en una hoja de cálculo hace que las conclusiones sean mucho más convincentes que una columna de números.

Segmentación por endpoints

Calcula las métricas por separado para cada endpoint. A veces el proxy funciona excelente con unos objetivos y peor con otros. Este detalle ayuda a tomar decisiones precisas.

FAQ: preguntas frecuentes sobre la medición de calidad de proxies

¿Cuántas solicitudes se necesitan para un resultado fiable?

Cuantas más, mejor. Una serie mínima significativa son varias decenas. Para una decisión importante, usa cientos de solicitudes y obligatoriamente una prueba de 24 horas.

¿Por qué no se puede confiar en la cifra de velocidad publicitaria?

Porque la velocidad es solo una métrica de siete. El proxy puede ser rápido pero inestable, con mala disponibilidad o cambio de IP lento. La publicidad muestra el mejor caso, no el típico.

¿Qué es más importante: la latencia o el ancho de banda?

Depende de la tarea. Para solicitudes rápidas y ligeras, es más importante la latencia y la estabilidad. Para transferir grandes volúmenes, es más importante el ancho de banda. Mira el conjunto de métricas.

¿Por qué el valor promedio de latencia es engañoso?

Porque los valores enormes y raros inflan el promedio, y los pequeños y raros lo reducen. Los percentiles p50, p95 y p99 describen la distribución honestamente y muestran cómo se comportan los peores casos.

¿Cómo saber si un proxy es inestable y no solo lento?

Mira el jitter y la brecha entre percentiles. Un proxy lento da valores grandes pero uniformes. Uno inestable salta de excelentes a pésimos.

¿Es obligatorio desactivar la caché en las mediciones?

Para una medición honesta de latencia, sí. De lo contrario, mides la velocidad de la memoria, no de la red. Agrega un parámetro único a la dirección y prohíbe la reutilización de conexión.

¿Por qué es necesaria una prueba de 24 horas si una de cinco minutos ya mostró algo?

La prueba de cinco minutos captura un momento. La de 24 horas muestra el comportamiento en horas punta, de noche y por la mañana, revela picos de error poco frecuentes. Solo ella separa un proxy fiable de uno que tuvo suerte.

¿Se pueden comparar dos proveedores probándolos en diferentes momentos?

No. La red cambia a lo largo del día y la comparación sería injusta. Prueba a ambos en el mismo intervalo según el protocolo unificado.

¿Qué hacer si los resultados varían mucho de una ejecución a otra?

Es normal en redes móviles. Por eso nos basamos en series y percentiles, no en mediciones puntuales. Aumenta el número de muestras.

¿Es necesario probar el cambio de IP si no planeo usarlo?

Si la función no es importante para ti, puedes omitir este paso. Pero medirlo es rápido y útil para tener una idea general de la calidad del pool de direcciones.

Conclusión: de las cifras publicitarias a tus propias mediciones

Has recorrido el camino desde la fe ingenua en una sola cifra de velocidad hasta una metodología sistemática de evaluación de calidad. Ahora tienes siete métricas, un protocolo unificado, scripts listos y comprensión de cómo interpretar los resultados.

Lo que has dominado. Aprendiste a medir la tasa de respuestas exitosas, la latencia mediante percentiles, el ancho de banda, el jitter, el comportamiento al cambiar de IP, la coincidencia geográfica y la estabilidad en 24 horas. Sabes por qué el promedio engaña y por qué una sola ejecución no demuestra nada.

Qué hacer a continuación. Aplica la metodología a tu proxy actual y registra los números base. Luego prueba un proveedor alternativo con el mismo protocolo y compara en una tabla unificada. La decisión se volverá evidente.

Hacia dónde desarrollar. Automatiza las comprobaciones periódicas, acumula historial y construye gráficos. Con el tiempo, notarás la degradación antes de que afecte tu trabajo. Recuerda lo principal: no confíes en la publicidad, sino en tus propias mediciones, hechas de forma honesta y sistemática. Eso es lo que distingue a un usuario seguro de uno que paga a ciegas.