Proxy funktioniert nicht: Fehler systematisch eingrenzen

Proxy-Verbindung fehlgeschlagen? Prüfen Sie in fester Reihenfolge Netzwerk, Host und Port, Protokoll, Zugangsdaten und Whitelist – mit Diagnosetabelle und curl-Tests.

Wenn ein Proxy nicht funktioniert, lässt sich der Fehler meist einer Stelle zuordnen: im eigenen Netz, beim Proxy-Server, in der Konfiguration oder bei der Zielseite. Diese Anleitung prüft die Stellen nacheinander, von unten nach oben, damit Sie nicht an drei Schrauben gleichzeitig drehen. Sie richtet sich an alle, die einen gekauften Proxy in Browser, Skript oder Programm eintragen. Wir verkaufen keine IPs und verteilen keine kostenlosen Zugänge; wir vergleichen Anbieter.

01Die Reihenfolge: warum von unten nach oben#

Eine Proxy-Verbindung hat vier Schichten, und jede baut auf der vorherigen auf. Ohne funktionierendes Netz erreichen Sie den Proxy nicht. Ohne erreichbaren Proxy spielt das Passwort keine Rolle. Ohne korrekte Anmeldung sehen Sie in der Regel nicht, wie die Zielseite reagiert.

Arbeiten Sie die Tabelle von oben nach unten ab. Jeder Schritt liefert einen Verdacht, keinen endgültigen Beweis; gehen Sie weiter, wenn der aktuelle Schritt plausibel bestanden ist.

02Schritt 1: Funktioniert das Netz ohne Proxy?#

Schalten Sie den Proxy in der betroffenen Anwendung aus und rufen Sie eine beliebige große Website auf. Lädt sie nicht, klären Sie zuerst Router, WLAN, VPN-Client oder Firmen-Firewall. Solange die direkte Verbindung scheitert, lässt sich der Proxy nicht sinnvoll beurteilen.

Lädt die Seite, öffnen Sie zusätzlich /de/my-ip. Die Seite zeigt die IP-Adresse, mit der genau diese eine Anfrage ankam. Notieren Sie sie. Das ist Ihr Vergleichswert für Schritt 4. Entscheidend ist dort später nicht nur, ob die Adresse anders ist, sondern ob sie zu dem Ausgang passt, den Ihr Anbieter für Ihren Zugang vorsieht.

Zwei Stolpersteine gehören schon in diesen Schritt:

• Ein VPN läuft parallel. Manche VPN-Clients leiten den gesamten Verkehr um oder blockieren Verbindungen außerhalb des Tunnels. Testen Sie den Proxy einmal mit pausiertem VPN, bevor Sie weitersuchen.
• Automatische Proxy-Erkennung oder ein PAC-Skript ist aktiv. In Firmennetzen verteilt die IT oft eine automatische Konfiguration. Sie kann Ihre manuelle Eingabe überlagern oder umgekehrt. Ändern Sie verwaltete Einstellungen nicht eigenmächtig; fragen Sie die IT, ob ein externer Proxy überhaupt zugelassen ist.

03Schritt 2: Sind Host und Port erreichbar?#

Jetzt prüfen Sie mit Bordmitteln, ob auf Adresse und Port des Proxys etwas antwortet.

Auf macOS und Linux:

nc -vz proxy.example.com 8000

In der Windows PowerShell:

Test-NetConnection proxy.example.com -Port 8000

Ersetzen Sie Host und Port durch die Werte aus Ihrem Anbieter-Dashboard. Der Test sagt nur, ob von Ihrem Netz aus eine TCP-Verbindung zu diesem Port möglich ist. Er prüft weder Passwort noch Protokoll und auch nicht, ob dahinter wirklich der erwartete Proxy-Dienst antwortet.

So lesen Sie das Ergebnis:

• Verbindung erfolgreich: Auf diesem Port nimmt etwas Verbindungen an. Weiter zu Schritt 3.
• Verbindung abgelehnt (refused): Entweder nimmt auf diesem Port niemand an, oder eine Firewall auf dem Weg weist die Verbindung aktiv zurück. Prüfen Sie zuerst, ob der Port richtig abgeschrieben ist und zum gewählten Protokoll gehört; viele Anbieter nutzen getrennte Ports für HTTP und SOCKS5.
• Zeitüberschreitung: Pakete kommen nicht an oder werden verworfen. Ursachen können eine Firewall im eigenen Netz, ein abgelaufener Tarif, ein abgeschalteter Server oder eine IP-Sperre beim Anbieter sein.
• Name kann nicht aufgelöst werden: Der Hostname kann falsch geschrieben sein, nicht mehr existieren oder Ihr DNS-Resolver bzw. Netz liefert gerade keine Antwort. Kopieren Sie ihn erneut aus dem Dashboard, ohne Leerzeichen am Ende, und prüfen Sie, ob andere Namen aufgelöst werden.

