Bei einer fehlgeschlagenen Proxy-Verbindung in drei Ebenen prüfen: zuerst IP-Wechsel und Standort des Exits, dann DNS-, Timeout- und Zertifikatsfehler unterscheiden und zuletzt Authentifizierung, Port und Protokoll abgleichen.
Der Proxy ist eingerichtet, Benutzername und Passwort stimmen, doch die Verbindungsprüfung meldet weiterhin einen Fehler. Viele wenden sich dann sofort an den Proxy-Anbieter, wechseln den Knoten, ändern den Port oder drängen den Support. Das ist oft wenig effizient, denn die Ursache kann an jeder Stelle der gesamten Verbindungskette liegen; der Proxy ist nur ein Glied davon.
Statt wahllos Dinge auszuprobieren, hilft eine feste Reihenfolge von außen nach innen: zuerst prüfen, ob der Exit wirklich aktiv ist, dann kontrollieren, ob der Netzwerkpfad funktioniert, und erst danach Authentifizierung und Protokoll auf Anwendungsebene untersuchen. Mit diesen drei Ebenen lassen sich die meisten Probleme eingrenzen.
Ist der Exit wirklich aktiv?
Dieser Schritt wird leicht übersprungen, weil die Konfiguration erfolgreich aussieht. Eine erfolgreiche Konfiguration und tatsächlich über den Proxy laufender Datenverkehr sind jedoch zwei verschiedene Dinge.
Prüfen Sie zwei Punkte. Erstens: Hat sich die IP geändert? Notieren Sie die öffentliche IP ohne Proxy, aktivieren Sie den Proxy und prüfen Sie erneut. Sind beide gleich, läuft der Verkehr gar nicht über den Proxy; weitere Prüfungen wären dann vergeblich. Zweitens: Stimmt der Standort? Proxy-Details enthalten meist Land, Region, Bundesland oder Provinz, Stadt, Koordinaten mit sechs Nachkommastellen und Postleitzahl. Vergleichen Sie diese Angaben mit der beim Kauf gewählten Region. Auch eine Systemzeitzone, die klar nicht zur Exit-Region passt, ist ein Warnsignal.
Wenn der Exit nicht greift, liegt die Ursache häufig an verbliebenen lokalen Einstellungen statt beim Anbieter. Wurde ein früher verwendetes Netzwerktool beim Beenden nicht sauber zurückgesetzt, können auf Systemebene Variablen wie HTTP_PROXY oder HTTPS_PROXY bestehen bleiben; unter macOS können auch Web-Proxy- oder SOCKS-Proxy-Schalter noch aktiv sein. Dann glaubt der Client, den Systemproxy zu verwenden, während Anfragen ihn tatsächlich umgehen. Solche Reste zu entfernen und erneut zu testen ist oft hilfreicher, als den Proxy komplett neu einzurichten.
Drei häufige Fehler im Netzwerkpfad
Wenn der Exit bestätigt ist, prüfen Sie als Nächstes, ob die Anfrage das Ziel tatsächlich erreicht.
Die DNS-Auflösung ist der erste mögliche Engpass. Typische Anzeichen sind ein Auflösungsfehler oder ein offensichtlich falsches Ergebnis, bei dem eine Domain, die auf den Zielservice zeigen sollte, bei einer unerwarteten Adresse landet. Versuchen Sie die Auflösung mit einem öffentlichen DNS-Server erneut oder leeren Sie den lokalen DNS-Cache und prüfen Sie, ob sich das Problem erledigt.
Die zweite Fehlerart ist ein Verbindungstimeout. Blockiert eine Firewall oder Sicherheitssoftware den Port, dreht die Anfrage oft nur weiter und läuft schließlich in ein Timeout. Prüfen Sie die Freigaberegeln für den Port und ob die Umgebung selbst, etwa ein Firmennetz oder öffentliches WLAN, Einschränkungen hat. Ein schneller Test: Stellen Sie die Verbindung ohne Proxy direkt her. Öffnet sich dann ebenfalls keine Website, liegt das Problem am Basisnetzwerk und nicht am Proxy. Ein Neustart des Routers oder ein Wechsel auf einen mobilen Hotspot kann das bestätigen.
Zertifikatsfehler sollten gesondert betrachtet werden. Bei Meldungen wie „Zertifikat nicht vertrauenswürdig“ oder „Handshake fehlgeschlagen“ wird oft zuerst an entschlüsselten Datenverkehr oder ein ausgetauschtes Zertifikat gedacht. Das ist möglich, doch es gibt eine weniger offensichtliche Ursache: eine falsche lokale Uhrzeit. Viele Authentifizierungs- und Sitzungsmechanismen hängen von Zeitstempeln ab. Weicht die lokale Zeit mehr als 5 Minuten von der Serverzeit ab, kann die Signaturprüfung scheitern und die Verbindung abgewiesen werden; bei HTTPS zeigt sich das als fehlgeschlagene Zertifikatsprüfung. Prüfen Sie bei Zertifikatsfehlern daher auch die Systemzeitsynchronisierung. Ist sie fehlerhaft, automatische Synchronisierung aktivieren, sofort korrigieren, den Client neu starten und erneut testen.
Authentifizierung und Protokoll nicht verwechseln
Wenn der Proxy-Server erreichbar ist, der Datenverkehr aber trotzdem nicht funktioniert, liegt das Problem meist auf der Anwendungsebene.
Am häufigsten sind falsche Authentifizierungsdaten. Benutzername, Passwort und Authentifizierungsmethode müssen den Angaben des Anbieters entsprechen; auch ein geändertes Passwort, das nicht in der Konfiguration aktualisiert wurde, kommt häufig vor. Bei manueller Konfiguration muss außerdem der eingetragene Port mit dem Port übereinstimmen, auf dem das Proxy-Tool selbst lauscht. Die Zahlen können ähnlich aussehen, doch ein falscher Port verhindert die Verbindung vollständig.
Die zweite Kategorie ist ein Protokollfehler. HTTP, HTTPS und SOCKS5 sind nicht austauschbar: Liefert der Anbieter SOCKS5, während in der Konfiguration HTTP steht, schlägt die Prüfung zwangsläufig fehl. Prüfen Sie außerdem, ob der Proxy den Zugriff auf die Zielseite und den Zielport erlaubt, denn manche Proxys beschränken Ziele oder Protokolle.
Am schnellsten lässt sich ein Knotenproblem von einem Konfigurationsproblem unterscheiden, indem Sie einen anderen Knoten testen. Funktioniert der neue Knoten, liegt es am ursprünglichen Knoten. Scheitert es weiterhin, gehen Sie zurück zu Konfiguration und Netzwerkpfad. Ändern Sie nicht mehrere Parameter gleichzeitig, sondern immer nur eine Variable und notieren Sie das Ergebnis; sonst können die eigenen Änderungen die eigentliche Ursache verdecken.
Verbunden heißt nicht automatisch nutzbar
Eine weitere häufige Falle: Der Proxy zeigt eine normale Verbindung, doch das Konto löst weiterhin häufig Risikokontrollen aus. Dann geht es oft nicht darum, ob eine Verbindung möglich ist, sondern ob der Exit wie eine normale Benutzerumgebung wirkt.
Prüfen Sie weiterhin die grundlegenden Punkte: Passt der Exit-Standort zur Registrierungsregion des Kontos? Ist der IP-Typ angemessen, da Plattformen Rechenzentrums- und Residential-IP-Adressen unterschiedlich bewerten können? Wurde diese IP vom Zielservice bereits markiert? Wenn über dieselbe IP zuvor viel auffälliger Datenverkehr lief, kann das spätere Nutzer beeinträchtigen. Nach einem erfolgreichen Verbindungstest lohnt es sich daher, auch die Sauberkeit des Exits kurz zu prüfen.
Werden auf einem Gerät mehrere Umgebungen betrieben, sollten Exits möglichst eins zu eins zugeordnet werden: jede Umgebung erhält ihren eigenen Exit. Probleme lassen sich so einzeln eingrenzen, und wird ein Exit markiert, betrifft das nur die zugehörige Umgebung statt alle zugleich. PurpleMark konfiguriert und isoliert Exits in der Verwaltung mehrerer Umgebungen genau nach diesem Prinzip.
Diese Hinweise zur Fehlersuche dienen nur dem technischen Austausch. Verwenden Sie entsprechende Tools und Dienste ausschließlich im Rahmen der geltenden Gesetze und Vorschriften.
