El VPN funciona, però una app no té internet? Revisa el seu proxy

El teu túnel està muntat, la pàgina d’estat mostra un handshake saludable, i una aplicació encara no carrega res. Aquesta aplicació probablement encara envia les peticions a un intermediari més antic: un proxy del sistema, una extensió, un fitxer de configuració empès per la gestió de dispositius o una variable de proxy que només llegeix el seu propi procés. Canviar de servidor VPN no tocarà aquesta configuració, i això explica el patró en què altres aplicacions funcionen des del mateix equip. Treballa des de l’aplicació que falla cap enfora i deixa el túnel tranquil fins que la qüestió del proxy estigui resolta.

Quina capa posseeix la configuració del proxy

Quatre llocs poden reclamar autoritat sobre les peticions d’una aplicació, i el més estret sol guanyar. El sistema operatiu té un proxy global i una URL de configuració automàtica opcional; un navegador pot seguir-la, substituir-la o cedir el control a una extensió; una eina de línia d’ordres llegeix el seu propi entorn; i una política gestionada pot fixar de nou qualsevol de les anteriors després d’un canvi. Decideix quina capa mana abans d’editar res, perquè esborrar la capa equivocada sembla una correcció reeixida que torna en el següent inici de sessió.

Compara dues aplicacions contra el mateix lloc web corrent en lloc d’una pàgina de prova només per a VPN. Si el navegador falla mentre una descàrrega al terminal funciona, el sistema operatiu no és el problema, i la diferència és dins del perfil del navegador o de les seves extensions. Si tots dos fallen però un segon compte d’usuari al mateix equip funciona, la configuració és per usuari. Aquesta comparació costa un minut i elimina la major part de les conjectures.

Llegeix el valor que cada eina fa servir realment

Imprimeix la configuració abans de canviar-la i copia la cadena de proxy exacta en un lloc des d’on la puguis restaurar. Les variables de l’intèrpret d’ordres són la comprovació més ràpida per a eines de línia d’ordres, perquè un client VPN normalment les deixa intactes.

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 només la línia que coincideix amb la plataforma que tens davant, i després llegeix la sortida per a l’amfitrió, el port i les credencials. Un valor com http://proxy.corp.example:8080 significa que l’eina demana aquest amfitrió per a cada petició, mentre que un resultat buit significa que va directa i que la fallada real és en un altre lloc. Tapa la part d’usuari i contrasenya abans d’enganxar la sortida en un tiquet, perquè aquestes cadenes són credencials vives molt més sovint del que la gent suposa.

Les eines amb el seu propi motor de proxy necessiten les seves pròpies proves. Curl indica la decisió que ha pres quan apuges la verbositat, cosa que val més que endevinar a partir de l’entorn, i el mateix senyalador mostra si la resolució de noms s’ha fet localment o al proxy.

Esborra la substitució i torna a provar la mateixa petició

Canvia una capa i després repeteix exactament la petició que va fallar, perquè una altra URL no demostra res. Esborra primer les variables d’entorn a l’intèrpret d’ordres actual, ja que aquest canvi és reversible i no pot trencar 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 sortida detallada encara afirma que hi ha un proxy, l’entorn no era l’autoritat. Puja un nivell en lloc d’apilar més substitucions.

A macOS, comprova que un fitxer de configuració automàtica no proporcioni el valor, i després desactiva el proxy del servei i confirma el canvi. A Windows, recorda que la configuració WinHTTP i la configuració del navegador per usuari són objectes diferents, de manera que una eina de línia d’ordres neta pot coexistir amb un navegador que encara apunta a un servidor antic. Les extensions mereixen la mateixa sospita: una extensió de proxy pot reescriure peticions només per a un perfil, i aquesta és exactament la forma d’una fallada que afecta un navegador i res més.

Comprova que la correcció sobreviu a un reinici

Una configuració que només funciona al terminal que has editat no està corregida. Torna a obrir l’aplicació des del llançador de l’escriptori, tanca la sessió i torna-la a obrir, i mira si el proxy antic torna.

Dues comprovacions separen una correcció real d’una de temporal, i totes dues haurien d’informar d’una connexió directa o del valor previst. L’execució en entorn net mostra si un procés depurat encara recull una configuració 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 antic torna després d’un reinici, la font és una política gestionada o un perfil que la torna a aplicar, i el propietari d’aquesta política ha de retirar l’excepció. Mantén la verificació de certificats activada tot el temps, perquè un proxy que intercepta trànsit semblarà resolt en desactivar les comprovacions. Acaba escrivint el valor retirat i la data a les teves notes, perquè la persona següent pugui distingir un proxy intencionat d’un d’oblidat.