Proxy-Statusfehlercodes lösen4xx, 5xx und unterbrochene Verbindungen verstehen

Ein Proxy-Fehler ist selten ein Rätsel, sobald man ihn als Satz liest. Der Statuscode verrät, wer gescheitert ist (Ihr Client, der Proxy oder das Ziel), und der Body oder die Header erklären meistens warum. Das Problem ist, dass derselbe Code je nachdem, ob er vom Proxy-Hop oder vom Ursprungsserver kam, zwei verschiedene Dinge bedeuten kann. Diese Mehrdeutigkeit treibt Menschen im Kreis. Ein 403 vom Ziel ist eine Sperrung; ein 407 vom Proxy ist ein Auth-Problem; ein 502 kann von beiden Seiten kommen. Klären Sie, welche Schicht gesprochen hat, und die Lösung ist fast immer offensichtlich.

Dies ist eine Referenz, die Sie beim Debuggen geöffnet lassen können. Sie ordnet die Statuscodes, die beim Scraping über einen Proxy-Server tatsächlich auftreten, ihrer Bedeutung im Proxy-Kontext und der Behebung zu, wobei proxy-spezifische Fälle (Auth, Rate-Limits, Gateway-Fehler, Geo-Sperren) hervorgehoben statt verallgemeinert werden. Überfliegen Sie die Tabelle, springen Sie zu Ihrem Code und wenden Sie die Lösung an.

Proxy-Fehlercodes auf einen Blick

Beginnen Sie hier. Die Tabelle deckt die Codes ab, die einen Scrape tatsächlich stoppen; die folgenden Abschnitte vertiefen die Codes mit proxy-spezifischen Fallstricken.

Eine Leseregel vor den Details: Fragen Sie, welcher Hop den Code erzeugt hat. Ein 4xx, der "proxy" nennt (407), kommt vom Proxy; fast jeder andere 4xx kommt vom Ziel, das durch einen funktionierenden Proxy spricht. Ein 5xx, der sofort ankommt, ist normalerweise der Proxy, der den Upstream nicht erreichen kann; ein 5xx nach einer langen Pause ist normalerweise der Ursprungsserver, der ein Timeout hat. Diese eine Unterscheidung führt Sie schneller zur richtigen Lösung als das Auswendiglernen jedes Codes.

4xx: Die Anfrage hat das Ziel erreicht und wurde abgelehnt

Das bedeutet, eine Anfrage kam durch, wurde aber abgelehnt. Mit einer Ausnahme (407) hat der Proxy seine Arbeit getan und das Urteil kam vom Ursprungsserver.

403 Forbidden: Sie wurden blockiert, nicht dauerhaft gesperrt

Das ist der Code, den Scraper am häufigsten sehen. Das Ziel akzeptierte die Verbindung, betrachtete die Anfrage und entschied, dass es nicht darauf antworten möchte. Im Proxy-Kontext bedeutet das fast immer, dass die Exit-IP markiert wurde (ein bekannter Datacenter-Bereich, eine bereits rate-limitierte Adresse) oder der Anfrage-Fingerabdruck automatisiert aussah (fehlende oder Standard-Header, kein realistischer User-Agent, eine Header-Reihenfolge, die kein Browser sendet).

Die Lösung ist mehrschichtig. Rotieren Sie zunächst zu einer frischen Exit-IP und versuchen Sie es erneut; eine einzelne Sperrung bedeutet nicht, dass der gesamte Pool verbrannt ist. Wenn saubere IPs weiterhin einen 403 erhalten, ist das Problem Vertrauen, nicht Glück: Ein gehärtetes Ziel blockiert Datacenter-Bereiche sofort, also wechseln Sie zu Residential. Unter Datacenter- vs. Residential-Proxys sehen Sie, wo diese Grenze liegt. Wenn Rotation und eine höhere Vertrauensstufe beide scheitern, ist die Sperrung auf Fingerabdruckebene und Sie benötigen realistische Header und oft eine gerenderte Seite statt eines rohen Abrufs. Das umfassendere Playbook finden Sie unter wie man scrapt, ohne gesperrt zu werden.

