VPN o proxy: qué cubre cada uno y qué no

Tanto una VPN como un proxy directo cambian la dirección que ve un sitio web, y ahí se detienen la mayoría de las comparaciones. La diferencia que decide tu configuración es la cobertura: un proxy directo es un intermediario que tu aplicación elige usar, a diferencia del proxy inverso que se sitúa delante de un sitio web, mientras que una VPN mueve todo lo que el sistema operativo enruta hacia un túnel. El cifrado, el manejo de DNS y el comportamiento ante fallos se derivan de esa división. Ejecuta estas cinco comprobaciones en orden, y la primera que falle te dirá qué herramienta necesitas en realidad.

¿Qué aplicaciones cubre el intermediario?

Una extensión de proxy del navegador se aplica solo a ese perfil del navegador. Los clientes de correo, los gestores de paquetes y un segundo navegador siguen usando su propia configuración, y algunas aplicaciones ignoran por completo las variables de proxy del sistema. Una VPN cubre lo que la tabla de enrutamiento envía al túnel, que puede ser todas las aplicaciones o un subconjunto en túnel dividido según las rutas y la política del cliente.

Prueba las aplicaciones que importan en lugar de extrapolar a partir de una sola carga de página. curl https://ifconfig.me sigue las variables de proxy del entorno; una aplicación de escritorio puede que no. En Windows, netsh winhttp show proxy muestra el proxy WinHTTP que usan los servicios, y esa es una configuración distinta de la del navegador.

¿Está cifrado el salto y dónde termina TLS?

Un protocolo de proxy es un punto de encuentro, no una garantía. SOCKS5 reenvía TCP sin cifrarlo, y un proxy HTTP simple transporta la línea de solicitud y las cabeceras en texto claro. HTTPS a través de un proxy usa CONNECT, así que tu sesión TLS sigue terminando en el destino, no en el proxy. La guía de MDN sobre servidores proxy y tunelización describe esa distinción desde el lado del protocolo.

Una VPN cifra el tramo entre tu dispositivo y su punto final. Más allá del punto final se aplican las mismas reglas que en cualquier otra red, y por eso un túnel por sí solo no protege una aplicación que envía credenciales por HTTP simple. Ninguno de los dos diseños oculta una cuenta con sesión iniciada, una cookie ni una huella del navegador.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

La salida detallada muestra si curl emitió CONNECT al puerto 443 o un GET simple con una URL completa. Con socks5h:// el proxy recibe el nombre de host dentro de la solicitud SOCKS5 y luego retransmite un TLS que no puede leer, así que ve el nombre y el recuento de bytes. A través de un proxy http://, una URL https:// es un CONNECT, así que ese proxy también ve el nombre y el volumen del destino, pero no la solicitud ni el cuerpo de la respuesta.

¿Qué resolutor ve el nombre?

La resolución de nombres puede ocurrir localmente antes de que salga la solicitud, o de forma remota en el proxy. Con curl, socks5h:// envía el nombre de host al proxy mientras que socks5:// lo resuelve primero localmente. La configuración de proxy del navegador ofrece una opción de DNS comparable, y los archivos PAC pueden enrutar distintos hosts de distintas maneras.

Dos protocolos pueden eludir un proxy sin ningún error de configuración. WebRTC recopila candidatos por STUN, y QUIC ejecuta HTTP/3 sobre UDP, que un proxy TCP no puede transportar. El navegador volverá a TCP si UDP 443 está bloqueado, así que bloquear UDP 443 en el cortafuegos del host (o en el router para toda una red), y no un indicador del navegador, es la forma fiable de mantener HTTP/3 dentro de la ruta del proxy.

Comprueba el resolutor desde la perspectiva del destino, no desde la de tu portátil. Una solicitud que llega con la dirección de salida del proxy pero con un nombre resuelto localmente sigue diciendo al resolutor local qué sitios visitas.

¿Qué ocurre cuando falla el intermediario?

Un proxy explícito falla cerrado: detén el proceso del proxy y el navegador o la aplicación devuelve un error de conexión en lugar de salir directamente. Las configuraciones PAC y WPAD son las que fallan abiertas - si el script no se puede obtener, el cliente recurre a DIRECT y el sitio vuelve a ver tu dirección real. Una VPN puede fallar abierta o cerrada según el cliente y según si hay un kill switch o una regla de cortafuegos activos.

Prueba el caso de fallo a propósito: detén el servicio de proxy y recarga; si obtienes una página de error en lugar de una carga directa, apunta la URL del PAC a un host inalcanzable para ver el respaldo. Si la página sigue cargando por tu ruta habitual, el proxy no ofrece ninguna protección contra su propia caída, y esa es una propiedad que deberías conocer antes de confiar en él.

El orden decide lo que ve el sitio. Un proxy cuyo tráfico saliente viaja por la VPN deja al sitio viendo la dirección del punto final de la VPN; pon el proxy fuera del túnel (VPN hacia un proxy en un host remoto) y el sitio verá en su lugar la dirección de salida de ese proxy. En cualquier caso, los dos saltos pueden registrar cosas distintas.

Cinco comprobaciones, en orden

La lista de comprobación de abajo es toda la decisión en un solo lugar. La cobertura va primero porque elimina la mayoría de los desajustes: si la aplicación que debe cubrirse no respeta la configuración, nada más adelante en la lista la salva.

Luego confirma el resultado con la aplicación que motivó el cambio. Carga una página en el navegador configurado, obtén la misma página con curl y compara la dirección que reporta cada uno. Si no coinciden, sigue habiendo una extensión, una regla PAC o una anulación a nivel de aplicación, y ningún ajuste del túnel lo arreglará.

Anota lo que configuraste: qué aplicaciones usan el proxy, si el DNS es local o remoto, si UDP está bloqueado y cuál es el comportamiento ante fallos. Ese pequeño inventario es lo que hace posible la siguiente comparación, porque «la IP cambió» nunca te dijo cuál de estas cinco comprobaciones se superó.