Por qué tu VPN WireGuard puede ir lenta cuando viajas al extranjero

Actualizado: 2 de noviembre de 2026

Introducción

Muchos usuarios se sorprenden cuando se conectan desde otro país al servidor WireGuard de su router GL.iNet y descubren que la velocidad de Internet es muy inferior a la conexión gigabit simétrica de su casa o a la conexión igualmente rápida del alojamiento en el extranjero, por ejemplo, un Airbnb. Varios factores pueden contribuir a esta diferencia: el enrutamiento y el peering del ISP, la congestión de la red, la capacidad de procesamiento del router y el comportamiento de las aplicaciones que se comunican a través del túnel VPN.

¿Qué es la latencia y por qué importa?

La latencia es el tiempo que tardan los datos en viajar desde tu dispositivo hasta el servidor VPN y volver. Suele medirse en milisegundos (ms). Por ejemplo, si tu router GL.iNet en Vietnam se conecta a un servidor VPN en Texas, el tiempo de ida y vuelta (RTT) puede alcanzar fácilmente 250-300 ms.

Una latencia alta no reduce por sí misma la capacidad de reenvío de paquetes de WireGuard. A diferencia de TCP, el transporte de datos de WireGuard, basado en UDP, no utiliza confirmaciones ni ventanas de congestión para regular la transmisión de paquetes de datos ordinarios. Por ejemplo, un túnel WireGuard con 300 ms de RTT puede mantener teóricamente el mismo rendimiento de reenvío de paquetes que otro con 3 ms de RTT, si el ancho de banda disponible, la pérdida de paquetes y la capacidad de procesamiento son comparables.

Las aplicaciones que se comunican a través del túnel VPN suelen utilizar TCP o QUIC, que dependen de la información que devuelve el extremo receptor. Enrutar el tráfico por un servidor VPN distante puede aumentar el RTT que experimentan esas aplicaciones. Esto puede afectar a su rendimiento, pero no determina si el cuello de botella es el comportamiento del transporte, la ruta de red o el procesamiento del router.

El comportamiento de las aplicaciones también importa. Abrir archivos de una carpeta compartida remota o copiar muchos archivos pequeños puede implicar solicitudes y respuestas repetidas entre tu dispositivo y el servidor. Cada ida y vuelta necesaria añade retardo, por lo que estas tareas pueden parecer lentas incluso si la conexión permite descargar rápidamente un único archivo grande. Aumentar la ventana de recepción TCP no elimina esas esperas de la aplicación.

Relación entre el rendimiento de TCP y la latencia

Una relación útil para comprender el rendimiento de TCP en conexiones de alta latencia es el producto ancho de banda-retardo (BDP):

Producto ancho de banda-retardo = Rendimiento x RTT

El BDP describe cuántos datos deben permanecer en tránsito, es decir, enviados pero aún sin confirmar, para mantener un rendimiento determinado en una conexión con un RTT dado. Sin embargo, esta relación por sí sola no establece el rendimiento máximo alcanzable ni identifica el factor limitante de una conexión de red concreta.

Por ejemplo, mantener 100 Mbps de rendimiento TCP con un RTT de 288 ms requiere aproximadamente 3.6 MB de datos en tránsito sin confirmar, suponiendo que la ruta de red y los extremos puedan soportar esa velocidad.

Estas son algunas definiciones importantes:

• Ventana de recepción TCP (rwnd): La cantidad de datos adicionales que el dispositivo receptor anuncia que puede aceptar según el espacio disponible en su búfer de recepción.
• Ventana de congestión TCP (cwnd): La cantidad de datos sin confirmar que el emisor puede mantener según su algoritmo de control de congestión y las condiciones de la red.
• Rendimiento: La velocidad efectiva a la que se transfieren correctamente los datos
• RTT (tiempo de ida y vuelta): El tiempo necesario para que los datos viajen entre los extremos y vuelva una respuesta.

El límite efectivo de datos TCP pendientes del emisor depende de la menor entre la ventana de recepción y la de congestión, además de otras restricciones. Esta distinción es importante: una ventana de recepción suficientemente grande no garantiza un rendimiento alto si el control de congestión o la ruta de red impiden que el emisor mantenga suficientes datos pendientes.

La pérdida de paquetes puede reducir el rendimiento de TCP al exigir retransmisiones y hacer que el emisor reduzca su ventana de congestión. En una conexión con alta latencia, la información de retorno y la recuperación pueden tardar más, por lo que una ventana de recepción grande puede no bastar para mantener transferencias rápidas.

Un ejemplo real de un miembro del subreddit de GL.iNet

