VPN läuft, aber eine App hat kein Internet? Prüfe ihren Proxy

Dein Tunnel steht, die Statusseite zeigt einen sauberen Handshake, und eine Anwendung lädt trotzdem nichts. Diese Anwendung schickt ihre Anfragen wahrscheinlich noch an eine ältere Zwischenstelle: einen System-Proxy, eine Erweiterung, eine von der Geräteverwaltung verteilte Konfigurationsdatei oder eine Proxy-Variable, die nur ihr eigener Prozess liest. Ein anderer VPN-Server ändert an dieser Einstellung nichts, und das erklärt das Muster, bei dem andere Apps auf derselben Maschine funktionieren. Arbeite dich von der fehlerhaften App nach außen vor und lass den Tunnel in Ruhe, bis die Proxy-Frage geklärt ist.

Welche Ebene besitzt die Proxy-Einstellung

Vier Stellen können die Hoheit über die Anfragen einer App beanspruchen, und die engste gewinnt meist. Das Betriebssystem hält einen globalen Proxy und eine optionale automatische Konfigurations-URL; ein Browser kann dieser folgen, sie überschreiben oder die Kontrolle an eine Erweiterung abgeben; ein Kommandozeilenwerkzeug liest seine eigene Umgebung; und eine verwaltete Richtlinie kann alles davon nach einer Änderung wieder festnageln. Entscheide, welche Ebene zuständig ist, bevor du etwas bearbeitest, denn das Löschen der falschen Ebene sieht wie ein erfolgreicher Fix aus, der beim nächsten Login zurückkehrt.

Vergleiche zwei Anwendungen an derselben gewöhnlichen Website statt an einer reinen VPN-Testseite. Wenn der Browser scheitert, während ein Terminal-Download gelingt, ist das Betriebssystem nicht das Problem, und der Unterschied liegt im Browserprofil oder in seinen Erweiterungen. Wenn beide scheitern, aber ein zweites Benutzerkonto auf derselben Maschine Erfolg hat, ist die Einstellung benutzerbezogen. Dieser Vergleich kostet eine Minute und nimmt den meisten Rätselraten weg.

Lies den Wert, den jedes Werkzeug tatsächlich nutzt

Gib die Konfiguration aus, bevor du sie änderst, und kopiere die genaue Proxy-Zeichenkette an einen Ort, von dem du sie wiederherstellen kannst. Die Shell-Variablen sind die schnellste Prüfung für Kommandozeilenwerkzeuge, weil ein VPN-Client sie normalerweise unangetastet lässt.

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

Führe nur die Zeile aus, die zu der Plattform vor dir passt, und lies dann die Ausgabe auf Host, Port und Zugangsdaten. Ein Wert wie http://proxy.corp.example:8080 bedeutet, dass das Werkzeug für jede Anfrage diesen Host fragt, während ein leeres Ergebnis bedeutet, dass es direkt geht und der echte Fehler woanders liegt. Schwärze den Benutzer- und Passwortteil, bevor du die Ausgabe in ein Ticket einfügst, denn diese Zeichenketten sind weit öfter lebende Zugangsdaten, als man annimmt.

Werkzeuge mit eigener Proxy-Engine brauchen ihre eigenen Belege. Curl nennt die Entscheidung, die es getroffen hat, wenn du die Ausführlichkeit erhöhst, was besser ist als Raten aus der Umgebung, und dasselbe Flag zeigt, ob die Namensauflösung lokal oder am Proxy stattfand.

Lösche die Überschreibung und teste dieselbe Anfrage erneut

Ändere eine Ebene und wiederhole dann genau die Anfrage, die fehlgeschlagen ist, denn eine andere URL beweist nichts. Lösche zuerst die Umgebungsvariablen in der aktuellen Shell, weil diese Änderung umkehrbar ist und den Tunnel nicht brechen kann:

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/'

Wenn die ausführliche Ausgabe weiterhin einen Proxy behauptet, war die Umgebung nicht die Instanz. Gehe eine Ebene nach oben, statt weitere Überschreibungen zu stapeln.

Prüfe unter macOS, ob eine automatische Konfigurationsdatei den Wert liefert, und schalte dann den Dienst-Proxy aus und bestätige die Änderung. Denke unter Windows daran, dass die WinHTTP-Einstellung und die benutzerbezogene Browser-Einstellung verschiedene Objekte sind, sodass ein sauberes Kommandozeilenwerkzeug neben einem Browser existieren kann, der noch auf einen alten Server zeigt. Erweiterungen verdienen denselben Verdacht: Eine Proxy-Erweiterung kann Anfragen nur für ein Profil umschreiben, und genau das ist die Form eines Fehlers, der einen Browser und sonst nichts betrifft.

Stelle sicher, dass die Korrektur einen Neustart übersteht

Eine Einstellung, die nur in dem Terminal funktioniert, das du bearbeitet hast, ist nicht behoben. Öffne die Anwendung erneut über den Desktop-Starter, melde dich ab und wieder an, und beobachte, ob der alte Proxy zurückkommt.

Zwei Prüfungen trennen eine echte Korrektur von einer vorübergehenden, und beide sollten eine direkte Verbindung oder den beabsichtigten Wert melden. Der Lauf mit sauberer Umgebung zeigt, ob ein bereinigter Prozess noch eine Systemeinstellung aufgreift.

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

Wenn der alte Wert nach einem Neustart zurückkommt, ist die Quelle eine verwaltete Richtlinie oder ein Profil, das ihn erneut anwendet, und der Eigentümer dieser Richtlinie muss die Ausnahme entfernen. Lass die Zertifikatsprüfung durchgehend aktiviert, weil ein Proxy, der Datenverkehr abfängt, sonst gelöst aussieht, sobald du die Prüfungen deaktivierst. Schreibe zum Schluss den entfernten Wert und das Datum in deine Notizen, damit die nächste Person einen absichtlichen Proxy von einem vergessenen unterscheiden kann.