Zurück zum Blog

Proxy-Verbindung fehlgeschlagen: vom Proxy selbst bis zur Zielseite prüfen

Wenn eine Proxy-Verbindung fehlschlägt, prüfen Sie der Reihe nach den Proxy-Dienst, Authentifizierung und Protokoll, die Client-Konfiguration und zuletzt die Zielseite. So lässt sich die fehlerhafte Ebene erkennen, bevor Einstellungen geändert werden.

Nach dem Eintragen des Proxys meldet die Testschaltfläche einen Fehler. In diesem Moment ist zufälliges Ändern der Konfiguration das Schlechteste: Port, Protokoll oder Knoten wechseln und am Ende nicht wissen, welche Änderung geholfen hat.

Die Ursachen liegen meist auf vier Ebenen: beim Proxy-Dienst selbst, bei Authentifizierung und Protokoll, in der Client-Konfiguration oder auf der Zielseite. Prüfen Sie in genau dieser Reihenfolge, vom Proxy nach außen.

Zuerst den Proxy isoliert testen

Beginnen Sie nicht in einem Geschäftstool. Tragen Sie den Proxy direkt in einen normalen Browser mit manueller Proxy-Konfiguration oder in die System-Proxy-Einstellungen ein und prüfen Sie, ob der Internetzugang funktioniert. Damit trennen Sie den Proxy von der eigentlichen Arbeitsumgebung.

Wenn die Verbindung auch dort scheitert, liegt das Problem am Proxy selbst: Er kann abgelaufen oder deaktiviert sein, der Ausgangsknoten kann gestört sein oder der Anbieter kann Zugriffsbeschränkungen gesetzt haben. Die weiteren Schritte können Sie dann überspringen und beim Proxy-Anbieter Status und Nutzung prüfen.

Funktioniert die Verbindung dort, ist der Proxy grundsätzlich aktiv. Das Problem liegt dann in der Konfiguration oder im Verbindungsweg, also geht die Prüfung weiter.

Eine einfache Regel reicht: Funktionieren dieselben Zugangsdaten an anderer Stelle, sind die Zugangsdaten selbst wahrscheinlich in Ordnung.

Authentifizierung und Protokoll müssen zusammenpassen

Sind die Zugangsdaten korrekt, aber die Verbindung scheitert trotzdem, ist als Nächstes das Protokoll zu prüfen. Drei typische Fehlkonfigurationen sind: Der Anbieter liefert SOCKS5, in der Umgebung ist aber HTTP gewählt; ein selbst eingerichteter SSH-Tunnel wird als SOCKS5 konfiguriert; oder ein Proxy unterstützt mehrere Protokolle mit unterschiedlichen Ports und es wurde der Port eines anderen Protokolls eingetragen.

Orientieren Sie sich am Fehlertext. Bei Authentifizierungsfehlern oder ungültigen Zugangsdaten prüfen Sie Benutzername und Passwort. Achten Sie auf Leerzeichen oder Zeilenumbrüche durch Kopieren und Einfügen sowie auf erforderliches Escaping von Sonderzeichen im Benutzernamen. Bei Protokoll- oder Handshake-Fehlern prüfen Sie Protokolltyp und Port.

Benutzername und Passwort sollten Sie testweise einmal manuell eingeben. Unsichtbare Zeichen können Fehler verursachen, die sich durch bloßes Anschauen nicht erkennen lassen.

Prüfen, ob die Client-Konfiguration wirklich aktiv ist

Hier geht es um eine weniger offensichtliche Frage: Die Werte sind korrekt eingetragen, aber werden sie tatsächlich verwendet?

Zwei Fälle sind häufig. Erstens wurde die Konfiguration gar nicht übernommen: Änderungen wurden nicht gespeichert, eine andere Umgebung wurde bearbeitet oder die vorherige Sitzung läuft noch. Zweitens ist die Konfiguration aktiv, wird aber überschrieben: Es kann einen weiteren Netzwerkschalter geben, eine Erweiterung kann den Proxy selbst steuern oder die Proxy-Einstellungen des Systems können eine höhere Priorität haben.

Entscheidend ist die Ausgangsadresse. Öffnen Sie nach dem Verbinden eine Seite, die die aktuelle Ausgangsadresse anzeigt. Dort muss die Proxy-Adresse erscheinen, nicht die lokale Adresse. Wird weiterhin die lokale Adresse angezeigt, läuft die Anfrage nicht über den Proxy, selbst wenn der Test als erfolgreich gemeldet wird.

Der Vergleich ist einfach: Schalten Sie in derselben Umgebung den Proxy einmal ein und einmal aus und prüfen Sie, ob sich die Ausgangsadresse ändert. Bleibt sie gleich, liegt das Problem auf der Client-Seite. Bei mehreren parallelen Umgebungen muss der Ausgang jeder Umgebung einzeln kontrolliert werden. Tools mit kontogetrennter Umgebung wie PurpleMark achten beim Binden eines Proxys genau darauf.

Ablehnung durch die Zielseite erkennen

Wenn alle Ebenen erreichbar sind und der Proxy nachweislich aktiv ist, die eigentliche Seite aber weiterhin nicht funktioniert, sollten Sie die Reaktion der Zielseite untersuchen, statt den Proxy weiter zu verändern.

Typische Muster sind deutlich: Verbindung und Handshake funktionieren, doch die Anfrage liefert 403 oder wird zurückgesetzt; die Seite öffnet sich, aber Aktionen wie Anmeldung oder Veröffentlichung werden abgelehnt; derselbe Ausgang funktioniert bei anderen Websites und nur bei dieser nicht; oder die Fehler treten sporadisch auf, was auf Ratenbegrenzung des Ausgangs oder Verbindungswegs beziehungsweise auf Begrenzungen der Parallelität hindeutet.

Wichtig ist die Trennung von Verbindungs- und Anwendungsebene. Kommt gar keine Verbindung zustande, liegt das Problem wahrscheinlich am Proxy. Kommt die Verbindung zustande, wird aber abgelehnt, sind häufig die Qualität der Ausgangs-IP oder die Zugriffshäufigkeit entscheidend. Rechenzentrums-IPs und stark genutzte gemeinsam verwendete IPs werden auf Anwendungsebene eher blockiert. Residential-IPs schneiden oft besser ab, sind aber keine Garantie: Anfragefrequenz, Parallelität und Zugriffszeit spielen ebenfalls eine Rolle.

Drei Gewohnheiten bei der Fehlersuche

Ändern Sie immer nur einen Punkt. Wenn Sie gleichzeitig Protokoll und Knoten wechseln, wissen Sie selbst bei Erfolg nicht, welche Änderung geholfen hat, und laufen später erneut in denselben Fehler.

Zuerst dokumentieren, dann anpassen. Halten Sie eine funktionierende Konfiguration mit Adresse, Port, Protokoll und Authentifizierungsmethode fest. Beim nächsten Problem ist der direkte Vergleich deutlich schneller als eine Analyse von Grund auf.

Vergleichstests sind besser als ständige Wiederholungen. Wenn die Konfiguration korrekt aussieht und die Verbindung trotzdem scheitert, liefert wiederholtes Klicken auf die Testschaltfläche keine neuen Informationen. Testen Sie stattdessen eine andere Netzwerkumgebung oder einen anderen Proxy zum Vergleich.