Un miembro del subreddit de GL.iNet en Vietnam comunicó los siguientes resultados al conectarse a su servidor WireGuard doméstico en Texas, que funcionaba en un router GL.iNet Flint 2.

• Ubicación del servidor: Texas, EE. UU.
  
  • Velocidades locales (fibra simétrica) 700 Mbps de descarga / 940 Mbps de subida
• Ubicación del cliente: Vietnam
  
  • Velocidades locales (sin VPN): 455 Mbps de descarga / 634 Mbps de subida
    
  • Velocidades locales (con el cliente VPN WireGuard activado): 47.3 Mbps de descarga / 12.1 Mbps de subida, 288 ms de ping

Recuerda que, al descargar a través de un servidor VPN en casa, el rendimiento máximo de descarga también depende de la velocidad de subida de la conexión doméstica.

Estas mediciones muestran una diferencia considerable entre el rendimiento de Internet local y el obtenido mediante la conexión internacional WireGuard. Sin embargo, las pruebas no miden necesariamente rutas de red equivalentes. Una prueba local en Vietnam puede conectarse a un servidor cercano, mientras que el tráfico enrutado por la VPN debe atravesar primero la conexión internacional hasta Texas. Esto introduce distintas redes de tránsito de los ISP, acuerdos de peering y posibles puntos de congestión. Dos conexiones internacionales con latencias similares pueden ofrecer velocidades muy distintas según la calidad de sus rutas. Aunque la conexión VPN registró aproximadamente 288 ms de RTT, esa medición por sí sola no demuestra que la latencia fuera la causa principal del menor rendimiento. La pérdida de paquetes, un enrutamiento internacional ineficiente, la congestión u otros factores pueden haber contribuido.

Primero, veamos algunos factores habituales que pueden afectar al rendimiento de la red:

1. Variaciones del rendimiento del ISP y congestión en tu zona: El rendimiento puede variar considerablemente según la congestión y la carga de la red.
2. Rendimiento del Wi-Fi: Muy variable según el entorno físico, las interferencias de otros dispositivos inalámbricos, la capacidad del dispositivo cliente y la naturaleza semidúplex del Wi-Fi, frente al Ethernet dúplex completo
   • Para una explicación detallada del rendimiento real del Wi-Fi, lee aquí: https://www.wiisfi.com/
3. Enrutamiento del ISP y peering internacional: El tráfico entre países puede atravesar varias redes operadas de forma independiente. Los enlaces de peering congestionados, las rutas ineficientes o la pérdida de paquetes pueden reducir mucho el rendimiento, aunque ambos extremos tengan conexiones locales rápidas. Dos rutas internacionales con RTT similares pueden ofrecer velocidades muy diferentes.

La congestión del ISP local y las condiciones del enrutamiento internacional suelen quedar fuera del control directo del usuario, aunque probar otros ISP o rutas puede ayudar a detectar diferencias de rendimiento. Un enrutamiento internacional deficiente o un peering congestionado son sospechosos habituales cuando ambos extremos tienen Internet local rápido, pero la ruta de larga distancia es lenta. Una prueba desde otro ISP, por ejemplo en una cafetería, o un punto de acceso móvil puede indicar si la ralentización está en la ruta. Las limitaciones del Wi-Fi suelen reducirse utilizando Ethernet por cable siempre que sea posible. También conviene investigar las limitaciones de procesamiento del router y los problemas de MTU al diagnosticar el rendimiento de la VPN.

En definitiva, averiguar por qué una conexión VPN internacional es lenta exige distinguir entre las limitaciones de la ruta de red, del router VPN y de las aplicaciones que se comunican por el túnel.

Escalado de ventana TCP para mejorar el rendimiento

Originalmente, la ventana de recepción TCP estaba limitada a unos 64 KB. El escalado de ventana (RFC 7323) eleva ese límite a aproximadamente 1 GiB, y los sistemas operativos modernos ajustan la ventana automáticamente. Por ejemplo, la configuración de ajuste automático Normal documentada por Microsoft puede representar ventanas de recepción de unos 16.8 MB. Por tanto, las conexiones TCP modernas no están limitadas de forma inherente a 64 KB.

Fuente: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Cómo interactúan los límites de ventana TCP con el RTT

En una conexión TCP con un límite fijo de datos pendientes, el techo aproximado de rendimiento asociado a la ventana es:

Rendimiento en bits por segundo ≈ Límite de ventana en bytes × 8 ÷ RTT en segundos

