Cómo medir realmente un VPN: metodología paso a paso, métricas y herramientas sin engaños

¿Por qué medir el rendimiento del VPN y qué significa realidad?

¿Qué es el rendimiento "real" y no el de marketing?

El rendimiento de un VPN no es un solo número bonito en un banner, sino un conjunto de métricas que afectan tu experiencia real: qué tan rápido se descargan archivos, la fluidez en videollamadas o que un juego no haga “teletransportes” con tu personaje. La realidad siempre depende del contexto. Hora del día, ruta al servidor, tipo de cifrado, carga del hardware, proveedor, incluso un router tonto con chip sobrecalentado — cada detalle modifica el panorama.

Cuando hablamos de "real", nos referimos a condiciones medibles y reproducibles, un plan de pruebas claro y una interpretación honesta. No necesitas un laboratorio de millones. Solo disciplina, herramientas adecuadas y saber qué números importan y cuáles son ruido en el gráfico.

¿Cuándo tiene sentido hacer pruebas y qué objetivos fijar?

Debes testear cuando cambias de VPN, cambias el protocolo (por ejemplo, de OpenVPN a WireGuard), modificas la ruta de red (nuevo proveedor, Starlink, 5G), configuras QoS o MTU, o detectas degradación — "ayer funcionaba bien, hoy da lag". La clave es tener un objetivo: ¿máximo throughput para backups? ¿latencia mínima para juegos? ¿jitter bajo para llamadas? El modo "todo a la vez" acaba en compromisos. Mejor priorizar.

Trampas comunes en la percepción y cómo evitarlas

Un test de velocidad único no dice nada. Medir "en la oficina con Wi-Fi" no es comparable con "en casa por cable". La ruta hasta el nodo de prueba cuenta la mitad de la historia; la otra mitad es el servidor VPN y su entorno. Es imprescindible medir la línea base sin VPN, si no, comparas nubes con papas. Y sí, la CPU suele ser el cuello de botella cuando usas cifrados pesados, sobre todo en routers sin AES-NI o con firmware fatigado.

Métricas clave: throughput, latencia, jitter y pérdidas

Throughput: el pan de cada día

Throughput es la cantidad de datos que pasan por el túnel por unidad de tiempo. Se mide en Mbps y Gbps. En la práctica, buscamos no un pico puntual, sino un promedio estable en intervalos de 30 a 60 segundos bajo carga constante. Diferenciamos throughput TCP (depende de ventana, pérdidas y latencia) y UDP (limitado por el emisor y las pérdidas). Para VPN es importante chequear ambos: TCP refleja la experiencia de usuario, UDP muestra el límite máximo con evaluación de pérdidas.

Escenarios típicos: 1 flujo, 4–8 flujos y muchos flujos para simular carga real. El aumento con multihilo revela limitaciones ocultas, por ejemplo, en un solo hilo de CPU para cifrado.

Latencia: la demora que se siente hasta en la piel

Latencia es el tiempo de ida y vuelta (RTT). Medimos mediana, percentiles 95 y 99. La mediana marca la base, las colas indican problemas. Para juegos queremos RTT bajo y estable. Para web importa no solo RTT sino la variabilidad: picos en las colas hacen que las páginas carguen lento, especialmente con muchas conexiones TCP/QUIC.

Detalle clave: medimos latencia hasta el destino final en Internet vía VPN, no solo hasta el servidor VPN. Si no, obtienes un número "bonito" que no refleja la ruta real.

Jitter: la fluctuación de latencia, el asesino de llamadas

Jitter es la variación de latencia en el tiempo. Los servicios de voz y video sufren por esto: 60 ms constantes se toleran, pero saltos entre 20 y 120 ms rompen los buffers y hacen la imagen entrecortada. Se calcula con la fórmula estándar de variación entre paquetes basada en mediciones sucesivas (por ejemplo, flujo UDP en iperf3). En informes revisamos el promedio y el percentil 95 de jitter. Para llamadas, confort está por debajo de 20–30 ms y pérdidas hasta 1%.

Pérdida de paquetes y relación con MOS

Las pérdidas degradan el throughput TCP (por retransmisiones) y a la larga aumentan latencia por buffering. En multimedia son críticas: el MOS (calidad de voz) baja drásticamente a partir del 2–3%. En 2026 muchos VPN sobre QUIC toleran mejores pérdidas gracias a FEC y control inteligente de flujo, pero no hay milagros: con un 5% estable de pérdidas la calidad sufre incluso si la velocidad promedio es buena.

Herramientas 2026: qué elegir y cómo prepararlas

