¿Internet solo funciona con la aplicación VPN encendida? Comprueba cuatro capas

Pruebas un cliente VPN gratuito o una extensión del navegador durante una semana, lo apagas y internet se detiene. El icono de Wi-Fi sigue mostrando conexión, los demás dispositivos del mismo router funcionan y lo único que devuelve la navegación es volver a activar la aplicación o desinstalarla. Ese patrón no es un cifrado que crea una dependencia. Es configuración que la aplicación escribió en un lugar que el túnel no posee.

El cliente cambia ajustes que no son del túnel

Un cliente de privacidad en Windows o macOS suele tocar tres sitios a la vez. Fija el proxy HTTP del sistema, el mismo campo que expone Internet Options. Instala un adaptador virtual, a menudo un controlador TAP, para poder capturar paquetes. Y reescribe la lista de resolutores, mientras que al pulsar desconectar solo desaparece el túnel.

Una extensión del navegador es algo más estrecho. Normalmente cambia su propio perfil o el proxy que sigue un solo navegador. Por eso un navegador puede fallar mientras las herramientas de línea de comandos siguen funcionando, o al revés: la extensión nunca tuvo autoridad para tocar las otras capas. Qué capa editó decide qué herramientas se rompen.

En cualquier caso, la decisión antigua la tomó un software que no tenía motivo para deshacerla. El túnel era la parte visible y también la única parte con una ruta de apagado limpia. Todo lo demás es un ajuste en un almacén que sobrevive al proceso, así que quitar la aplicación es el único paso que revierte las tres a la vez. Leer esos almacenes antes de reinstalar nada es lo que convierte el síntoma en un diagnóstico.

Tres restos, tres fallos distintos

El primer resto es un proxy que no apunta a nada: la casilla del proxy de LAN todavía marcada, o una URL de script de configuración dirigida a un puerto localhost donde ya no escucha ningún proceso. El navegador envía cada petición a ese puerto muerto y se queda colgado hasta que el tiempo de espera parece una red muerta. El segundo es un adaptador que aún posee una ruta predeterminada, porque un dispositivo TAP-Windows o un controlador de enrutamiento del proveedor sigue siendo una interfaz real tras desinstalar. Conserva la ruta que se le dio, y el tráfico desaparece en un túnel que no está. Ninguno de los dos restos se anuncia; ambos parecen exactamente una caída.

El tercero es DNS, y falla antes que los otros dos. Si la lista de resolutores solo contiene servidores accesibles por el túnel, cada consulta expira antes de pedir una sola página, así que el navegador informa de un sitio inalcanzable en lugar de un proxy muerto. Sea cual sea el que tengas, ninguno es una caída en el sentido de red. Cada uno es un resto que nadie revocó, y cada uno se repara en un lugar distinto.

Recorre las cuatro capas

Empieza lo más cerca de la aplicación y baja, porque las capas fallan en ese orden de visibilidad. Cambia una capa por prueba y vuelve a probar después de cada una. Restablecerlo todo a la vez suele devolver la navegación y te deja sin poder decir qué resto lo causó, así que la siguiente instalación recrea el mismo rompecabezas. El orden es proxy, adaptadores, rutas, resolutores.

En Windows cada comprobación es un solo comando que viene con el sistema operativo, así que no hay que instalar nada. Ejecútalos en orden y mantén la salida junta, porque las cuatro respuestas solo tienen sentido una al lado de otra. Informan del proxy, los adaptadores, las rutas IPv4 y la lista de resolutores, en ese orden:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux y macOS necesitan sus propios comandos, y no son intercambiables. En Linux las rutas vienen de ip route y el resolutor de resolvectl status donde lo posee systemd-resolved, con vuelta a cat /etc/resolv.conf. En macOS las rutas vienen de netstat -rn, los resolutores de scutil --dns y el proxy del sistema de scutil --proxy. Un lector de macOS que ejecute ip route obtiene command not found, y /etc/resolv.conf allí es un stub generado y no la configuración autoritativa. Comprueba la plataforma antes de comprobar la capa, o el primer comando se convierte en el hallazgo.

Para cada capa haz una pregunta: ¿este valor sigue apuntando a algo que existe mientras la aplicación está cerrada? Un proxy en un puerto muerto, un adaptador sin túnel, una ruta predeterminada por una interfaz caída y un resolutor dentro del túnel todos responden no. Un solo no basta para explicar el síntoma, por eso importa un cambio por prueba.

Un proxy no es un túnel

Un proxy acepta una petición, la busca en otro sitio y devuelve la respuesta, lo que significa que conoce el destino y ve todo lo que el sitio no cifró por su cuenta. No transporta otros protocolos. No protege la ruta salvo que el destino ya use TLS. Y puede cambiarlo quien lo instaló, sin tu intervención.

Esa distinción cambia la pregunta que merece la pena hacer. Cuando queda un proxy, averigua qué programa sigue dirigiendo tu navegador en lugar de si el túnel está levantado. El túnel puede estar perfectamente sano y ser del todo irrelevante para el fallo.

Si quieres saber qué hizo realmente ese cliente, obsérvalo en lugar de leer su panel. Process Monitor registra qué claves del registro y archivos toca, mientras que una captura de paquetes revela adónde fue su tráfico. Ambas son herramientas corrientes, y ambas responden mejor la pregunta del resto que cualquier luz de estado. Ninguna necesita que la aplicación siga en marcha.

Quita el componente, no las pruebas

La solución duradera es quitar lo que escribió el ajuste. Desinstala la aplicación, borra el adaptador virtual que añadió, limpia el proxy y la lista de resolutores, reinicia y prueba con la aplicación aún desinstalada. Si en ese punto la navegación funciona, has encontrado la causa y no un apaño. Anota qué capa estaba obsoleta, porque el mismo proveedor suele repetir el mismo error dos veces.

Si el síntoma vuelve después de instalar el siguiente cliente, recorre otra vez las cuatro capas antes de decidir que el servicio ha roto algo. Las pruebas suelen seguir ahí, en uno de los cuatro sitios. Una segunda aplicación no crea una quinta capa; edita una de las cuatro.

Reinstalar restablece el proxy pero no un adaptador obsoleto, y puede dejar dos resolutores en la lista. Esa asimetría es la razón por la que desinstalar-y-probar gana a un botón de restablecerlo todo. También te da una línea base con la que comparar la próxima vez que caiga la conexión.