407 Proxy Authentication Required: Der Proxy fragt, nicht die Seite

Der 407 ist der einzige 4xx, der vom Proxy-Hop selbst kommt, und er wird am häufigsten falsch interpretiert. Das Ziel hat Ihre Anfrage nie gesehen; der Proxy weigerte sich, sie weiterzuleiten, weil Sie sich nicht am Proxy authentifiziert haben. Zwei Dinge verursachen es: falsche oder fehlende Credentials oder ein IP-Whitelist-Proxy, der die Adresse, von der Sie aufrufen, nicht erkennt.

Senden Sie Credentials in der Proxy-URL oder whitelisten Sie Ihre Quell-IP im Provider-Dashboard, je nachdem, welchen Auth-Modus Ihr Plan verwendet. Mit curl gehen Credentials in das Argument -x, nicht in die Anfrage an das Ziel.

# 407 fix: authenticate TO the proxy in the -x URL.
# user:pass here are the proxy's credentials, not the site's.
curl -x "http://USER:[email protected]:8080" \
     "https://httpbin.org/ip"

# IP-whitelist plans take no credentials; the proxy
# checks your source IP instead. Confirm it is allowed.

Wenn Sie jede andere Anfrage gut authentifizieren und plötzlich ein 407 auftritt, prüfen Sie, ob sich Ihre ausgehende IP geändert hat (ein neuer Container, ein VPN, ein CI-Runner) und whitelisten Sie sie erneut. Weitere curl-und-Proxy-Muster finden Sie unter wie man curl mit einem Proxy verwendet.

401 Unauthorized: Das Ziel möchte Credentials

Leicht mit 407 zu verwechseln, aber es ist die entgegengesetzte Schicht. Ein 401 bedeutet, dass der Proxy Ihre Anfrage weitergeleitet hat und das Ziel geantwortet hat, dass die Ressource eine Authentifizierung erfordert, die Sie nicht geliefert haben. Der Proxy funktioniert korrekt. Beheben Sie es, indem Sie die eigenen Credentials, den API-Schlüssel oder das Session-Token der Seite senden, genau wie ohne Proxy. Wenn Sie abwechselnd 401 und 407 sehen, haben Sie zwei separate Auth-Probleme gestapelt: eines zum Proxy, eines zum Ursprungsserver.

400 Bad Request: Die Nachricht selbst ist fehlerhaft

Ein 400 bedeutet, dass die Anfrage fehlerhaft war, bevor jemand ihre Meriten beurteilen konnte: ungültige Syntax, fehlerhafte URL-Kodierung, duplizierte oder übergroße Header oder ein Body, der nicht mit seinem deklarierten Content-Type übereinstimmt. Durch einen Proxy achten Sie auf doppelte Kodierung, wenn Sie eine Ziel-URL als Query-Parameter an eine API übergeben, und auf Header-Injection durch String-Konkatenation. Protokollieren Sie die genauen Bytes, die Sie senden, und lesen Sie sie zurück; der Defekt liegt fast immer in Ihrem Request-Builder, nicht im Netzwerk.

429 Too Many Requests: Sie haben ein Rate-Limit ausgelöst

Sie haben mehr Anfragen gesendet, als das Ziel (oder Ihr Proxy-Plan) in einem Zeitfenster erlaubt. Die ehrliche Lösung ist, langsamer zu werden und zu verteilen: Verzögerung zwischen Anfragen hinzufügen, Parallelität begrenzen und Exit-IPs rotieren, damit die Last auf viele Adressen statt eine fällt. Respektieren Sie den Header Retry-After, wenn die Antwort ihn enthält, anstatt blind zu hämmern.