iperf3: el estándar de oro para throughput y métricas UDP

iperf3 es la herramienta básica para medir TCP y UDP. Para TCP hacemos pruebas de 30–60 segundos, variando número de flujos (-P 1,4,8) y tamaño de ventana (por defecto va bien, pero a veces ayuda -w). Para UDP variamos bitrate (-b) en pasos hasta detectar pérdidas >1–2% y medimos jitter. Importante: el servidor iperf3 debe estar fuera del servidor VPN, en el país o región objetivo donde quieres medir rendimiento.

Bonus 2026: modos para backend orientados a QUIC (hay forks y añadidos), pero iperf3 clásico cubre el 95% de necesidades. Para reproducibilidad exacta, úsalo en Docker con versiones fijadas.

ping, fping, mtr: el trío para latencia y diagnóstico de ruta

ping mide RTT. fping lo hace masivamente y estable, útil para percentiles. mtr combina traceroute y ping: ves ruta, latencias y pérdidas en cada salto. Usa mtr hasta destino final vía VPN para detectar saltos “estrechos”: por ejemplo, enlaces saturados o rutas extrañas por otro continente.

Consejo: registra mtr 2–3 veces al día en horas pico y fuera de pico. En 2026 rutas cambian con frecuencia: proveedores balancean tráfico dinámicamente, especialmente con la expansión de SASE y proxies en la nube.

Speedtest CLI y servidores propios

Speedtest CLI es cómodo para un chequeo rápido, pero no es laboratorio. Sus resultados dependen del nodo y suelen ser “demasiado buenos” cerca de caches del proveedor. Mejor monta LibreSpeed en tu VPS en la ubicación requerida: el navegador simula carga real y tú controlas el servidor. Es útil para reportes a dirección — “experiencia usuario” — y comparar protocolos bajo mismas condiciones.

Wireshark, tcpdump y perfiles eBPF

Wireshark sirve para analizar a fondo: vemos retransmisiones, MSS, MTU, ventanas, causas de pérdidas. tcpdump para capturas ligeras con filtros. En 2026 es habitual usar herramientas eBPF (como perfiles bpftrace para pilas de red) para ver dónde se consume CPU: cifrado, copia de memoria, colas. A menudo la sorpresa es que la culpa no es la red, sino un driver mal optimizado o un offload desactivado en la NIC.

Metodología de pruebas: desde la línea base hasta comparar protocolos VPN

Paso 1. Línea base: sin VPN, pero en serio

Primero medimos sin VPN. Por cable. Misma ruta al servidor de prueba. Hacemos tres series: mañana, pico, noche. Guardamos iperf3 TCP/UDP, ping/fping, mtr. Esto es la "referencia de velocidad y estabilidad", sin ella no sabrás si el túnel falla por la red o el cifrado, la ruta o el servidor.

Simultáneamente anotamos métricas del sistema: carga CPU (sobre todo un hilo), IRQ, frecuencia de núcleos, temperatura. En el router, aceleradores hardware, offload, estado de buffers. Sin esto podrías culpar erróneamente al VPN de problemas que son del CPU.

Paso 2. Plan de experimento: aleatorización, reproducibilidad, duración

Diseña plan: qué protocolos (WireGuard, OpenVPN, IPsec, soluciones modernas basadas en QUIC), qué cifrados (ChaCha20-Poly1305 para ARM y CPUs débiles, AES-GCM para x86 con AES-NI), ubicaciones (cercana, media, lejana), cargas (un flujo, multihilo, UDP al límite). Aleatoriza orden para evitar sesgos por degradación del servidor o red.

Cada prueba dura al menos 30 segundos, ideal 60. Repitiendo 3–5 veces. Para resultados usa mediana e intervalos de confianza. Descarta outliers evidentes (por ejemplo, si hubo rebalanceo de ruta en una corrida).

Paso 3. Comparación y control de variables

Cambia un parámetro a la vez. Primero WireGuard vs OpenVPN con mismo MTU y cifrados, luego efecto MTU, luego multihilo, luego ubicación. Crítico: mismos puertos y protocolos de transporte (UDP vs TCP). Cambiar puerto puede activar diferente QoS en proveedor.

Registro de versión cliente/servidor, configuraciones, keepalive, timers de renovación de keys. En 2026 muchos clientes tienen auto-switching y multipath inteligentes — desactívalos para pruebas limpias, no mezcles peras con piñas.

Escenarios prácticos: juegos, vídeo, trabajo y compartir archivos

Juegos: prioridad latencia y estabilidad de colas

