Charles is gesloten, maar je Mac wijst nog steeds naar 127.0.0.1

Een applicatie faalt en de VPN krijgt de schuld, maar het verzoek bereikt de tunnel nooit. Als macOS die applicatie nog steeds een lokale proxy laat gebruiken, is de eerste hop 127.0.0.1 en luistert daar niets. Charles sluiten wist niet altijd de systeemproxy-instelling die het installeerde, dus een gezonde VPN zit achter een dode socket. Hier is de volgorde om dat te bevestigen en alleen het onderdeel te repareren dat fout is.

De eerste hop is deze Mac, niet de server

Lees het adres letterlijk: 127.0.0.1 is de machine voor je, en de poort is degene waarop de proxytool geconfigureerd was te luisteren. Als die listener weg is, mislukt de verbinding onmiddellijk met een geweigerde verbinding in plaats van een time-out, en dat is de nuttige aanwijzing.

Een VPN maakt geen eigen proxyinstellingen en verwijdert de systeeminstellingen niet. De twee configuraties zijn onafhankelijk, waardoor de tunnel perfect kan zijn en de browser toch onbruikbaar. Die onafhankelijkheid is ook waarom de fout een VPN-herverbinding, een herstart en een nieuw profiel overleeft. Niets in het VPN-pad raakt ooit de proxyopslag aan.

Stap 1: lees de huidige proxystatus

Begin met de alleen-lezen weergave, want die vertelt wat het systeem gelooft voordat een applicatie het interpreteert:

scutil --proxy

Kijk naar HTTPEnable, HTTPProxy, HTTPPort, de HTTPS-equivalenten en elke ProxyAutoConfigEnable met zijn URL. Een ingeschakelde proxy met een poort waar niets op luistert is jouw fout. Een PAC-URL is de andere vorm: de instelling kan actief zijn zonder zichtbaar handmatig adres, omdat het bestand de proxy op het moment van het verzoek kiest.

Bevestig daarna dezelfde waarden in Systeeminstellingen, Netwerk, de dienst die je werkelijk gebruikt, Details, Proxy's. De GUI en het commando lezen dezelfde opslag, dus een verschil betekent dat je naar een andere dienst kijkt.

Stap 2: zoek uit wie de instelling bezit

Drie eigenaren veroorzaken deze toestand: een proxytool die een helper installeerde en niet opruimde, een beheerd configuratieprofiel van je organisatie, en een handmatige instelling die iemand tijdens het debuggen toevoegde. Elk heeft een andere juiste oplossing, en alleen de eerste kun je zelf achteloos verwijderen.

Charles documenteert de integratie met browser en systeemproxy, inclusief de macOS-helper, dus gebruik eerst de eigen bediening en het afsluitpad. De geprivilegieerde helper bestaat om configuratie te wijzigen; dat is geen reden om niet-gerelateerde software brede toegang tot de machine te geven.

Als de instelling van een beheerd profiel kwam, mislukt lokaal uitschakelen of wordt het bij de volgende check-in hersteld. Behandel dat als een beleidsvraag voor de eigenaar van het profiel, niet als een lokale bug.

Stap 3: wijzig het smalste ding

Schakel de specifieke ongewenste vermelding voor de specifieke dienst uit. Schakel niet elke dienst om en maak het hele proxyvenster niet leeg, want de VPN-dienst en de onderliggende Wi-Fi-dienst houden aparte instellingen en een ervan kan correct zijn.

Als de proxy bewust vereist is, start dan de goedgekeurde listener in plaats van het beleid te verwijderen. Dat onderscheid is belangrijk in organisaties waar de proxy de enige route naar internet is en de VPN een tweede, smallere route.

Probeer één nieuw verzoek vanuit de getroffen applicatie. Sommige applicaties lezen de proxy één keer bij het starten, dus afsluiten en heropenen is deel van de test en geen bijgeloof.

Stap 4: als de proxy weg is en het nog steeds mislukt

Dan heb je een ander probleem, en de nieuwe fout is het nuttige bewijs. Naamresolutie, VPN-routing, TLS-vertrouwen en applicatieautorisatie zijn vier afzonderlijke controles, en elk levert een onderscheidbare fout op.

Houd certificaatvertrouwen buiten deze reparatie. Een vertrouwde root verwijderen of servervalidatie verzwakken repareert geen dode proxysocket, en het laat je achter met twee wijzigingen en één oorspronkelijke fout. Als een bedrijfsproxy TLS inspecteert, is dat een bewust ontwerp met zijn eigen vertrouwenseis, geen bijwerking om ongedaan te maken. Vraag het team dat de proxy bezit voordat je een certificaat aanraakt, want hun antwoord gaat over beleid en het jouwe over één mislukt verzoek.

Schrijf de terugdraaiing voordat je begint: noteer de exacte proxywaarden die je vond, zodat herstellen een kopie is en geen geheugenoefening. De Charles-documentatie over proxyconfiguratie beschrijft de integratie en het afsluitgedrag voor de versie die je draait.

De volgende keer dat een app op een VPN faalt, controleer de eerste hop vóór de tunnel. Het kost één commando en sluit een hele categorie verkeerde diagnose uit.