Si ese límite de ventana se mantiene constante, un RTT mayor produce un techo menor asociado a la ventana. Los siguientes ejemplos ilustran esta relación; no predicen el rendimiento real de la VPN.

Techos teóricos asociados a la ventana (ventana ÷ RTT), usando 1 MB = 1,000,000 bytes. Son ejemplos ilustrativos, no predicciones del rendimiento real de la VPN.

El rendimiento real también depende del control de congestión, la pérdida de paquetes, el ancho de banda disponible y los límites de procesamiento. Varias conexiones TCP pueden lograr a veces un rendimiento agregado mayor, pero no existe un umbral universal de RTT a partir del cual no puedan aprovechar todo el ancho de banda disponible.

En el ejemplo Vietnam-Texas, una hipotética conexión TCP única limitada a 2 MB de datos pendientes con 288 ms de RTT tendría un techo asociado a la ventana de unos 55.6 Mbps. La fila de 300 ms de la tabla es algo inferior por su mayor RTT. Sin embargo, esto no establece por qué el usuario midió 47.3 Mbps.

Sin conocer el número de conexiones de la prueba, las ventanas TCP reales y las condiciones de la red, no podemos determinar si el cuello de botella era un límite de ventana, la congestión, la pérdida de paquetes, el enrutamiento del ISP u otro factor.

¿Qué determina el tamaño de tu ventana TCP?

Los tamaños de ventana TCP pertenecen a cada conexión y pueden cambiar durante la transferencia de datos. Por tanto, los valores de ejemplo anteriores no deben considerarse ajustes fijos aplicables a todas las conexiones de tu dispositivo.

El sistema operativo del dispositivo receptor gestiona su ventana de recepción. El tamaño depende de factores como el espacio disponible en el búfer de recepción, el ajuste automático y los límites del sistema operativo, la configuración de la aplicación y la rapidez con la que esta consume los datos entrantes. Al descargar un archivo en tu portátil, este anuncia su ventana de recepción al servidor emisor. Al subirlo, el servidor receptor anuncia su ventana al portátil.

El emisor gestiona por separado su ventana de congestión según su algoritmo de control de congestión y la información que recibe de la red. Esto puede limitar los datos pendientes incluso cuando el receptor anuncia una ventana grande. En una configuración WireGuard típica entre routers, estas ventanas TCP pertenecen a los ordenadores y servidores que se comunican; no son un único ajuste de tamaño de ventana en los routers VPN.

¿Cómo puedes comprobar una conexión real?

Si tienes experiencia en análisis de paquetes, Wireshark puede mostrar la ventana de recepción TCP anunciada. En una configuración entre routers, captura el tráfico en el ordenador que realiza la transferencia. Inicia la captura antes de establecer una nueva conexión TCP para que Wireshark registre el intercambio inicial y la negociación del escalado de ventana. Durante una descarga, examina una confirmación TCP saliente de tu ordenador correspondiente a esa transferencia, despliega la sección Transmission Control Protocol y busca Calculated window size. Este valor muestra la ventana de recepción que tu ordenador anunció en ese momento, con el escalado aplicado si Wireshark conoce el factor negociado.

Ese valor puede cambiar durante la transferencia. No revela directamente la ventana de congestión del emisor ni demuestra que la ventana de recepción limite el rendimiento. Comprobar el ajuste automático del sistema operativo tampoco indica la ventana real que una conexión concreta está anunciando en ese momento.

Otro ejemplo real: más velocidad sin reducir el ping

En otro caso de soporte, investigué una conexión VPN Tailscale lenta. Tailscale utiliza el cifrado de WireGuard, pero sus opciones de retransmisión pueden transportar los paquetes cifrados de distintas maneras: los relés DERP utilizan conexiones basadas en TCP, mientras que los Tailscale Peer Relays usan UDP. Esto difiere de una conexión WireGuard independiente, que normalmente envía sus paquetes cifrados directamente por UDP. En este caso, ambos relés estaban autoalojados en la misma instancia de AWS Lightsail, así que la comparación era entre dos métodos de retransmisión alojados de forma privada, y no con los servidores DERP públicos de Tailscale.

La conexión a Internet del cliente alcanzó unos 83 Mbps en la prueba, mientras que la del servidor VPN registró una velocidad de subida de unos 40.6 Mbps. Se observaron las siguientes velocidades de descarga:

SQM significa Smart Queue Management, una función del router que gestiona las colas de paquetes y reduce el retardo excesivo bajo carga. En esta comparación, SQM se activó o desactivó en el router de viaje del lado del cliente.