Hilfreich ist ein Gegentest aus einem anderen Netz, zum Beispiel über den Mobilfunk-Hotspot des Smartphones. Klappt die Verbindung dort, kann Ihr Heim- oder Firmennetz den Port blockieren. Möglich ist aber auch, dass der Anbieter Verbindungen je nach Herkunftsadresse unterschiedlich behandelt, etwa wegen einer Whitelist.

04Schritt 3: Protokoll, Passwort und Whitelist#

Ist der Port offen, die Verbindung scheitert aber trotzdem, liegt der Fehler häufig in der Konfiguration. Drei Dinge müssen zusammenpassen.

Das Protokoll. Ein HTTP-Proxy und ein SOCKS5-Proxy sprechen unterschiedliche Protokolle. Tragen Sie einen SOCKS5-Endpunkt als HTTP-Proxy ein, bekommen Sie oft keine verständliche Fehlermeldung, sondern einen Abbruch oder eine leere Antwort. Prüfen Sie im Dashboard, welches Protokoll zu welchem Port gehört; Eintrag und Endpunkt müssen übereinstimmen.

Die Anmeldung. Es gibt zwei übliche Wege, wie ein Anbieter Sie erkennt:

• Benutzername und Passwort. Achten Sie auf Sonderzeichen. In einer Proxy-URL hat @ eine eigene Bedeutung. Laut curl-Dokumentation werden Benutzer und Passwort in der Proxy-Angabe URL-dekodiert, ein @ im Passwort schreiben Sie dort also als %40, einen Doppelpunkt als %3a. Bei vielen Anbietern steckt im Benutzernamen außerdem eine Steuerung für Land oder Session. Ein Tippfehler darin führt je nach Anbieter zu einer Ablehnung oder zu einem anderen Standort als erwartet.
• IP-Whitelist. Der Anbieter lässt nur Verbindungen von freigegebenen Adressen zu. Hat sich Ihre eigene IP geändert, etwa nach einem Router-Neustart oder im Mobilfunknetz, kann der Proxy plötzlich ablehnen, obwohl gestern alles lief. Vergleichen Sie die IP aus Schritt 1 mit der Liste im Dashboard.

Verlangt ein HTTP-Proxy eine Anmeldung, antwortet er mit dem Statuscode 407. MDN beschreibt 407 als Gegenstück zu 401, bei dem sich der Client gegenüber dem Proxy authentifizieren muss. Bei 407 ist zumindest der antwortende Proxy erreichbar. Ob es an Zugangsdaten, Whitelist, Anmeldeverfahren oder einem weiteren Proxy in der Kette liegt, klärt erst der nächste Blick. Eine erste 407-Antwort kann auch einfach die Aufforderung sein, sich anzumelden.

Der Test mit curl. Ein Kommandozeilentest trennt Konfigurationsfehler von Eigenheiten einzelner Programme. curl ist auf macOS und aktuellen Windows-Versionen in der Regel vorhanden; die Beispiele sind für die Shell unter macOS und Linux geschrieben.

# HTTP-Proxy mit Anmeldung (Platzhalter ersetzen)
curl -q --noproxy "" -v --connect-timeout 10 --max-time 30 \
  -x http://proxy.example.com:8000 -U "BENUTZER:PASSWORT" \
  -w "\nHTTP_STATUS=%{http_code}\n" https://example.com/

# SOCKS5-Proxy, Namensauflösung über den Proxy
curl -q --noproxy "" -v --connect-timeout 10 --max-time 30 \
  -x socks5h://proxy.example.com:1080 -U "BENUTZER:PASSWORT" \
  -w "\nHTTP_STATUS=%{http_code}\n" https://example.com/

Was die Optionen bewirken, laut curl-Dokumentation:

• -q muss als erstes Argument stehen. Dann liest curl keine .curlrc-Konfigurationsdatei, die den Test unbemerkt verändern könnte.
• -x hat Vorrang vor Proxy-Umgebungsvariablen. --noproxy "" hebt zusätzlich Ausnahmelisten aus NO_PROXY auf, damit die Anfrage tatsächlich über den angegebenen Proxy läuft.
• --connect-timeout 10 begrenzt nur die Verbindungsphase, also Namensauflösung und Verbindungsaufbau samt Handshakes. --max-time 30 begrenzt den gesamten Transfer. Eine eigene Lese-Zeitgrenze setzen diese Beispiele nicht: Ein Server, der nach dem Verbindungsaufbau nicht mehr antwortet, wird erst von --max-time abgebrochen.
• Fehlt der Port in der Proxy-Angabe, nimmt curl 1080 an. Ohne Protokollpräfix gilt der Eintrag als HTTP-Proxy; für SOCKS braucht es socks5:// oder socks5h://. Bei socks5h:// löst der Proxy den Hostnamen auf, bei socks5:// Ihr eigener Rechner.

