¿El VPN funciona pero una app no tiene internet? Revisa su proxy

Tu túnel está activo, la página de estado muestra un handshake correcto, pero una aplicación sigue sin cargar nada. Esa aplicación probablemente todavía envía sus peticiones a un intermediario más antiguo: un proxy del sistema, una extensión, un archivo de configuración empujado por la gestión de dispositivos o una variable de proxy que solo lee su propio proceso. Cambiar de servidor VPN no tocará ese ajuste, y eso explica el patrón en el que otras aplicaciones funcionan desde el mismo equipo. Trabaja desde la aplicación que falla hacia fuera y deja el túnel tranquilo hasta que la cuestión del proxy esté resuelta.

Qué capa posee el ajuste del proxy

Cuatro lugares pueden reclamar autoridad sobre las peticiones de una app, y el más estrecho suele ganar. El sistema operativo tiene un proxy global y una URL de configuración automática opcional; un navegador puede seguirla, anularla o ceder el control a una extensión; una herramienta de línea de comandos lee su propio entorno; y una política gestionada puede fijar de nuevo cualquiera de las anteriores tras un cambio. Decide qué capa manda antes de editar nada, porque borrar la capa equivocada parece una corrección exitosa que vuelve en el siguiente inicio de sesión.

Compara dos aplicaciones contra el mismo sitio web normal en lugar de contra una página de prueba solo para VPN. Si el navegador falla mientras una descarga en la terminal funciona, el sistema operativo no es el problema, y la diferencia está en el perfil del navegador o en sus extensiones. Si ambas fallan pero una segunda cuenta de usuario en el mismo equipo funciona, el ajuste es por usuario. Esa comparación cuesta un minuto y elimina la mayor parte de las conjeturas.

Lee el valor que cada herramienta usa realmente

Imprime la configuración antes de cambiarla y copia la cadena de proxy exacta en un lugar desde el que puedas restaurarla. Las variables del shell son la comprobación más rápida para herramientas de línea de comandos, porque un cliente VPN normalmente las deja intactas.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Ejecuta solo la línea que corresponde a la plataforma que tienes delante y luego lee la salida para el host, el puerto y las credenciales. Un valor como http://proxy.corp.example:8080 significa que la herramienta pregunta a ese host por cada petición, mientras que un resultado vacío significa que va directa y que la falla real está en otro sitio. Tapa la parte de usuario y contraseña antes de pegar la salida en un ticket, porque esas cadenas son credenciales vivas mucho más a menudo de lo que la gente supone.

Las herramientas con su propio motor de proxy necesitan sus propias pruebas. Curl indica la decisión que tomó cuando subes la verbosidad, lo que vale más que adivinar a partir del entorno, y el mismo indicador muestra si la resolución de nombres ocurrió localmente o en el proxy.

Borra la anulación y vuelve a probar la misma petición

Cambia una capa y luego repite exactamente la petición que falló, porque otra URL no demuestra nada. Borra primero las variables de entorno en el shell actual, ya que ese cambio es reversible y no puede romper el túnel:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Si la salida detallada sigue afirmando que hay un proxy, el entorno no era la autoridad. Sube un nivel en lugar de apilar más anulaciones.

En macOS, comprueba que un archivo de configuración automática no esté aportando el valor, luego desactiva el proxy del servicio y confirma el cambio. En Windows, recuerda que el ajuste WinHTTP y el ajuste del navegador por usuario son objetos distintos, así que una herramienta de línea de comandos limpia puede convivir con un navegador que aún apunta a un servidor antiguo. Las extensiones merecen la misma sospecha: una extensión de proxy puede reescribir peticiones solo para un perfil, y esa es exactamente la forma de una falla que afecta a un navegador y a nada más.

Comprueba que la corrección sobrevive a un reinicio

Un ajuste que solo funciona en la terminal que editaste no está corregido. Vuelve a abrir la aplicación desde el lanzador del escritorio, cierra sesión y vuelve a entrar, y observa si el proxy antiguo regresa.

Dos comprobaciones separan una corrección real de una temporal, y ambas deberían informar de una conexión directa o del valor previsto. La ejecución en un entorno limpio muestra si un proceso depurado sigue tomando un ajuste del sistema.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Si el valor antiguo vuelve tras un reinicio, la fuente es una política gestionada o un perfil que lo vuelve a aplicar, y el propietario de esa política tiene que retirar la excepción. Mantén la verificación de certificados activada todo el tiempo, porque un proxy que intercepta tráfico parecerá resuelto en cuanto desactives las comprobaciones. Termina escribiendo el valor retirado y la fecha en tus notas, para que la siguiente persona distinga un proxy intencionado de uno olvidado.