Rotierende IPs sind die strukturelle Lösung hier, weil ein pro-IP gezähltes Rate-Limit zurückgesetzt wird, wenn die IP es tut. Unter wie man rotierende Proxys verwendet finden Sie die Mechanik, und rotierende Residential-Proxys wenn das Ziel auch die IP-Vertrauenswürdigkeit prüft.

451 Unavailable For Legal Reasons: Geo- oder Richtliniensperrung

Ein 451 bedeutet, dass der Inhalt aus rechtlichen oder regionalen Gründen zurückgehalten wird, nicht wegen eines technischen Fehlers. Im Proxy-Kontext ist das normalerweise Geo-Gating: Die Exit-IP befindet sich in einer Region, die das Ziel nicht bedient. Die Lösung ist, von einem erlaubten Land aus auszugehen. Wählen Sie einen Proxy mit Geo-Targeting und bestätigen Sie, dass er tatsächlich die Region abdeckt, die Sie benötigen, dann verifizieren Sie den Exit-Standort mit einem Echo-Dienst, bevor Sie von Abdeckung ausgehen.

5xx: Der Fehler liegt upstream, aber in welchem Hop?

Diese kommen von einem Server, nicht von Ihrer Anfrage, doch durch einen Proxy ist "der Server" mehrdeutig: Es kann der Proxy sein, der den Ursprungsserver nicht erreicht, oder der Ursprungsserver, der selbst scheitert. Das Timing unterscheidet sie.

502 Bad Gateway: Der Proxy hat Müll vom Upstream bekommen

Ein 502 bedeutet, dass ein Gateway (hier Ihr Proxy) eine ungültige oder leere Antwort von dem Server erhalten hat, den es zu erreichen versuchte. Er kommt normalerweise schnell, weil der Proxy schnell aufgegeben hat. Ursachen teilen sich in zwei Wege: Der Proxy selbst ist ungesund oder falsch konfiguriert, oder der gewählte Upstream-Exit ist tot. Versuchen Sie es zunächst erneut, da 502s oft vorübergehend sind; wenn Wiederholungen weiterhin scheitern, wechseln Sie zu einer anderen Exit-IP und bestätigen Sie, dass der Proxy-Endpunkt selbst läuft, indem Sie eine Anfrage an einen bekannt guten Echo-Dienst durch ihn senden. Wenn das auch mit 502 antwortet, ist die Proxy-Schicht das Problem, nicht das Ziel.

503 Service Unavailable: Überlastet oder ausgefallen

Ein 503 bedeutet, dass der Server vorübergehend nicht in der Lage ist, die Anfrage zu bearbeiten: überlastet, in Wartung oder Last abstoßend. Von einem Proxy aus kann das das Ziel sein, das Ihren Traffic speziell abstößt (ein sanfter Block als 503 verkleidet) oder tatsächlich für alle ausgefallen. Zurückziehen und mit Jitter wiederholen; wenn eine einzelne Exit-IP 503 bekommt, während andere erfolgreich sind, wird diese IP gedrosselt, also rotieren. Wenn jeder Exit gleichzeitig 503 bekommt, ist das Ziel ausgefallen und Warten ist die einzige Möglichkeit.

504 Gateway Timeout: Jemand in der Kette hat keine Zeit mehr

Ein 504 ist ein Timeout auf einem Gateway-Hop: Der Proxy wartete auf den Ursprungsserver und der Ursprungsserver hat nie geendet, oder der Proxy selbst war zu langsam, um zu antworten. Im Gegensatz zu 502 kommt er nach einer langen Pause. Erhöhen Sie Ihr Client-Timeout für echte langsame Seiten, versuchen Sie es erneut (Timeouts sind häufig vorübergehend) und wechseln Sie Exits, wenn eine Route konstant langsam ist. Wenn Seiten einen Browser zum Rendern benötigen, kann ein roher Abruf scheinbar ein Timeout haben, wenn das eigentliche Problem unvollständige JavaScript-Ausführung ist, was eine Rendering-Schicht löst statt einem längeren Timeout.

