Proxy-Fehlercodes im Überblick: 407, 403, 429, 502 und Timeouts beheben

Ein Proxy-Fehlercode verrät, auf welcher Ebene eine Anfrage hängen geblieben ist. 407 bedeutet, dass der Proxy Sie nicht erkennt, 403 und 429 zeigen meist an, dass die Zielseite die Anfrage ablehnt, und 502 sowie 504 weisen darauf hin, dass die Verbindung zwischen Proxy und Ziel abgebrochen ist. Timeouts und Meldungen wie „tunnel connection failed“ lesen Sie nach derselben Logik: Finden Sie zuerst heraus, wer den Fehler erzeugt hat, und beheben Sie dann genau diese Ebene.

Dieser Leitfaden teilt die häufigsten Codes in drei Gruppen ein: Authentifizierung, Ablehnung durch die Zielseite sowie Netzwerk und Timeout. Für jeden Code finden Sie die typische Ursache, die erste Stelle, an der Sie nachsehen sollten, und wie er in cURL und Python aussieht. In den Beispielen wird die WeProxy-Gateway-Adresse gw.weproxy.com.tr:8989 verwendet; USER und PASSWORD sind Ihre Zugangsdaten aus dem Panel.

Wer hat den Fehler erzeugt: der Proxy oder die Zielseite?

Bei einer Proxy-Anfrage gibt es zwei getrennte Verbindungen. Die erste besteht zwischen Client und Proxy, die zweite zwischen Proxy und Zielseite. Der Fehlercode entsteht auf einer dieser beiden Verbindungen, und dort setzt auch die Lösung an.

Bei HTTPS-Anfragen sendet der Client zunächst CONNECT example.com:443 an den Proxy. Antwortet der Proxy mit 200 Connection Established, steht der Tunnel, und jeder danach eintreffende HTTP-Code stammt von der Zielseite. Baut der Proxy den Tunnel nicht auf, kommt der Fehler bereits in der Antwort auf CONNECT, etwa als 407, 403 oder 502. Am schnellsten erkennen Sie diesen Unterschied in der Ausgabe von curl -v:

curl -v -x "http://USER:[email protected]:8989" https://api.ipify.org

Sehen Sie in der Ausgabe die Zeile < HTTP/1.1 200 Connection established, hat der Proxy seine Arbeit erledigt. Tritt der Fehler erst nach dieser Zeile auf, liegt das Problem auf der Zielseite. Ist bereits die Antwort auf CONNECT fehlerhaft, liegt das Problem in der Proxy-Verbindung. Bei einfachen HTTP-Anfragen (ohne TLS) gibt es kein CONNECT; hier verraten Header wie Server, Via oder cf-ray in der Antwort, woher der Code stammt.

Als Faustregel gilt:

• 407 kommt immer vom Proxy.
• 403, 429 und CAPTCHAs sind meist eine Entscheidung der Zielseite.
• 502, 503 und 504 bedeuten, dass der Proxy das Ziel nicht erreicht oder nicht rechtzeitig eine Antwort erhalten hat.
• Clientseitige Fehler (curl: (7), ProxyError, ERR_PROXY_CONNECTION_FAILED) treten auf, wenn der Proxy gar nicht erreichbar ist – noch bevor überhaupt ein HTTP-Code entsteht.

407 Proxy Authentication Required

407 bedeutet, dass der Proxy die Anfrage ohne Authentifizierung nicht annimmt. RFC 9110 definiert diesen Code: Der Proxy sendet in seiner Antwort den Header Proxy-Authenticate, und der Client übermittelt die Zugangsdaten bei der nächsten Anfrage im Header Proxy-Authorization.

Die häufigsten Ursachen:

1. Falscher Benutzername oder falsches Passwort. Sehr häufig rutscht beim Kopieren aus dem Panel ein Leerzeichen an den Anfang oder das Ende.
2. Sonderzeichen sind nicht kodiert. Enthält das Passwort @, :, /, # oder %, muss es in der Proxy-URL prozentkodiert werden. Das Passwort p@ss wird in der URL als p%40ss geschrieben. Ohne Kodierung hält der Client alles nach dem @ für den Host.
3. Die IP-Whitelist passt nicht. Arbeiten Sie ohne Zugangsdaten über IP-Autorisierung, muss Ihre ausgehende IP im Panel hinterlegt sein. Hat sich die IP Ihres Heimanschlusses geändert oder geht der Server über eine andere IPv6-Adresse ins Netz, erhalten Sie 407.
4. Der Client sendet die Zugangsdaten nicht mit. Manche Bibliotheken lesen die Proxy-Zugangsdaten nur aus der URL, andere erwarten einen separaten Parameter. Browser-Erweiterungen wiederum warten bei passwortgeschützten Proxys auf ein Pop-up-Fenster.
5. Laufzeit oder Guthaben des Pakets. Bei einem inaktiven Paket werden auch korrekte Zugangsdaten nicht akzeptiert. Prüfen Sie den Status des Pakets im Panel.

Bei WeProxy-Paketen lassen sich Benutzername/Passwort und IP-Whitelist über HTTP und SOCKS5 parallel nutzen. Wenn Sie die Zugangsdaten in mehreren Tools verwenden, tippen Sie das Format nicht von Hand ab, sondern wandeln Sie es mit dem Proxy-Format-Konverter zwischen ip:port:user:pass und URL-Format um.

So kodieren Sie das Passwort in Python sicher:

from urllib.parse import quote

user = "USER"
password = quote("p@ss:w0rd/1", safe="")
proxy = f"http://{user}:{password}@gw.weproxy.com.tr:8989"
proxies = {"http": proxy, "https": proxy}

403 Forbidden und 429 Too Many Requests

403 bedeutet, dass die Anfrage verstanden, aber abgelehnt wurde. Bei Proxy-Nutzung erzeugt diesen Code meist die Sicherheitsebene der Zielseite (WAF, Bot-Schutz, CDN-Regel). Gibt der Proxy selbst 403 zurück, geschieht das in der Regel in der CONNECT-Phase, weil ein Port oder Ziel nicht erlaubt ist.

Typische Ursachen für ein 403 von der Zielseite sind: eine schlechte Reputation der IP-Adresse, ein IP-Typ, der nicht zur Seite passt (etwa bei einer Seite, die Datacenter-IPs pauschal blockiert), eine Länderbeschränkung oder Request-Header, die nicht nach einem echten Browser aussehen. Ein IP-Wechsel ist zwar der erste Reflex, doch solange User-Agent, Accept-Language und Cookies nicht konsistent sind, erhält auch die neue IP dieselbe Antwort.

429 ist dagegen eindeutig ein Rate Limit. RFC 6585 definiert diesen Code, und der Server teilt Ihnen meist über den Header Retry-After mit, wie lange Sie warten sollen. Der Zähler wird in der Regel pro IP geführt und greift, wenn Sie viele gleichzeitige Anfragen über dieselbe ausgehende IP senden.

WeProxy-Pakete haben kein Limit für gleichzeitige Verbindungen oder Threads. Erhalten Sie also ein 429, setzt das Limit fast immer die Zielseite. Das sollten Sie tun:

• Halten Sie sich an den Wert von Retry-After; fehlt er, nutzen Sie exponentielles Backoff (1, 2, 4, 8 Sekunden).
• Reduzieren Sie die Parallelität, die sich auf einer einzelnen IP ballt.
• Ein IP-Wechsel pro Anfrage eignet sich für Aufgaben ohne Session. Für Aufgaben mit Session verwenden Sie eine Sticky-Session; die Unterschiede erklärt unser Leitfaden zu Sticky vs. Rotating.
• Für Ziele, die IPs mit hohem Trust Score verlangen, eignet sich ein Rotating Residential Proxy; brauchen Sie eine langlebige, gleichbleibende Identität, wählen Sie einen ISP-Proxy.

Den IP-Pool zu vergrößern, um ein Rate Limit zu umgehen, ist keine Lösung, wenn dadurch die Nutzungsbedingungen des Ziels verletzt werden. Automatisierung sollte sich auf das beschränken, was das Ziel erlaubt, und den Regeln zur akzeptablen Nutzung folgen.

502, 503 und 504: Der Proxy hat das Ziel nicht erreicht

Diese drei Codes bilden die „Gateway“-Familie und zeigen an, dass der Proxy auf der Zielseite ein Problem hatte.