Die Option -v hilft zu erkennen, in welcher Phase der Ablauf abbricht: beim Verbindungsaufbau zum Proxy, bei der Anmeldung oder erst bei der Zielseite. TLS-Prüfung bleibt eingeschaltet; schalten Sie sie für die Diagnose nicht ab. Die ausführliche Ausgabe kann Anmeldedaten oder Authentifizierungs-Header enthalten. Entfernen Sie diese, bevor Sie die Ausgabe an den Support oder in ein Forum geben.

Was curl in einem lokalen Test tatsächlich meldet

Wir haben curl 8.7.1 mit genau diesen Schutzoptionen gegen einen lokalen Test-Proxy auf dem eigenen Rechner laufen lassen, mit Testzugangsdaten und eingeschalteter TLS-Prüfung. Das zeigt, wie curl Fehler meldet. Es ist kein Test eines kommerziellen Anbieters und sagt nichts über Geschwindigkeit, Standorte oder Kompatibilität aus.

Gerenderter Bericht der beobachteten curl-Ausgaben aus dem lokalen Test, Authentifizierungs-Header maskiert. Kein Terminal- oder Systemscreenshot und kein kommerzieller Proxy.

Zwei Lehren daraus: Wer curl in Skripten nutzt, sollte den Statuscode auswerten oder --fail setzen; dann endet curl laut Dokumentation bei Serverfehlern mit Fehlercode 22. Und ein 502 im Test stammte von der Zielseite selbst, nicht von einem Proxy-Gateway. Einen echten Gateway-Fehler des Proxys, Verbindungsabbrüche, Zeitüberschreitungen und Whitelist-Ablehnungen haben wir nicht nachgestellt; dafür gelten die Hinweise aus Schritt 2 und 3. Ein Kontrolllauf mit der Python-Bibliothek requests ergab für 407, geschlossenen Port und Ziel-401 dasselbe Muster.

Funktioniert curl, die eigentliche Anwendung aber nicht, vergleichen Sie zuerst, ob beide wirklich dasselbe tun: denselben Proxy-Endpunkt, dasselbe Protokoll, dieselben Zugangsdaten, dieselbe Zielseite und denselben Rechner im selben Netz. Erst wenn das übereinstimmt, spricht viel für die Anwendung: Manche Programme ignorieren die Systemeinstellungen, andere unterstützen nur HTTP oder speichern Anmeldedaten nicht. Das gilt auch auf dem Mac: Ein in den macOS-Netzwerkeinstellungen eingetragener Proxy wird nur von Programmen genutzt, die diese Systemeinstellung auch übernehmen. Die genaue Einrichtung gehört in die Anleitung des jeweiligen Programms.

05Schritt 4: Zielseite und Ergebnis prüfen#

Kommt die Proxy-IP an? Öffnen Sie mit eingeschaltetem Proxy erneut /de/my-ip. Vergleichen Sie die angezeigte Adresse mit dem Ausgang, den Ihr Anbieter für den Zugang nennt, etwa Land, Netz oder IP-Bereich im Dashboard. Passt sie dazu, lief diese Anfrage sehr wahrscheinlich über den Proxy. Eine andere Adresse als in Schritt 1 allein beweist das nicht, eine gleiche Adresse allein beweist das Gegenteil nicht: Vielleicht nutzt der Browser eine andere Einstellung als das Programm, das Sie eigentlich testen. Prüfen Sie deshalb im selben Programm. my-ip zeigt nur eine einzelne Anfrage; bei rotierenden Proxys kann die nächste eine andere IP haben, und das angezeigte Land muss nicht dem Land entsprechen, das Sie im Tarif gewählt haben, wenn der Anbieter es nicht garantiert.

Was sagt der Proxy-Checker? Mit dem Proxy-Checker testen Sie den Endpunkt unabhängig von Ihrem Browser. Beachten Sie die Grenze: Der Checker verbindet sich von seiner eigenen Adresse aus. Ist Ihr Proxy per IP-Whitelist auf Ihren Rechner beschränkt, wird er dort abgelehnt, obwohl er bei Ihnen funktioniert. Umgekehrt beweist ein erfolgreicher Check nicht, dass Ihr Browser richtig eingestellt ist.

