Charles ist geschlossen, aber dein Mac zeigt noch auf 127.0.0.1

Ein toter lokaler Proxy sieht genauso aus wie ein kaputtes VPN. Lies den Proxy-Zustand des aktiven Netzwerkdienstes, finde den Eigentümer der Einstellung und ändere nur diese.

Eine Anwendung scheitert, und das VPN bekommt die Schuld, doch die Anfrage erreicht den Tunnel nie. Wenn macOS dieser Anwendung weiterhin einen lokalen Proxy vorschreibt, ist der erste Sprung 127.0.0.1, und dort hört nichts zu. Charles zu schließen räumt nicht immer die Systemproxy-Einstellung auf, die es installiert hat, also steht ein gesundes VPN hinter einem toten Socket. Hier ist die Reihenfolge, um das zu bestätigen und nur das fehlerhafte Teil zu reparieren.

Der erste Sprung ist dieser Mac, nicht der Server

Lies die Adresse wörtlich: 127.0.0.1 ist der Rechner vor dir, und der Port ist der, auf dem das Proxy-Werkzeug lauschen sollte. Wenn dieser Listener weg ist, scheitert die Verbindung sofort mit einer abgelehnten Verbindung statt mit einem Timeout, und das ist der nützliche Hinweis.

Ein VPN erstellt keine eigenen Proxy-Einstellungen und entfernt auch nicht die des Systems. Die beiden Konfigurationen sind unabhängig, deshalb kann der Tunnel perfekt sein und der Browser trotzdem unbrauchbar. Diese Unabhängigkeit erklärt auch, warum der Fehler ein Neuverbinden des VPN, einen Neustart und ein frisches Profil übersteht. Nichts auf dem VPN-Pfad berührt jemals den Proxy-Speicher.

Schritt 1: den aktuellen Proxy-Zustand lesen

Beginne mit der Nur-Lese-Ansicht, denn sie zeigt, was das System glaubt, bevor irgendeine Anwendung es interpretiert:

scutil --proxy

Sieh dir HTTPEnable, HTTPProxy, HTTPPort, die HTTPS-Entsprechungen und jedes ProxyAutoConfigEnable mit seiner URL an. Ein aktivierter Proxy mit einem Port, auf dem nichts lauscht, ist dein Fehler. Eine PAC-URL ist die andere Form: Die Einstellung kann aktiv sein, ohne sichtbare manuelle Adresse, weil die Datei den Proxy erst zur Anfragezeit wählt.

Bestätige dann dieselben Werte in den Systemeinstellungen, Netzwerk, dem Dienst, den du tatsächlich nutzt, Details, Proxies. GUI und Befehl lesen denselben Speicher, eine Abweichung bedeutet also, dass du einen anderen Dienst ansiehst.

Schritt 2: herausfinden, wem die Einstellung gehört

Drei Eigentümer erzeugen diesen Zustand: ein Proxy-Werkzeug, das einen Helfer installiert und nicht aufgeräumt hat, ein verwaltetes Konfigurationsprofil deiner Organisation und eine manuelle Einstellung, die jemand beim Debuggen hinzugefügt hat. Jeder hat eine andere richtige Lösung, und nur die erste darfst du unbekümmert entfernen.

Charles dokumentiert seine Browser- und Systemproxy-Integration einschließlich des macOS-Helfers, nutze also zuerst dessen eigene Steuerung und seinen Abschaltpfad. Der privilegierte Helfer existiert, um Konfiguration zu ändern; das ist kein Grund, fremder Software weitreichenden Zugriff auf den Rechner zu geben.

Stammt die Einstellung aus einem verwalteten Profil, scheitert das lokale Abschalten entweder oder wird beim nächsten Check-in wiederhergestellt. Behandle das als Richtlinienfrage für den Eigentümer des Profils, nicht als lokalen Fehler.

Schritt 3: das Engste ändern

Deaktiviere den konkreten ungewollten Eintrag für den konkreten Dienst. Schalte nicht jeden Dienst um und leere nicht das ganze Proxy-Fenster, denn der VPN-Dienst und der darunterliegende WLAN-Dienst halten getrennte Einstellungen, und eine davon kann richtig sein.

Wird der Proxy absichtlich verlangt, starte seinen freigegebenen Listener, statt die Richtlinie zu löschen. Dieser Unterschied zählt in Organisationen, in denen der Proxy der einzige Weg ins Internet ist und das VPN ein zweiter, engerer Pfad.

Wiederhole eine frische Anfrage aus der betroffenen Anwendung. Manche Anwendungen lesen den Proxy beim Start einmal, deshalb ist Beenden und neu Öffnen Teil des Tests und kein Aberglaube.

Schritt 4: wenn der Proxy weg ist und es weiter scheitert

Dann hast du ein anderes Problem, und der neue Fehler ist der nützliche Beweis. Namensauflösung, VPN-Routing, TLS-Vertrauen und Anwendungsautorisierung sind vier getrennte Prüfungen, und jede erzeugt einen unterscheidbaren Fehler.

Halte Zertifikatsvertrauen aus dieser Reparatur heraus. Eine vertrauenswürdige Wurzel zu entfernen oder die Serverprüfung abzuschwächen repariert keinen toten Proxy-Socket und hinterlässt dir zwei Änderungen und einen ursprünglichen Fehler. Inspiziert ein Firmenproxy TLS, ist das ein bewusstes Design mit eigener Vertrauensanforderung, kein rückgängig zu machender Nebeneffekt. Frag das Team, dem der Proxy gehört, bevor du ein Zertifikat anfasst, denn seine Antwort betrifft Richtlinien und deine eine fehlgeschlagene Anfrage.

Schreib den Rückweg auf, bevor du beginnst: notiere die genauen Proxy-Werte, die du gefunden hast, damit Wiederherstellen ein Kopieren ist und keine Gedächtnisübung. Die Dokumentation zur Charles-Proxy-Konfiguration beschreibt die Integration und ihr Abschaltverhalten für die Version, die du betreibst.

Wenn das nächste Mal eine App über ein VPN scheitert, prüfe den ersten Sprung vor dem Tunnel. Es kostet einen Befehl und schließt eine ganze Kategorie von Fehldiagnosen aus.

Ähnliche Artikel