Verbindungsebenen-Fehler: Nichts hat einen HTTP-Code erhalten

Manche Fehler erreichen nie den Punkt eines HTTP-Status. Das sind Socket-Fehler, und sie bedeuten fast immer, dass der Proxy falsch konfiguriert war, nicht dass die Anfrage abgelehnt wurde.

Connection refused bedeutet, dass an dem Host und Port, den Sie gewählt haben, nichts hörte: falscher Port, falscher Host, der Proxy läuft nicht oder ein Schema-Konflikt (HTTP an einen HTTPS-only-Endpunkt senden). Überprüfen Sie genau den host:port und das Protokoll, das Ihr Provider Ihnen gegeben hat.

Connection reset / timeout bedeutet, dass der Socket geöffnet, aber getrennt wurde oder nie antwortete: eine tote Exit-IP, eine aggressive Firewall oder das Ziel, das markierten Traffic still löscht. Mit einem frischen Exit erneut versuchen; wenn Resets auf einer IP häufen, ist sie verbrannt. TLS- / Zertifikatsfehler durch einen Proxy bedeuten normalerweise, dass etwas TLS in der Mitte beendet. Verwenden Sie CONNECT-Tunneling für HTTPS, damit der Proxy verschlüsselte Bytes weiterleitet, ohne sie zu inspizieren; Details unter HTTP- vs. HTTPS-Proxys.

Ganze Fehlerklassen verschwinden lassen

Beachten Sie das Muster durch die Tabelle: 403, 429, 502, 503 und die meisten Verbindungsresets teilen sich alle eine Lösung: zu einem sauberen Exit rotieren und erneut versuchen. Dies selbst aufzubauen bedeutet einen gesunden Pool, eine Rotationsrichtlinie, Backoff mit Jitter und Retry-Logik pro Code. Ein verwalteter rotierender Endpunkt erledigt das für Sie, weshalb mehrere Fehlerklassen einfach aufhören aufzutreten, sobald Rotation und Wiederholungsversuche serverseitig werden.

Eine Wiederholungsschleife, die den Code liest

Unabhängig davon, welchen Proxy Sie verwenden, sollte Ihr Client auf den Statuscode reagieren, anstatt jeden Fehler gleich zu behandeln. Die minimale Version: Die vorübergehenden Klassen mit Backoff wiederholen, bei einem per-IP-Block rotieren und bei einem echten Client-Fehler, den Sie durch erneutes Versuchen nicht beheben können, stoppen.

import time, requests

RETRY = {429, 502, 503, 504}  # transient: back off and retry
ROTATE = {403, 429}        # per-IP: try a fresh exit

def fetch(url, get_proxy, tries=5):
    for n in range(tries):
        proxy = get_proxy()  # new exit IP each call
        r = requests.get(url, proxies=proxy, timeout=30)
        if r.status_code == 200:
            return r
        if r.status_code not in RETRY and r.status_code not in ROTATE:
            r.raise_for_status()  # 400/401/451: stop, fix the request
        wait = int(r.headers.get("Retry-After", 2 ** n))
        time.sleep(wait)
    r.raise_for_status()

Die Form ist wichtiger als die Sprache: Den Code klassifizieren, bei vorübergehenden Fehlern zurückziehen, bei per-IP-Sperren rotieren und bei Fehlern, die durch erneutes Versuchen nicht behoben werden können, schnell scheitern. Ein verwalteter Endpunkt faltet die Rotate-und-Retry-Hälfte in sich selbst, sodass Ihre Schleife nur die echten Client-Fehler behandeln muss.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem 403- und einem 407-Proxy-Fehler?