Para juegos ideal es RTT bajo 50 ms a servidores de juego, jitter menor a 15–20 ms, pérdidas bajo 0.5%. Throughput casi no importa salvo actualizaciones. Testea ping/fping a IP reales o PoP cercanos del desarrollador, mtr para detectar saltos erráticos. Chequea MTU: si el cliente es sensible a fragmentación verás saltos en RTT bajo carga. A veces WireGuard da colas 10–20% más estables que túneles TCP, especialmente en Wi‑Fi.

Videollamadas y streaming: jitter importa más que throughput

Zoom, Meet, Teams, WebRTC, todos adaptativos. Necesitan canal uniforme. Para evaluar usa prueba UDP iperf3 de 2–8 Mbps por 5–10 minutos y analiza jitter y pérdidas. MOS suele superar 4.0 con jitter bajo 20 ms y pérdidas hasta 1–2%. En realidad, QoS bien configurado en router marca gran diferencia: marca DSCP y evita bufferbloat, sobre todo en subida.

Trabajo remoto: web, IDE, RDP/SSH

Clave es combinación de RTT y throughput. QUIC/HTTP3 ya estándar en 2026, 0-RTT handshake reduce “pausas” al abrir pestañas. Pero si VPN suma 40–60 ms lo notarás como “pegajosidad”. Para RDP/SSH comodidad empieza con RTT bajo 80 ms sin jitter errático. Chequea intervalos keepalive VPN para evitar reconexiones inesperadas.

Compartir archivos, torrents y backups: limitados por CPU y ventana

Throughput máximo es rey. Testea TCP multihilo (4–16 flujos) y compara con uno solo. Si gana 2–3 veces, limitaba ventana/RTT. Si casi nada, limita cifrado/CPU o servidor. En torrents subida importa: prueba VPN al 80–90% de carga uplink. FQ o Cake en router suele arreglar el "todo se traba al subir".

Interpretación de resultados: dónde está el cuello y qué hacer

Red y ruta: proveedor, peering, congestión

Si sin VPN RTT es estable y bajo, pero con VPN sube y es errático, revisa ruta: mtr mostrará salto con cola o pérdida. A veces el servidor VPN está en un data center “barato” con enlace saturado. Solución: cambiar ubicación o proveedor, o a veces usar otro puerto/protocolo (UDP 443 vía rutas QUIC puede comportarse distinto que UDP 51820).

Criptografía y CPU: la realidad del hardware

Si CPU usa 100% en un hilo con cifrado, tocarás techo seguro. WireGuard en x86 con AES-NI y ChaCha20-Poly1305 suele rendir mejor que OpenVPN en espacio usuario. En routers ARM ChaCha20 casi siempre gana a AES sin aceleración hardware. Revisa offloads: GRO/LRO, TSO, acelerador crypto hardware. A veces deshabilitar partes de offload mejora latencia aunque reduzca pico de velocidad — mira qué buscas.

MTU, MSS y "agujeros negros" de PMTUD

MTU incorrecto es clásico. Síntomas: throughput inestable, latencias raras bajo carga, páginas que se quedan cargando recursos. Solución: ajustar MTU experimentalmente (p. ej. WireGuard suele ir bien con 1420, pero no siempre), activar MSS clamping en router, comprobar no bloqueo de ICMP necesarios para PMTUD. Tras ajuste MTU jitter baja y throughput se estabiliza.

Lado servidor: limitaciones no obvias

Servidores VPN no son mágicos. Límites de sesiones, pool general de CPU, efectos NUMA, máquina virtual ruidosa vecina, todo influye. Para honestidad haz tests de noche y compara con pico. Si de noche throughput es 30–40% mejor, simplemente faltan recursos o uplink en el data center está saturado.

Optimización y tuning: victorias rápidas y soluciones duraderas

Elección de protocolo y cifrados

En 2026 para uso general la mejor base es WireGuard (UDP) con ChaCha20-Poly1305. Para redes con QoS/Firewall agresivo, modo transparente QUIC en 443/UDP (muchas implementaciones comerciales y algunos plugins open-source lo soportan). OpenVPN tiene sentido cuando buscas comportamiento complejo a nivel 7 y compatibilidad legacy, pero generalmente es más lento.

Configuración TCP/QUIC y gestión de buffers

Activa algoritmos modernos de control de congestión: BBRv2 en clientes y servidores suele mejorar en rutas largas con pérdidas. Para RTT cortos CUBIC sigue siendo confiable. Controla sysctls: rmem, wmem, tcp_timestamps, SACK, ECN. Para QUIC muchos clientes ya se adaptan dinámicamente, pero límites del sistema siguen siendo relevantes.

