Charles è chiuso, ma il tuo Mac punta ancora a 127.0.0.1

Un’applicazione fallisce e la colpa ricade sul VPN, ma la richiesta non raggiunge mai il tunnel. Se macOS dice ancora a quell’applicazione di usare un proxy locale, il primo salto è 127.0.0.1 e non c’è nulla in ascolto. Chiudere Charles non sempre cancella l’impostazione proxy di sistema che ha installato, quindi un VPN sano resta dietro un socket morto. Ecco l’ordine per confermarlo e riparare solo il pezzo sbagliato.

Il primo salto è questo Mac, non il server

Leggi l’indirizzo alla lettera: 127.0.0.1 è la macchina davanti a te, e la porta è quella su cui lo strumento proxy era configurato per ascoltare. Quando quell’ascoltatore sparisce, la connessione fallisce subito con una connessione rifiutata invece che con un timeout, e questo è l’indizio utile.

Un VPN non crea impostazioni proxy proprie e non rimuove quelle di sistema. Le due configurazioni sono indipendenti, perciò il tunnel può essere perfetto e il browser comunque inutilizzabile. Questa indipendenza spiega anche perché il guasto sopravvive a una riconnessione del VPN, a un riavvio e a un profilo nuovo. Nulla nel percorso del VPN tocca mai l’archivio dei proxy.

Passo 1: leggi lo stato attuale del proxy

Parti dalla vista in sola lettura, perché dice ciò che il sistema crede prima che qualsiasi applicazione lo interpreti:

scutil --proxy

Guarda HTTPEnable, HTTPProxy, HTTPPort, gli equivalenti HTTPS e qualsiasi ProxyAutoConfigEnable con il suo URL. Un proxy attivo su una porta dove nulla è in ascolto è il tuo guasto. Un URL PAC è l’altra forma: l’impostazione può essere attiva senza un indirizzo manuale visibile, perché il file sceglie il proxy al momento della richiesta.

Poi conferma gli stessi valori in Impostazioni di Sistema, Rete, il servizio che stai davvero usando, Dettagli, Proxy. L’interfaccia grafica e il comando leggono lo stesso archivio, quindi un disaccordo significa che stai guardando un altro servizio.

Passo 2: scopri chi possiede l’impostazione

Tre proprietari producono questo stato: uno strumento proxy che ha installato un helper e non l’ha ripulito, un profilo di configurazione gestito della tua organizzazione e un’impostazione manuale aggiunta da qualcuno durante il debug. Ognuno ha una correzione corretta diversa, e solo la prima puoi rimuoverla senza pensarci.

Charles documenta la sua integrazione con il browser e il proxy di sistema, incluso l’helper macOS, quindi usa prima i suoi controlli e il suo percorso di chiusura. L’helper privilegiato esiste per cambiare la configurazione; non è una ragione per dare a software estraneo un accesso ampio alla macchina.

Se l’impostazione arriva da un profilo gestito, disattivarla localmente o fallisce o viene ripristinata al controllo successivo. Trattalo come una questione di politica per chi possiede il profilo, non come un bug locale.

Passo 3: cambia la cosa più stretta

Disattiva la voce involontaria specifica per il servizio specifico. Non commutare ogni servizio e non svuotare tutto il pannello proxy, perché il servizio VPN e il servizio Wi-Fi sottostante tengono impostazioni separate e una di esse può essere corretta.

Se il proxy è richiesto di proposito, avvia il suo ascoltatore approvato invece di cancellare la politica. Questa distinzione conta nelle organizzazioni dove il proxy è l’unica via verso internet e il VPN è un secondo percorso, più stretto.

Riprova una richiesta nuova dall’applicazione colpita. Alcune applicazioni leggono il proxy una volta all’avvio, quindi chiuderla e riaprirla fa parte del test e non è superstizione.

Passo 4: se il proxy è sparito e fallisce ancora

Allora hai un altro problema, e il nuovo errore è la prova utile. Risoluzione dei nomi, l’instradamento del VPN, la fiducia TLS e l’autorizzazione delle applicazioni sono quattro controlli separati, e ognuno produce un guasto distinguibile.

Tieni la fiducia nei certificati fuori da questa riparazione. Rimuovere una radice attendibile o indebolire la validazione del server non ripara un socket proxy morto e ti lascia con due modifiche e un guasto originale. Se un proxy aziendale ispeziona TLS, è un progetto deliberato con il suo requisito di fiducia, non un effetto collaterale da annullare. Chiedi al team che possiede il proxy prima di toccare un certificato, perché la loro risposta riguarda la politica e la tua una richiesta fallita.

Scrivi il ritorno prima di iniziare: annota i valori proxy esatti che hai trovato, così il ripristino è una copia e non un esercizio di memoria. La documentazione di configurazione del proxy Charles descrive l’integrazione e il suo comportamento alla chiusura per la versione che usi.

La prossima volta che un’applicazione fallisce su un VPN, controlla il primo salto prima del tunnel. Costa un comando e scarta un’intera categoria di diagnosi sbagliata.