Il VPN funziona, ma un’app non ha internet? Controlla il suo proxy

Il tuo tunnel è attivo, la pagina di stato mostra un handshake sano, ma un’applicazione continua a non caricare nulla. Quell’applicazione probabilmente sta ancora inviando le sue richieste a un intermediario più vecchio: un proxy di sistema, un’estensione, un file di configurazione spinto dalla gestione dei dispositivi o una variabile proxy che legge solo il suo processo. Cambiare server VPN non toccherà quell’impostazione, ed è per questo che il pattern in cui altre applicazioni funzionano dallo stesso computer ha senso. Lavora dall’app che fallisce verso l’esterno e lascia in pace il tunnel finché la questione del proxy non è risolta.

Quale livello possiede l’impostazione del proxy

Quattro luoghi possono rivendicare autorità sulle richieste di un’app, e di solito vince il più stretto. Il sistema operativo tiene un proxy globale e un URL di configurazione automatica opzionale; un browser può seguirlo, sovrascriverlo o cedere il controllo a un’estensione; uno strumento da riga di comando legge il proprio ambiente; e un criterio gestito può riappuntare chiunque di questi dopo una modifica. Decidi quale livello comanda prima di modificare qualcosa, perché cancellare quello sbagliato sembra una correzione riuscita che torna al login successivo.

Confronta due applicazioni sullo stesso sito normale invece che su una pagina di prova solo per VPN. Se il browser fallisce mentre un download nel terminale riesce, il sistema operativo non è il problema, e la differenza sta nel profilo del browser o nelle sue estensioni. Se entrambi falliscono ma un secondo account utente sullo stesso computer riesce, l’impostazione è per utente. Quel confronto costa un minuto e toglie gran parte delle supposizioni.

Leggi il valore che ogni strumento usa davvero

Stampa la configurazione prima di cambiarla e copia la stringa proxy esatta in un posto da cui puoi ripristinarla. Le variabili della shell sono il controllo più rapido per gli strumenti da riga di comando, perché un client VPN di solito le lascia intatte.

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

Esegui solo la riga che corrisponde alla piattaforma davanti a te, poi leggi l’output per host, porta e credenziali. Un valore come http://proxy.corp.example:8080 significa che lo strumento interroga quell’host per ogni richiesta, mentre un risultato vuoto significa che va diretto e che il guasto vero è altrove. Oscura la parte utente e password prima di incollare l’output in un ticket, perché quelle stringhe sono credenziali attive molto più spesso di quanto si pensi.

Gli strumenti con un proprio motore proxy hanno bisogno di prove proprie. Curl dichiara la decisione presa quando alzi la verbosità, il che è meglio che indovinare dall’ambiente, e lo stesso flag mostra se la risoluzione dei nomi è avvenuta localmente o al proxy.

Cancella l’override e ritesta la stessa richiesta

Cambia un livello, poi ripeti esattamente la richiesta che è fallita, perché un altro URL non dimostra nulla. Cancella prima le variabili d’ambiente nella shell attuale, dato che quella modifica è reversibile e non può rompere il tunnel:

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 l’output dettagliato dichiara ancora un proxy, l’ambiente non era l’autorità. Sali di un livello invece di impilare altri override.

Su macOS, verifica che un file di configurazione automatica non fornisca il valore, poi disattiva il proxy del servizio e conferma la modifica. Su Windows, ricorda che l’impostazione WinHTTP e quella del browser per utente sono oggetti diversi, quindi uno strumento da riga di comando pulito può convivere con un browser che punta ancora a un vecchio server. Le estensioni meritano lo stesso sospetto: un’estensione proxy può riscrivere richieste solo per un profilo, ed è esattamente la forma di un guasto che colpisce un browser e nient’altro.

Verifica che la correzione sopravviva a un riavvio

Un’impostazione che funziona solo nel terminale che hai modificato non è corretta. Riapri l’applicazione dal launcher del desktop, esci e rientra, e guarda se il vecchio proxy torna.

Due controlli separano una correzione reale da una temporanea, e entrambi dovrebbero riportare una connessione diretta o il valore previsto. L’esecuzione in ambiente pulito mostra se un processo ripulito prende ancora un’impostazione di sistema.

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

Se il vecchio valore torna dopo un riavvio, la fonte è un criterio gestito o un profilo che lo riapplica, e il proprietario di quel criterio deve rimuovere l’eccezione. Lascia attiva la verifica dei certificati per tutto il tempo, perché un proxy che intercetta traffico sembrerà risolto appena disattivi i controlli. Chiudi scrivendo il valore rimosso e la data nelle tue note, così la persona successiva può distinguere un proxy intenzionale da uno dimenticato.