Wie reagiert die Zielseite? Ein HTTP-Statuscode kann vom Proxy, von einem Zwischenserver oder von der Zielseite stammen. Die Codes helfen bei der Einordnung, nennen aber nicht automatisch den Absender:

Die Bedeutungen stammen aus der MDN-Übersicht der HTTP-Statuscodes. Hinweise darauf, welche Station geantwortet hat, liefern die ausführliche curl-Ausgabe und die Antwort-Header; im lokalen Test oben reichte curl 401 und 502 der Zielseite unverändert durch. Ein sicherer Nachweis des Absenders sind solche Hinweise nicht immer.

Hilfreich ist der Gegentest: Rufen Sie über denselben Proxy eine neutrale Seite auf. Klappt das, die Zielseite scheitert aber, ist der Proxy grundsätzlich erreichbar und eingestellt. Für die Zielseite selbst bleiben mehrere Möglichkeiten: Einschränkungen beim Anbieter für bestimmte Ziele, DNS- oder TLS-Probleme, Fehler weiter oben in der Kette oder eine Ablehnung durch die Website.

06Wenn der Proxy technisch läuft, aber nicht zur Aufgabe passt#

Nicht jeder Fehler ist ein Konfigurationsfehler. Rechenzentrums-IPs werden von manchen Plattformen strenger behandelt als Adressen aus Privat- oder Mobilfunknetzen; ob das bei Ihrer Zielseite so ist, zeigt nur die Zielseite selbst. Wenn Schritte 1 bis 3 bestanden sind, eine neutrale Seite über den Proxy lädt und der Anbieter keine Einschränkung für dieses Ziel nennt, kann sich der Blick auf einen anderen IP-Typ lohnen, etwa mobile Proxys.

Bei rotierenden Tarifen gilt außerdem: Eine neue Session-ID garantiert keine neue IP, und „sticky“ Sessions halten eine Adresse nur nach bestem Bemühen des Anbieters. Wenn eine lange Sitzung plötzlich abbricht, kann ein IP-Wechsel die Ursache sein.

Zum Vergleich von Anbietern mit unterschiedlichen IP-Typen und Protokollen finden Sie hier einige Einträge aus unserem Katalog. Die Auswahl ist keine Garantie, dass ein bestimmter Anbieter mit Ihrer Anwendung oder Zielseite funktioniert.

SOAX: Residential- und Mobile-Proxys3.9219

SOAX verkauft rotierende Residential- und Mobile-Proxys über einen gemeinsamen Credit-Pool, mit Datacenter und ISP in denselben Plänen. Der Builder startet bei $200/mo + VAT (200 Credits); Tier-1-Traffic kostet $3/GB im Builder.

85 Länder

3,00 $

pro 1 GB

Bright Data: Residential- und Datacenter-Proxys4.41438

Bright Data ist ein großes Proxy-Netz für Datenerhebung: Residential-, Mobile-, ISP- und Datacenter-IPs in rund 195 Ländern. Residential-Traffic lässt sich ohne Abo nach Verbrauch bezahlen, Datacenter- und ISP-Adressen gibt es in Paketen ab 10 IPs. Für Residential und Mobile ist eine Identitätsprüfung nötig.

10 Länder

5,00 $

pro 1 GB

Oxylabs: Residential- und Datacenter-Proxys4.0770

Oxylabs verkauft Residential-, Datacenter- und Mobile-Proxys. Residential Self-Serve startet bei $6/GB für 5 GB/Monat. Käuferzahlungen: Karten, Überweisung, AliPay, PayPal.

10 Länder

0,59 $

pro 1 GB

07Kurzfassung als Diagnosebaum#

1. Ohne Proxy kein Internet? Zuerst Netz, Router oder VPN klären; vorher lässt sich der Proxy nicht beurteilen.
2. Port-Test schlägt fehl? Host und Port neu kopieren, DNS prüfen, Gegentest über anderes Netz, Tarifstatus und Whitelist prüfen.
3. Port offen, Verbindung bricht ab? Protokoll und Port abgleichen, Sonderzeichen im Passwort kodieren, Whitelist mit aktueller eigener IP vergleichen, Anmeldeverfahren prüfen. Mit curl gegentesten.
4. curl klappt, Programm nicht? Erst Endpunkt, Protokoll, Zugangsdaten und Ziel angleichen; bleibt der Unterschied, die Programmeinstellungen prüfen.
5. Erwartete Ausgangs-IP kommt an, Zielseite scheitert? Absender des Fehlers eingrenzen, Anbieter-Einschränkungen, Anfragetempo und IP-Typ prüfen.

Am Ende steht ein begründeter Verdacht, ob Netzbetreiber, Proxy-Anbieter, Softwarehersteller oder Zielseite der richtige Ansprechpartner ist.