502 Bad Gateway: Der Proxy hat sich mit dem Ziel verbunden, aber keine gültige Antwort erhalten, oder die Verbindung kam gar nicht erst zustande. Möglicherweise ist der Zielserver offline, der Proxy konnte den Domainnamen des Ziels nicht auflösen, oder das im Residential-Pool genutzte Ausgangsgerät ist während der Verbindung offline gegangen. Da Residential- und Mobile-IPs von echten Geräten stammen, sind einzelne 502-Fehler normal; ein erneuter Versuch reicht meistens aus.

503 Service Unavailable: Der Zielserver oder eine Zwischenschicht ist vorübergehend nicht verfügbar. Eine Wartungsseite oder ein Überlastschutz der Zielseite liefert diesen Code. Ist Retry-After gesetzt, halten Sie sich daran.

504 Gateway Timeout: Der Proxy hat vom Ziel nicht rechtzeitig eine Antwort erhalten. Auslöser sind eine langsame API, eine weit entfernte Region oder eine schwere Seite. Um die Strecke zwischen Proxy und Ziel zu verkürzen, hilft es, ein Ausgangsland nahe am Zielserver zu wählen.

Zur Unterscheidung rufen Sie dieselbe URL auch ohne Proxy auf. Tritt der Fehler auch ohne Proxy auf, liegt das Problem bei der Zielseite. Tritt er nur mit Proxy auf und verschwindet beim erneuten Versuch, hat ein einzelner Ausgang im Pool ein Problem. Wiederholt er sich dauerhaft, teilen Sie dem Support mit, bei welchem Ziel, zu welcher Uhrzeit und mit welchem Paket er auftritt.

Timeouts und Verbindungsfehler

Ein Timeout kann in zwei verschiedenen Phasen auftreten, und beide bedeuten etwas anderes:

• Connect-Timeout: Der Client konnte keine TCP-Verbindung zum Proxy aufbauen. Die Gateway-Adresse ist falsch, der Port ist geschlossen oder das lokale Netzwerk bzw. die Firewall blockiert die Verbindung.
• Read-Timeout: Die Verbindung wurde aufgebaut, aber die Antwortzeit ist abgelaufen. Ursache ist meist ein langsames Ziel oder eine lange Antwortkette.

Um beides zu unterscheiden, geben Sie Ihrer Bibliothek zwei getrennte Zeitlimits vor. Bei Python requests gewährt timeout=(10, 30) dem Verbindungsaufbau 10 und dem Lesen 30 Sekunden. Geben Sie nur einen Wert an, gilt er für beide Phasen, und die Diagnose wird schwieriger.

Ist der Proxy überhaupt nicht erreichbar, prüfen Sie zuerst die lokale Seite: Kontrollieren Sie mit dem Port-Checker, ob Port 8989 unter gw.weproxy.com.tr von außen als offen erscheint, und anschließend, ob Ihr eigenes Netzwerk ausgehende Verbindungen zu diesem Port zulässt. Firmennetzwerke und manche Cloud-Anbieter sperren ausgehende Verbindungen zu Nicht-Standard-Ports.

In Browsern erscheint dieselbe Situation unter anderen Bezeichnungen. Chrome zeigt ERR_PROXY_CONNECTION_FAILED, wenn es keine Verbindung zum Proxy herstellen kann, und ERR_TUNNEL_CONNECTION_FAILED, wenn es sich zwar mit dem Proxy verbindet, den Tunnel aber nicht aufbauen kann. Hinter Letzterem steckt eine Proxy-Antwort wie 407 oder 502.

Übersicht der Fehlercodes

curl: (35) tritt meist auf, wenn versucht wird, eine Verbindung zu einem HTTP-Proxy mit dem Schema https:// aufzubauen. Das Schema der Proxy-URL beschreibt das Protokoll des Proxys, nicht das des Ziels. Auch für HTTPS-Ziele wird die Proxy-Adresse mit http:// angegeben.

SOCKS5-Fehlerantworten

SOCKS5 verwendet keine HTTP-Codes. Laut RFC 1928 beantwortet der Server eine Verbindungsanfrage mit einem „Reply“-Feld. Bibliotheken zeigen diesen Wert meist als Meldung an:

Die Authentifizierung ist bei SOCKS5 ein eigener Schritt (RFC 1929). Werden Benutzername oder Passwort abgelehnt, wird die Verbindung mit einer Meldung wie „authentication failed“ geschlossen; das ist das Gegenstück zu 407 bei HTTP. Damit DNS auf Proxy-Seite aufgelöst wird, verwenden Sie socks5h:// statt socks5://; andernfalls entsteht ein DNS-Leak. Details finden Sie im DNS-Leak-Leitfaden, den Unterschied der Protokolle im Artikel HTTP vs. SOCKS5.

Fehler in Python abfangen und Anfragen wiederholen

requests meldet Proxy-Fehler über eigene Exception-Typen. Wer alle mit einem einzigen except abfängt, verliert die Diagnoseinformation. Das folgende Beispiel wiederholt Anfragen bei vorübergehenden Codes (429, 502, 503, 504) mit Backoff und meldet dauerhafte Fehler jeweils getrennt:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

proxy = "http://USER:[email protected]:8989"

retry = Retry(
    total=5,
    backoff_factor=1,
    status_forcelist=[429, 502, 503, 504],
    allowed_methods=["GET", "HEAD"],
    respect_retry_after_header=True,
)

session = requests.Session()
session.mount("http://", HTTPAdapter(max_retries=retry))
session.mount("https://", HTTPAdapter(max_retries=retry))
session.proxies = {"http": proxy, "https": proxy}

try:
    r = session.get("https://api.ipify.org?format=json", timeout=(10, 30))
    print(r.status_code, r.text)
except requests.exceptions.ProxyError as e:
    print("Proxy hat abgelehnt oder ist nicht erreichbar (407 / Verbindung):", e)
except requests.exceptions.ConnectTimeout:
    print("Timeout beim Verbindungsaufbau zum Proxy: Port und Firewall prüfen")
except requests.exceptions.ReadTimeout:
    print("Ziel hat nicht geantwortet: Read-Timeout oder Ausgangsland ändern")
except requests.exceptions.SSLError as e:
    print("TLS-Fehler: Proxy-Schema prüfen", e)

Bei HTTPS-Zielen kommt 407 nicht als HTTP-Antwort, sondern als ProxyError mit der Meldung „Tunnel connection failed: 407“. Nehmen Sie 407 nicht in die Retry-Liste auf: Ein erneuter Versuch mit falschen Zugangsdaten ändert nichts am Ergebnis. Weitere Beispiele in anderen Sprachen finden Sie auf den Seiten zur Python-Integration und zur Node.js-Integration.

Diagnose Schritt für Schritt

1. Notieren Sie Ihre IP-Adresse ohne Proxy mit dem My-IP-Tool.
2. Prüfen Sie mit dem Port-Checker, ob der Gateway-Port erreichbar ist. Ist er nicht erreichbar, liegt das Problem im lokalen Netzwerk.
3. Rufen Sie mit curl -v -x ... https://api.ipify.org Ihre IP über den Proxy ab. Ist die zurückgegebene IP der Proxy-Ausgang, funktionieren Authentifizierung und Tunnel.
4. Wiederholen Sie denselben Befehl mit der Ziel-URL. Steckt der Fehler in der CONNECT-Antwort, prüfen Sie die Proxy-Seite; tritt er nach dem Tunnel auf, prüfen Sie die Zielseite.
5. Bestätigen Sie zusätzlich mit dem Proxy-Checker, dass der Proxy grundsätzlich funktioniert.
6. Überprüfen Sie bei 429 und 403 Parallelität, Header und IP-Typ. Testen Sie bei 502/504 ohne Proxy und trennen Sie das Read-Timeout ab.
7. Besteht das Problem weiter, schreiben Sie dem Support mit Ziel-URL, Fehlercode, Uhrzeit (mit Zeitzone) und Paketname. Die Ausgabe von curl -v – mit entferntem Passwort – beschleunigt die Diagnose.

Die meisten Proxy-Fehler lassen sich in drei Sätzen zusammenfassen: 407 betrifft die Zugangsdaten, 403 und 429 sind Entscheidungen des Ziels, 5xx und Timeouts betreffen den Weg zwischen Proxy und Ziel. Wenn Sie den Fehler der richtigen Ebene zuordnen, treffen Sie die richtige Wahl zwischen IP-Wechsel, Korrektur der Zugangsdaten und Abwarten.