MTU/MSS, ECN y QoS contra bufferbloat

Elige MTU correcto y activa MSS clamping, base fundamental. Luego QoS: prioriza tráfico interactivo (DSCP CS6/EF para voz), limita fondos pesados en subida. Usa Cake o FQ-Codel en router gateway. El resultado suele ser dramático: jitter cae 2–3 veces, llamadas dejan de fallar, web se siente más rápida incluso si RTT igual.

Aceleración hardware y arquitectura

Si tropiezas con CPU, actualiza hardware (x86 con AES-NI, ARM modernos con núcleos crypto) o lleva cifrado más cerca del kernel (WireGuard en kernel space ya estándar). En velocidades 1–5 Gbps conviene NICs con offload y drivers sólidos. A veces sirve dividir usuarios en varios servidores pequeños, no un solo "monstruo" — NUMA y cachés lo agradecen.

Automatización e informes: pruebas como código

Scripts, contenedores y reproducibilidad

Empaqueta toda la metodología en scripts. Bash o Python, da igual. iperf3, fping/mtr, recogida de métricas del sistema, parsing a JSON/CSV. Monta servicios de prueba en Docker, fija versiones. Así podrás repetir test dentro de medio año y comparar manzana con manzana.

Scheduler, monitoreo y alertas

Lanza tests cortos cada hora: RTT, jitter, mini tráfico UDP. Si la gráfica comienza a subir, lo sabrás antes que los usuarios se quejen. Integra con Prometheus/Grafana o simple exportador CSV hacia sistema BI en la nube. Alertas a aumento del percentil 95 de jitter y caída del throughput TCP mayor a 30% respecto a la mediana base.

Informes para negocio y SLA

No sobrecargues con números. Muestra 3 cosas: throughput promedio, RTT mediano y percentil 95 de jitter, comparativos por protocolo y ubicaciones, y una conclusión en un párrafo: "Para videollamadas — ubicación A, para backups — ubicación B". Si tienes SLA interno, fija umbrales: por ejemplo, RTT a Europa no más de 80 ms, jitter no más de 25 ms, pérdidas menos de 1% en 95% del tiempo.

Errores frecuentes y anti-patrones

Túnel sobre túnel y magia excesiva

VPN dentro de VPN dentro de proxies suena seguro pero en la práctica es un caos de problemas MTU, handshakes extra y dolores de cabeza. Si necesitas multipath usa soluciones con MPTCP/QUIC o mecanismos nativos multi-canal. Evita cascadas de protocolos sin necesidad.

Ignorar la línea base y estadísticas

El mayor error es no medir primero sin VPN, luego con VPN bajo mismas condiciones y repitiendo. Un solo número no es número. Dos pruebas ya dicen algo. Tres o más permiten sacar conclusiones. Usa medianas y percentiles, no te fijes en "el mejor resultado".

Mala interpretación y conclusiones apresuradas

"VPN es malo porque el throughput bajó". Puede. O puede que tu proveedor limite tráfico por puerto, o CPU esté al límite, o MTU te asfixie. Analiza sistemáticamente: ruta, CPU, MTU, protocolo, y después cambia proveedor. Y registra todo lo que modificas para no perderte.

Ejemplos detallados de mediciones y casos 2026

Caso 1: WireGuard contra OpenVPN en giga hogareño

Línea base sin VPN: 930–940 Mbps TCP, RTT a Frankfurt 28 ms, jitter 2–3 ms. WireGuard: 820–860 Mbps TCP (4 flujos), UDP sin pérdidas hasta 900 Mbps, RTT 30–32 ms, jitter 4–6 ms. OpenVPN (UDP): 450–520 Mbps, RTT 35–38 ms, jitter 10–14 ms. Resultado: para backups y navegación general — WireGuard; para compatibilidad con routers viejos — OpenVPN, pero a costo de velocidad y jitter.

Caso 2: 5G SA + portátil, prioridad videollamadas

Línea base sin VPN: RTT 22–35 ms pero jitter salta 5–25 ms en pico y pérdidas hasta 1%. Con WireGuard: RTT 28–40 ms, jitter estabilizado 6–12 ms gracias a QoS en router (FQ-Codel). Test UDP a 6 Mbps sin pérdidas 0.6%, llamadas sin interferencias. Conclusión: VPN no debe acelerar, debe ser predecible. Con QoS y MTU adecuado mejor que sin VPN.

Caso 3: Oficina remota con Starlink

