¿Ralentiza una VPN siempre la conexión? No necesariamente, y rara vez tanto como se cree. La pérdida de velocidad depende de una combinación de factores —algunos ligados al proveedor, otros a tu instalación, otros aún a la infraestructura de Internet—. Esta página desmonta las explicaciones perezosas e identifica lo que realmente cuenta.
¿Ralentiza una VPN siempre?
En la mayoría de los casos, sí, ligeramente: es estructural —el tráfico toma un camino más largo, transita por un servidor intermedio y sufre un cifrado en cada extremo—. En una línea estable, con un servidor cercano y un protocolo eficiente, la pérdida puede seguir siendo moderada y a veces poco perceptible. Y existen casos —minoritarios pero documentados— en que una VPN restablece una conexión degradada, cuando un proveedor de Internet limita ciertos tráficos.
Lo que mide un test de velocidad
La velocidad de bajada (download) condiciona streaming, descargas y videollamadas. La velocidad de subida (upload) cuenta para las videoconferencias y transferencias cloud. La latencia (ping), en milisegundos, es el parámetro más sensible para los usos en tiempo real (juego, VoIP). El ancho de banda es el volumen máximo transportable por unidad de tiempo —el límite que la VPN se acerca sin jamás superar—. Una VPN puede afectar poco la velocidad pero más la latencia, o lo inverso, según la distancia y el enrutamiento.
Cómo probar correctamente
Prueba primero sin VPN (velocidad de bajada, de subida, latencia), luego con la VPN en el servidor deseado, con la misma herramienta; repite dos a tres veces para suavizar las variaciones. Condiciones idénticas imperativas: mismo dispositivo, misma herramienta, misma franja horaria, conexión por cable de preferencia (el wifi enmascara el efecto real). Compara luego un servidor cercano y un servidor lejano: una degradación masiva en servidor cercano señala un problema de infraestructura.
Los factores que realmente cuentan
Distancia y enrutamiento: cada router y punto de intercambio atravesado añade latencia y riesgo de congestión; pero la distancia no lo es todo —la calidad del peering también es determinante (un servidor a 500 km bien enrutado puede ganarle a un servidor a 200 km mal encaminado)—. Las VPN solo tienen una influencia parcial sobre ese trayecto. Carga y calidad del servidor, hardware local (un router antiguo se vuelve un cuello de botella independientemente de la VPN; ciertos antivirus con inspección de paquetes también pesan), y throttling del proveedor de Internet: el cifrado impide al proveedor de Internet inspeccionar finamente la naturaleza del tráfico —sin ocultar el uso de una VPN—, lo que puede a veces restaurar una parte del rendimiento perdido.
Congestión: CUBIC vs BBR
La velocidad no depende solo del ancho de banda, sino también de la gestión de la congestión —punto rara vez explicado—. En TCP, el algoritmo histórico CUBIC es loss-based: detecta la congestión vía las pérdidas de paquetes y reduce la velocidad, lo que lo penaliza en los enlaces de larga distancia con alta latencia (confunde pérdida y congestión). BBR (Bottleneck Bandwidth and Round-trip propagation time) modela de forma continua el ancho de banda real y el tiempo de trayecto para mantener una velocidad óptima; en enlaces intercontinentales, la diferencia puede ser sustancial. Este mecanismo solo se aplica a los protocolos transportados sobre TCP: OpenVPN en modo TCP se beneficia de él, WireGuard (UDP) no está concernido a nivel del túnel.
Algunos proveedores documentan optimizaciones en ese sentido. Proton presenta por ejemplo su acelerador VPN como un conjunto de técnicas que actúan sobre la repartición de CPU, el camino de red y el uso de BBR. Es un ejemplo interesante de documentación técnica de proveedor, pero sigue siendo una descripción de proveedor, no una garantía universal de rendimiento.
Protocolo y velocidad
El protocolo influye, sin ser nunca el único factor. WireGuard® (UDP) busca un rendimiento elevado vía un código compacto y una criptografía moderna. OpenVPN funciona en UDP (preferible para el rendimiento) o TCP (útil en redes restrictivas). IKEv2/IPSec conserva un interés en móvil gracias a MOBIKE, que permite a la conexión sobrevivir a un cambio de IP. Del lado de las tecnologías propietarias: NordLynx está construido sobre WireGuard®, Lightway es un protocolo distinto de ExpressVPN (UDP/TCP), y Nexus (Surfshark) no es un protocolo sino una arquitectura de red SDN que pilotea el enrutamiento a escala de la infraestructura.
Cuándo una VPN mejora la experiencia
Caso minoritario pero real: en caso de throttling dirigido por el proveedor de Internet, en un mal enrutamiento por defecto hacia un destino lejano, o en redes públicas/de empresa que filtran agresivamente, un túnel puede restablecer un acceso normal. Estas situaciones están documentadas pero no constituyen una regla —presentarlas como una garantía sería inexacto—.
¿Qué velocidad basta?
Una pérdida de velocidad medida no significa una degradación perceptible: lo que cuenta es la velocidad restante frente a las necesidades. Netflix recomienda cerca de 3 Mbps para la HD 720p, 5 Mbps para la Full HD 1080p y 15 Mbps para la UHD 4K; YouTube publica referencias cercanas. Estos valores evolucionan y se citan como órdenes de magnitud, no como umbrales absolutos. Pasar de 200 a 160 Mbps con la VPN no tiene ninguna incidencia funcional para el streaming o la navegación; en cambio, para el juego o una latencia baja, la elección del servidor y del protocolo merece atención.
Preguntas frecuentes
¿Es rápida una VPN gratuita? Rara vez de forma consistente: limitaciones de ancho de banda, servidores muy compartidos, ubicaciones restringidas degradan el rendimiento independientemente del protocolo. ¿Y para el juego? Puede aumentar la latencia, sobre todo si el servidor VPN está lejos del servidor de juego —elegir un servidor cercano es indispensable, siendo WireGuard a menudo el mejor adaptado—. ¿Qué protocolo para la velocidad? WireGuard® en conexiones estables, IKEv2 en móvil, OpenVPN-UDP como alternativa sólida —el rendimiento depende también de la implementación del proveedor—. ¿Basta la velocidad para predecir la experiencia? No: la estabilidad en el tiempo (variaciones de latencia entre paquetes) juega un papel importante que un test puntual no revela.