Ein 407 kommt vom Proxy selbst: Er weigerte sich, Ihre Anfrage weiterzuleiten, weil Sie sich nicht beim Proxy authentifiziert haben, sodass das Ziel die Anfrage nie gesehen hat. Ein 403 kommt vom Ziel, nachdem der Proxy die Anfrage erfolgreich weitergeleitet hat: Die Seite hat Ihre IP oder Ihren Fingerabdruck betrachtet und sich geweigert, sie zu bedienen. Beheben Sie 407 mit Proxy-Credentials oder IP-Whitelisting; beheben Sie 403 durch Rotation der Exit-IP oder Erhöhung der Vertrauensstufe Ihres Proxys.

Wie behebe ich einen 429 Too Many Requests-Fehler beim Scraping?

Verlangsamen und verteilen. Verzögerung zwischen Anfragen hinzufügen, Parallelität begrenzen und den Header Retry-After respektieren, wenn er vorhanden ist, anstatt sofort erneut zu versuchen. Da Rate-Limits typischerweise pro IP gezählt werden, ist das Rotieren Ihrer Exit-IP die strukturelle Lösung: Jede neue Adresse startet mit einem frischen Kontingent. Das Kombinieren von Abstand mit Rotation klärt die große Mehrheit der 429s.

Was verursacht einen 502 Bad Gateway durch einen Proxy?

Ein 502 bedeutet, dass Ihr Proxy (als Gateway fungierend) eine ungültige oder leere Antwort von dem Server erhalten hat, den er zu erreichen versuchte. Er kommt normalerweise schnell. Die Ursache ist entweder ein ungesunder Proxy oder eine tote Upstream-Exit-IP. Versuchen Sie es zuerst erneut, da viele 502s vorübergehend sind; wenn sie anhalten, wechseln Sie zu einem anderen Exit und bestätigen Sie, dass der Proxy-Endpunkt selbst läuft, indem Sie eine Anfrage an einen bekannt guten Echo-Dienst durch ihn senden.

Warum erhalte ich connection refused statt eines HTTP-Fehlercodes?

Connection refused ist ein Socket-Level-Fehler, der auftritt, bevor eine HTTP-Antwort existieren kann: An dem Host und Port, den Sie gewählt haben, hörte nichts. Prüfen Sie, dass Proxy-Host, Port und Schema genau mit dem übereinstimmen, was Ihr Provider Ihnen gegeben hat, dass der Proxy-Prozess läuft und dass Sie kein einfaches HTTP an einen HTTPS-only-Endpunkt senden. Das ist ein Konfigurationsfehler, keine Ablehnung Ihrer Anfrage.

Können rotierende Proxys Proxy-Fehlercodes eliminieren?

Rotation entfernt die per-IP-Fehlerklassen, hauptsächlich 403-Sperren und 429-Rate-Limits, weil beide zurückgesetzt werden, wenn sich die Exit-IP ändert, und es hilft bei vorübergehenden 5xx, indem bei einem frischen Exit erneut versucht wird. Es behebt keine Codes, die von Ihrer eigenen Anfrage kommen, wie 400 oder 401, oder legale Geo-Sperren wie 451. Kombinieren Sie Rotation mit korrektem Request-Building und Geo-Targeting, um den Rest abzudecken.

Soll ich jeden Proxy-Fehler automatisch wiederholen?

Nein. Die vorübergehenden Klassen (429, 502, 503, 504) mit exponentiellem Backoff und Jitter wiederholen und die Exit-IP bei per-IP-Sperren (403, 429) rotieren. Client-Fehler, die Sie verursacht haben (400, 401, 451) nicht blind wiederholen, da erneutes Versuchen mit derselben Anfrage wieder scheitert und ein Rate-Limit-Cooldown verlängern kann. Zuerst den Code klassifizieren, dann wiederholen, rotieren oder stoppen wählen.

HR

Hassan Rehan

Softwareentwickler · Crawlbase

Softwareentwickler bei Crawlbase, der praxisnahe Anleitungen zu rotierenden Proxys, Scraping und den praktischen Details schreibt, Proxys in echten Code einzubinden.