Acelerador VPN: funcionamiento y límites

El VPN Accelerator es el nombre comercial dado por Proton VPN a un conjunto de optimizaciones desplegadas en su infraestructura —algunas internas, otras fundadas en mecanismos estándar de transporte de red—. No es una categoría genérica de producto, sino un paquete propietario, activado por defecto (desactivable según la plataforma), concebido para actuar sobre la velocidad en condiciones de red específicas. Esta página explica lo que hace, cuándo produce un efecto, y lo que no es verificable de forma independiente.

Varios mecanismos bajo un solo nombre

1. Multiproceso OpenVPN. OpenVPN 2 es monohilo por proceso: un solo núcleo de CPU puede saturarse mientras los demás permanecen sin usar, creando un techo de velocidad debido no al ancho de banda sino a la capacidad de procesamiento. Proton dice redistribuir ese procesamiento en varios procesos paralelos. Este aspecto concierne específicamente a OpenVPN (WireGuard®, integrado al kernel Linux, gestiona ya el paralelismo de otro modo) —y más bien las conexiones de escritorio, habiendo Proton retirado OpenVPN de su aplicación Android—.

2. Segmentación del trayecto («split path»). El goodput TCP (velocidad útil neta de las retransmisiones) decrece a medida que latencia y pérdidas aumentan —de ahí los servidores cercanos para los tests de velocidad—. Una VPN alarga mecánicamente el camino. Proton documenta el hecho de fraccionar ese trayecto en segmentos más cortos (ejemplo: 600 ms tratados como dos veces 300 ms), ofreciendo cada segmento un mejor goodput. Esto no acorta físicamente Internet: es la explotación de la sensibilidad de TCP a la longitud de los caminos. La implementación precisa no se publica.

3. Optimización del forwarding. Pequeños bloqueos (stalls) pueden reducir fuertemente el pacing TCP; Proton descarga ciertas comunicaciones hacia «companion processes» y modifica la pila de red Linux de sus servidores para acortar el camino de los paquetes del «tráfico conocido», sobre una infraestructura bare-metal (no virtualizada). Es sin duda el componente más transversal —pero estas afirmaciones son las de Proton, no auditables desde el exterior—.

Los «400 %»: reales, pero bajo condiciones

Proton avanza una ganancia de velocidad hasta 400 % en los casos más favorables, precisando que esto se expresa en las conexiones de larga distancia y las redes con pérdidas. En una conexión local (usuario conectado a un servidor cercano en fibra, sin congestión), el impacto es netamente más limitado —es sin embargo la situación de la mayoría de los usuarios a diario—. Los beneficiarios reales son quienes se conectan a servidores lejanos, o desde redes móviles o de baja calidad.

Lo que no se puede verificar

Proton no publica la metodología de la cifra de 400 %: ni RTT objetivo, ni tasa de pérdida simulada, ni protocolo de referencia, ni servidores. La ganancia es verosímil en condiciones adversas y los mecanismos descritos son reales y documentados, pero la cifra no es reproducible de forma independiente. Las técnicas subyacentes (control de congestión TCP, multiproceso OpenVPN, tuning Linux) son conocidas en otros lugares de la industria; el mérito de Proton es haberlas agrupado y desplegado a escala. La afirmación de rendimiento sigue siendo la del proveedor, no una medición de un tercero.

Cómo constatar (o no) el efecto

Un test en un servidor cercano puede no mostrar nada: minimiza la latencia y enmascara precisamente los escenarios donde Proton dice tener más impacto. El test limpio compara en condiciones estrictamente idénticas (mismo servidor, misma hora, mismo dispositivo, mismo destino realmente lejano), opción activada y luego desactivada, en una transferencia bastante larga para estabilizar la velocidad. En una conexión local estable, la ausencia de diferencia es un resultado normal, no un mal funcionamiento —y si el cuello de botella es el wifi o el router, el acelerador no cambia nada (actúa del lado de los servidores Proton)—.