Línea base sin VPN: RTT 45–80 ms con saltos a 130 ms (cambio de satélite), jitter 8–25 ms. WireGuard + BBRv2: TCP throughput 180–220 Mbps (4 flujos), jitter estable 10–18 ms. OpenVPN: 120–160 Mbps y sensible a saltos. Recomendación: WireGuard, MTU 1420, MSS clamping, QoS ligero en subida y pruebas cada 2 horas para monitorear “ventanas satelitales”.

Guía paso a paso: lanzar tests en 60 minutos

Preparar el entorno

1) Dos VPS en ubicación deseada: uno con iperf3 y LibreSpeed, otro de reserva. 2) Instalar servidor iperf3 (iperf3 -s). 3) En cliente: iperf3, fping, mtr, speedtest-cli, tcpdump o Wireshark. 4) Configurar cliente VPN con registro de versión y configuración. 5) Tabla en Google Sheets o CSV local para resultados.

Línea base

Corre sin VPN: iperf3 TCP 60 s con -P 1 y -P 4, UDP con -b 50M+ hasta pérdidas ~1%. fping 300 paquetes, guarda percentiles. mtr 3 pruebas de 60 s. Guarda métricas CPU. Repite en distintas horas.

Prueba protocolos VPN

Conecta WireGuard. Repite misma batería. Luego OpenVPN UDP. Si el proveedor tiene modo QUIC, registra puerto 443/UDP. Cada protocolo con mismas pruebas y duraciones. Aleatoriza orden para no perjudicar al último por saturación.

Análisis e informes

Arma tablas: mediana TCP, percentil 95 RTT, jitter, pérdidas UDP a 50-100-200 Mbps. Marca escenarios: juegos, llamadas, backups. Da recomendaciones: “para llamadas — protocolo X, ubicación Y, MTU 1420, activar Cake; para backups — ubicación Z, -P 8, BBRv2”. Resultado: plan claro y aplicable, no “más o menos OK”.

Tendencias 2026: hacia dónde va el rendimiento VPN

Capas QUIC y mimetización en 443/UDP

QUIC ya es estándar. Muchos VPN ocultan tráfico como “QUIC normal”, saltando firewalls complejos y manteniendo baja latencia. No siempre es más rápido en picos, pero suele ser más predecible en colas y resistente a pérdidas. Para pruebas, añade modo QUIC a la matriz comparativa.

WireGuard como default y multipath

WireGuard es el “default” en la mayoría de casos. Apareció multipath — tráfico paralelo por Wi‑Fi+LTE, LTE+Starlink. En tests significa: ejecuta escenarios con un canal y con dos, mide estabilidad ante cortes y cambios, no solo números absolutos.

BBRv2, eBPF y aceleradores hardware

Algoritmos de control de congestión más agresivos y “inteligentes” reducen la “lentitud” de TCP en pérdidas, sobre todo en rutas largas. Profiling con eBPF es la norma: ver dónde se pierde rendimiento es más fácil. Aceleradores hardware de cifrado en chips masivos son más accesibles — resultado: VPN gigabit en hardware doméstico ya no sorprenden.

FAQ: respuestas rápidas

Respuestas rápidas para empezar

• ¿Con qué frecuencia testear VPN? Cada semana una prueba corta (RTT, jitter, un test TCP), cada mes un set completo con repeticiones. Al cambiar proveedor o protocolo, prueba extra.
• ¿Cuánto dura una prueba "correcta"? 30–60 segundos para flujos TCP/UDP, 5–10 minutos para estabilidad de jitter en llamadas. Más importante repetir y percentiles que un solo largo.
• ¿Vale la pena testear de noche? Sí. Comparar noche y pico muestra si cuello es saturación de ruta o servidor y no el cliente.

Métricas e interpretación

• ¿Qué métricas importan más? Juegos: RTT y jitter percentil 95. Llamadas: jitter y pérdidas. Backups: throughput TCP y estabilidad con 4–8 flujos.
• ¿Qué hacer si throughput cae 30%? Revisa CPU y cifrados, MTU/MSS, ruta (mtr) y luego intenta otra ubicación/puerto/protocolo. Normalmente culpa MTU o CPU.
• ¿Cómo detectar que MTU es culpable? Síntomas: páginas "se quedan pegadas", velocidad baja con más carga, aumentan retransmisiones. Se arregla con ajuste MTU y MSS clamping.

Práctica y herramientas

• ¿Se puede confiar en un solo speedtest? No. Es un indicador, no un diagnóstico. Usa iperf3, fping, mtr, mira rutas y repite pruebas.
• ¿WireGuard siempre es más rápido? Generalmente sí, pero no siempre. En rutas irregulares modo QUIC de algunas soluciones es más estable. Rendimiento es protocolo + ruta + hardware.