O VPN funciona, pero unha app non ten internet? Revisa o seu proxy

O teu túnel está activo, a páxina de estado mostra un handshake correcto, pero unha aplicación segue sen cargar nada. Esa aplicación probabelmente aínda envía as súas peticións a un intermediario máis antigo: un proxy do sistema, unha extensión, un ficheiro de configuración empurrado pola xestión de dispositivos ou unha variable de proxy que só le o seu propio proceso. Cambiar de servidor VPN non tocará ese axuste, e iso explica o patrón no que outras aplicacións funcionan desde o mesmo equipo. Traballa desde a aplicación que falla cara a fóra e deixa o túnel tranquilo ata que a cuestión do proxy estea resolta.

Que capa posúe o axuste do proxy

Catro lugares poden reclamar autoridade sobre as peticións dunha app, e o máis estreito adoita gañar. O sistema operativo ten un proxy global e un URL de configuración automática opcional; un navegador pode seguilo, anulalo ou ceder o control a unha extensión; unha ferramenta de liña de ordes le o seu propio contorno; e unha política xestionada pode fixar de novo calquera das anteriores tras un cambio. Decide que capa manda antes de editar nada, porque borrar a capa equivocada parece unha corrección exitosa que volve no seguinte inicio de sesión.

Compara dúas aplicacións contra o mesmo sitio web normal en lugar de contra unha páxina de proba só para VPN. Se o navegador falla mentres unha descarga no terminal funciona, o sistema operativo non é o problema, e a diferenza está no perfil do navegador ou nas súas extensións. Se ambas fallan pero unha segunda conta de usuario no mesmo equipo funciona, o axuste é por usuario. Esa comparación custa un minuto e elimina a maior parte das conxecturas.

Le o valor que cada ferramenta usa realmente

Imprime a configuración antes de cambiala e copia a cadea de proxy exacta nun lugar desde o que poidas restaurala. As variables da shell son a comprobación máis rápida para ferramentas de liña de ordes, porque un cliente VPN normalmente déixaas 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

Executa só a liña que corresponde á plataforma que tes diante e logo le a saída para o host, o porto e as credenciais. Un valor como http://proxy.corp.example:8080 significa que a ferramenta pregunta a ese host por cada petición, mentres que un resultado baleiro significa que vai directa e que a falla real está noutro sitio. Tapa a parte de usuario e contrasinal antes de pegar a saída nun tícket, porque esas cadeas son credenciais vivas moito máis a miúdo do que a xente supón.

As ferramentas co seu propio motor de proxy necesitan as súas propias probas. Curl indica a decisión que tomou cando sobes a verbosidade, o que vale máis que adiviñar a partir da contorna, e o mesmo indicador mostra se a resolución de nomes ocorreu localmente ou no proxy.

Borra a anulación e volve probar a mesma petición

Cambia unha capa e logo repite exactamente a petición que fallou, porque outro URL non demostra nada. Borra primeiro as variables de contorno na shell actual, xa que ese cambio é reversible e non pode romper o 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/'

Se a saída detallada segue afirmando que hai un proxy, a contorna non era a autoridade. Sobe un nivel en lugar de apilar máis anulacións.

En macOS, comproba que un ficheiro de configuración automática non estea a fornecer o valor, logo desactiva o proxy do servizo e confirma o cambio. En Windows, lembra que o axuste WinHTTP e o axuste do navegador por usuario son obxectos distintos, así que unha ferramenta de liña de ordes limpa pode convivir cun navegador que aínda apunta a un servidor antigo. As extensións merecen a mesma sospeita: unha extensión de proxy pode reescribir peticións só para un perfil, e esa é exactamente a forma dunha falla que afecta un navegador e nada máis.

Comproba que a corrección sobrevive a un reinicio

Un axuste que só funciona no terminal que editaches non está corrixido. Volve abrir a aplicación desde o lanzador do escritorio, pecha a sesión e volve entrar, e observa se o proxy antigo regresa.

Dúas comprobacións separan unha corrección real dunha temporal, e ambas deberían informar dunha conexión directa ou do valor previsto. A execución nunha contorna limpa mostra se un proceso depurado segue tomando un axuste do sistema.

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

Se o valor antigo volve tras un reinicio, a fonte é unha política xestionada ou un perfil que o volve aplicar, e o propietario desa política ten que retirar a excepción. Mantén a verificación de certificados activada todo o tempo, porque un proxy que intercepta tráfico parecerá resolto en canto desactives as comprobacións. Remata escribindo o valor retirado e a data nas túas notas, para que a seguinte persoa distinga un proxy intencionado dun esquecido.