SQM no es una solución universal para las velocidades VPN lentas. Cuando solo detecta un único flujo de túnel cifrado, no puede priorizar por separado las conexiones de las aplicaciones ocultas en su interior. Puede seguir gestionando la cola de paquetes compartida, pero esto solo reduce el retardo en la cola cuando la acumulación excesiva de paquetes es un problema que puede resolver. Si no hay una acumulación excesiva de paquetes que SQM pueda controlar de forma útil, una configuración de ancho de banda innecesariamente restrictiva o una carga de procesamiento adicional pueden reducir el rendimiento sin mejorar la capacidad de respuesta.

La latencia se mantuvo prácticamente igual, pero el relé basado en UDP ofreció un rendimiento mucho mayor tanto con SQM activado como desactivado. La mayor mejora acompañó al cambio de método de retransmisión, no a una reducción del ping ni a la desactivación de SQM.

Una posible causa es el transporte basado en TCP de DERP. Cada dispositivo Tailscale se conecta al relé DERP por TCP, por lo que los paquetes cifrados pasan por conexiones TCP separadas a ambos lados del relé. Varias conexiones de aplicaciones dentro del túnel pueden compartir estas conexiones TCP externas. Si se pierden datos en una conexión TCP externa, los datos posteriores pueden tener que esperar a la retransmisión antes de entregarse, lo que podría retrasar varias aplicaciones a la vez. Un Peer Relay basado en UDP evita esta capa adicional de transporte TCP ordenado, aunque las aplicaciones TCP dentro del túnel siguen usando sus propias confirmaciones y control de congestión.

Como ambos relés se ejecutaban en la misma instancia, el host y su ubicación permanecieron constantes. Esto refuerza la interpretación de que el transporte o la implementación del relé contribuyeron a la mejora, en lugar de simplemente acercar el relé a los usuarios. Sin embargo, usar el mismo host no garantiza rutas ni condiciones de red idénticas, por lo que la comparación no aísla TCP frente a UDP como única causa.

Estas son observaciones de un único caso de soporte, no cifras de rendimiento garantizadas. Sin embargo, demuestran por qué la latencia por sí sola no basta para predecir la velocidad de una VPN.

Conclusión

Espero que este artículo haya aclarado por qué las velocidades de descarga y subida de las conexiones VPN WireGuard de larga distancia pueden ser mucho menores que las velocidades de Internet disponibles en cualquiera de sus extremos. La distinción más importante es que WireGuard por sí mismo no impone un techo de rendimiento dependiente del RTT. Su transporte de datos basado en UDP no implementa ventanas de congestión, confirmaciones ni retransmisiones de tipo TCP para los paquetes de datos ordinarios.

Sin embargo, las aplicaciones TCP y QUIC que se comunican a través del túnel siguen sujetas a sus propios mecanismos de control de congestión y fiabilidad. Un RTT mayor aumenta los datos pendientes necesarios para mantener un rendimiento dado. Varias conexiones pueden mejorar el rendimiento agregado, pero ni el RTT ni el número de conexiones determinan por sí solos la velocidad alcanzable. El rendimiento real también depende de la pérdida de paquetes, la congestión, el enrutamiento y el peering del ISP, el ancho de banda disponible, la configuración de MTU y la capacidad de procesamiento del router VPN.

En una configuración WireGuard típica entre routers GL.iNet, las conexiones TCP se establecen entre los dispositivos finales y sus servidores de destino. Los routers VPN cifran, descifran y reenvían paquetes sin controlar directamente las ventanas de recepción TCP de esas conexiones de extremo a extremo. Aunque las limitaciones del hardware del router pueden afectar al rendimiento de los paquetes cifrados, no deben confundirse con las de la ventana de recepción TCP.

Al diagnosticar una conexión WireGuard internacional lenta, empieza por probar la conexión a Internet de cada ubicación, usando Ethernet por cable si es posible. Comprueba si el rendimiento de la VPN cambia según la hora del día o al usar otra conexión, como un punto de acceso móvil. Estas comparaciones pueden ayudar a localizar la ralentización, aunque quizá hagan falta pruebas más detalladas para identificar la causa. Una latencia alta puede contribuir a que las aplicaciones vayan lentas, pero no debe considerarse automáticamente la única explicación de una VPN lenta.

De cara al futuro, espero experimentar con relés UDP situados estratégicamente para comprobar si rutas alternativas pueden mejorar el rendimiento de la VPN WireGuard entre Estados Unidos y Asia.

Para obtener más información y consejos sobre cómo resolver problemas y comprender tu configuración VPN de WireGuard, consulta la siguiente publicación del foro de GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502