HTTP-Statuscodes beim Web Scraping: 403, 407, 429, 503

Die häufigsten Zeilen im Protokoll eines Scrapers sind nicht die erfolgreichen 200-Antworten, sondern die zwischendurch auftauchenden Codes 403, 429 und 503. Jeder dieser Codes beschreibt ein anderes Problem und verlangt eine andere Reaktion. Ein Skript, das alle gleich behandelt, also „dreimal wiederholen", drückt entweder gegen eine dauerhafte Sperre und verschlimmert die Lage, oder es verliert Daten bei einem vorübergehenden Problem, das sich nach wenigen Sekunden erledigt hätte.

In diesem Artikel erklären wir, wie HTTP-Statuscodes zu lesen sind, was die beim Scraping häufigsten Codes (403, 407, 429 und 503) bedeuten und welche Ursachen wahrscheinlich dahinterstehen. Danach behandeln wir 502, 504 und Verbindungsfehler, den Umgang mit dem Header Retry-After und fassen in einer Tabelle zusammen, bei welchen Codes wiederholt und bei welchen angehalten wird. Am Ende steht ein getestetes Python-Beispiel, das diese Entscheidungen umsetzt.

Wie liest man HTTP-Statuscodes?#

Jede HTTP-Antwort beginnt mit einem dreistelligen Statuscode. Die erste Ziffer bestimmt die Klasse der Antwort. Die Codes sind in Abschnitt 15 von RFC 9110 definiert; die Statuscode-Liste von MDN bietet ebenfalls kurze Erklärungen und Beispiele für jeden Code.

Die wichtigste Unterscheidung für Scraping lautet: Die meisten 4xx-Codes liefern dasselbe Ergebnis, wenn Sie exakt dieselbe Anfrage erneut senden. Sie müssen etwas an der Anfrage ändern. Die meisten 5xx-Codes sind vorübergehend, und dieselbe Anfrage kann nach einer Wartezeit gelingen. 429 ist die Ausnahme: ein 4xx-Code, der sich durch Warten erledigt.

Unabhängig vom Code noch ein Hinweis: 200 heißt nicht, dass Sie die gewünschten Daten erhalten haben. Bot-Schutzsysteme liefern Prüfseiten oft mit dem Code 200. Bevor Sie eine Antwort als Erfolg werten, prüfen Sie, ob die Seite ein erwartetes Element enthält (einen Produkttitel, ein Preisfeld).

Was bedeutet 403 Forbidden?#

403 besagt, dass der Server Ihre Anfrage verstanden hat, sie aber nicht erfüllt. Laut RFC 9110 muss der Server den Grund nicht nennen. Der Unterschied zu 401 Unauthorized, das bei fehlender Authentifizierung genutzt wird: Bei 403 ändert das Hinzufügen von Zugangsdaten das Ergebnis in der Regel nicht.

Wahrscheinliche Ursachen für ein 403 beim Scraping:

• IP-Reputation oder IP-Typ. Websites, die Verkehr aus Rechenzentrumsadressen einschränken, antworten diesen Adressen direkt mit 403.
• Geografische Beschränkung. Die Website erlaubt nur Zugriffe aus bestimmten Ländern.
• Fehlende oder widersprüchliche Header. Der Standard-User-Agent der Bibliothek oder eine Header-Kombination, die in keinem Browser vorkommt.
• Eine WAF-Regel. Die Anfrage hat eine Sicherheitsregel ausgelöst.
• Sperre wegen früheren Verkehrs. Eine IP, die das Rate-Limit lange überschreitet, kann nach einer Weile statt 429 ein 403 erhalten.
• Eine Seite, die wirklich eine Berechtigung verlangt. Ein Pfad, der ohne Anmeldung nicht erreichbar ist.

Was zu tun ist: Senden Sie dieselbe Anfrage nicht sofort erneut. Öffnen Sie die Adresse mit derselben IP in einem echten Browser. Öffnet sie sich dort, liegt das Problem an Ihrer Anfrage selbst (Header, Geschwindigkeit); öffnet sie sich nicht, an IP oder Standort. Ursachen von Sperren und legitime Lösungen erklären wir ausführlich in Web Scraping ohne Sperren.

Was bedeutet 407 Proxy Authentication Required?#

407 kommt nicht von der Zielseite, sondern vom Proxy-Server. Der Proxy verlangt, dass Sie sich ausweisen, bevor er die Anfrage an das Ziel weiterleitet. Sehen Sie 407, müssen Sie sich also um Ihre Proxy-Verbindung kümmern, nicht um die Regeln der Zielseite.

Wahrscheinliche Ursachen:

• Benutzername oder Passwort sind falsch.
• Das Passwort enthält Sonderzeichen wie @, : oder /, die in der Proxy-Adresse nicht kodiert sind (@ → %40).
• Die IP-Whitelist-Methode wird genutzt, doch die IP, von der die Verbindung kommt, steht nicht auf der Liste.
• Die Bibliothek sendet die Zugangsdaten aus der Adresse nicht an den Proxy.
• Guthaben oder Traffic-Kontingent des Kontos ist aufgebraucht.

Bibliotheken zeigen 407 unterschiedlich an. Bei HTTPS-Anfragen kann der Proxy-Tunnel nicht aufgebaut werden, daher erhalten Sie oft eine Ausnahme statt eines Antwortobjekts: Python Requests wirft ProxyError, HTTPX ebenfalls ProxyError; in Node.js liefert Axios einen Fehler mit dem Statuscode 407. Die Unterschiede der Bibliotheken zeigen wir mit getesteten Beispielen in Proxys in Node.js verwenden.

Was zu tun ist: Nicht wiederholen, sondern die Konfiguration korrigieren. Prüfen Sie in der Ausgabe von curl -v, ob der Header Proxy-Authorization gesendet wird; den Befehl selbst finden Sie in Proxy mit cURL verwenden. Beide Authentifizierungsmethoden und die Diagnose von 407 zeigen wir Schritt für Schritt in Proxy-Authentifizierung: User:Pass oder IP-Whitelist.

Was bedeutet 429 Too Many Requests?#

429 besagt, dass Sie in einem bestimmten Zeitraum zu viele Anfragen gesendet haben. Der Code ist in Abschnitt 4 von RFC 6585 definiert, der festhält, dass der Server mit einem Retry-After-Header angeben kann, wie lange Sie warten sollen.

Worauf das Rate-Limit gezählt wird, unterscheidet sich je nach Website:

• Nach IP-Adresse: Anfragen von derselben Adresse werden addiert.
• Nach Sitzung oder Cookie: Anfragen derselben Sitzung werden addiert; ein IP-Wechsel setzt den Zähler nicht zurück.
• Nach API-Schlüssel: Bei offiziellen APIs hängt das Limit meist am Schlüssel.
• Nach Endpunkt: Bei aufwendigen Endpunkten wie Suchseiten ist das Limit niedriger als bei Produktseiten.

Manche APIs melden Ihr verbleibendes Kontingent mit Headern wie X-RateLimit-Remaining und X-RateLimit-Reset. Diese Header-Namen sind nicht standardisiert und unterscheiden sich von Dienst zu Dienst; prüfen Sie die Dokumentation der genutzten API.

Was zu tun ist: Gibt es ein Retry-After, warten Sie so lange. Wenn nicht, nutzen Sie exponentiellen Backoff: 1 Sekunde beim ersten Versuch, dann 2, 4, 8 Sekunden, jeweils mit einer Zufallskomponente. Senken Sie gleichzeitig die Nebenläufigkeit; warten Sie und machen Sie mit derselben Geschwindigkeit weiter, erhalten Sie bald wieder 429.

Was bedeutet 503 Service Unavailable?#

503 besagt, dass der Server die Anfrage gerade nicht bearbeiten kann, der Zustand aber vorübergehend ist. Wartungsarbeiten, Überlast oder ein abgestürzter Anwendungsserver dahinter sind typische Ursachen. Laut RFC 9110 kann der Server mit Retry-After angeben, wann erneut versucht werden soll.

Beim Scraping hat 503 zwei Gesichter:

• Echte Last oder Wartung. Die Website liefert allen 503. Außer Warten ist nichts zu tun.
• Eine vorübergehende Sperre durch Bot-Schutz. Manche Schutzsysteme liefern verdächtigem Verkehr 503 zusammen mit einer Prüfseite. Enthält der Body einen Prüfbildschirm, liegt das Problem nicht an der Serverlast, sondern an Ihrem Verkehr selbst.

Was zu tun ist: Unterscheiden Sie beide Fälle am Body. Bei echter Last warten Sie mit Retry-After oder exponentiellem Backoff. Sehen Sie eine Prüfseite, überprüfen Sie Geschwindigkeit und Client-Identität, statt zu wiederholen. Warum solche Bildschirme bei der Browserautomatisierung erscheinen, erklären wir in Puppeteer und CAPTCHA.

502, 504 und Verbindungsfehler#

Ein Scraper mit Proxy erhält neben Antworten der Zielseite auch Fehler vom Proxy selbst. Diese Codes helfen herauszufinden, an welchem Glied der Kette das Problem liegt.

• 500 Internal Server Error: In der Zielanwendung ist ein Fehler aufgetreten. Manchmal betrifft er nur eine Seite. Ein- bis zweimal wiederholen; tritt er dauerhaft auf, die Adresse überspringen.
• 502 Bad Gateway: Ein Zwischengateway (Proxy, CDN oder Reverse-Proxy) hat vom Server dahinter keine gültige Antwort erhalten. Im Proxy-Kontext kann das bedeuten, dass der Proxy das Ziel nicht erreicht hat. Nach kurzer Wartezeit wiederholen.
• 504 Gateway Timeout: Das Gateway hat vom Server dahinter nicht rechtzeitig eine Antwort erhalten. Tritt auf, wenn das Ziel langsam ist oder der Ausgangspunkt des Proxys weit entfernt liegt. Wiederholen.
• 408 Request Timeout: Der Server hat beim Warten auf den Abschluss der Anfrage ein Timeout erreicht. Wiederholen.
• Verbindungsfehler: Es gibt keinen Code; der Client wirft eine Ausnahme. Verbindung abgelehnt (ECONNREFUSED), Verbindung zurückgesetzt (ECONNRESET), Timeout, Host nicht gefunden (ENOTFOUND) usw. Sind Adresse oder Port falsch, hilft keine Wiederholung; bei vorübergehenden Störungen wie einem Netzabbruch schon.
• CDN-spezifische Codes: Manche CDNs nutzen nicht standardisierte Codes im Bereich 520-526. Sie beschreiben meist Verbindungsprobleme zwischen dem CDN und dem eigentlichen Server der Website.

404 Not Found und 410 Gone besagen, dass die Seite nicht existiert. Statt zu wiederholen, entfernen Sie die Adresse aus Ihrer Liste; sehen Sie plötzlich viele 404, hat sich womöglich die URL-Struktur der Website geändert.

Wie nutzen Sie Retry-After?#

Der Header Retry-After kann in zwei Formen kommen:

• Anzahl Sekunden: Retry-After: 120 → 120 Sekunden warten.
• HTTP-Datum: Retry-After: Wed, 16 Sep 2026 07:28:00 GMT → nach diesem Zeitpunkt erneut versuchen.

Vier Regeln für den richtigen Umgang:

1. Ist der Header da, raten Sie nicht, sondern folgen Sie ihm. Die Zeit vom Server ist genauer als jeder selbst berechnete Backoff.
2. Setzen Sie eine Obergrenze. Nennt der Header etwas Langes, etwa mehrere Stunden, verschieben Sie die Adresse auf einen späteren Lauf, statt Ihr Skript so lange hängen zu lassen.
3. Wenden Sie die Wartezeit auf die Website an, nicht nur auf die Anfrage. Senden Sie parallel weitere Anfragen an dieselbe Website, während Sie die 429-Anfrage zurückhalten, wird das Limit weiter überschritten.
4. Werten Sie auch die Datumsform aus. Code, der nur eine Zahl erwartet, ignoriert einen Header in Datumsform. Eine Python-Funktion, die beide Formen verarbeitet, haben wir in Web Scraping ohne Sperren veröffentlicht.

Bei welchen Codes wiederholen, bei welchen anhalten?#

Beispiel: Wiederholungen, die nach Statuscode entscheiden#

Das folgende Beispiel nutzt den asynchronen Client von HTTPX. Bei 408, 429 und 5xx beachtet es den Header Retry-After; fehlt er, nutzt es exponentiellen Backoff mit Zufallskomponente. Bei Codes, bei denen Wiederholen das Ergebnis nicht ändert, etwa 403, 404 und 407, hält es mit einer eigenen Ausnahme an. Auch Fehler bei der Proxy-Authentifizierung (bei HTTPS-Anfragen als ProxyError) gehören zu dieser Gruppe.

import asyncio
import random

import httpx

RETRY_STATUS = {408, 429, 500, 502, 503, 504}
STOP_STATUS = {400, 401, 403, 404, 407, 410}


class StopScraping(Exception):
    """Fälle, in denen Wiederholen das Ergebnis nicht ändert."""


def backoff(response, attempt, base=1.0, cap=60.0):
    retry_after = response.headers.get("Retry-After") if response is not None else None
    if retry_after and retry_after.isdigit():
        return min(int(retry_after), cap)
    return min(cap, base * 2**attempt) * random.uniform(0.5, 1.0)


async def fetch(client, url, attempts=5):
    for attempt in range(attempts):
        response = None
        try:
            response = await client.get(url)
        except httpx.ProxyError as exc:
            raise StopScraping(f"Proxy-Fehler (Zugangsdaten prüfen): {exc}") from exc
        except httpx.TransportError:
            pass  # Verbindungsabbruch, Timeout: kann wiederholt werden
        else:
            status = response.status_code
            if status < 400:
                return response
            if status in STOP_STATUS:
                raise StopScraping(f"{url}: HTTP {status}, keine Wiederholung")
            if status not in RETRY_STATUS:
                return response
        await asyncio.sleep(backoff(response, attempt))
    raise RuntimeError(f"{url}: nach {attempts} Versuchen kein Ergebnis")


async def main():
    proxy = "http://user:pass@pr.proxynet.io:8000"
    async with httpx.AsyncClient(proxy=proxy, timeout=20, follow_redirects=True) as client:
        urls = ["https://example.com/product/1", "https://example.com/product/2"]
        results = await asyncio.gather(*(fetch(client, u) for u in urls), return_exceptions=True)
        for url, result in zip(urls, results):
            print(url, result if isinstance(result, Exception) else result.status_code)


asyncio.run(main())

Erweitern Sie das Beispiel für Ihre Aufgabe an zwei Stellen. Erstens startet asyncio.gather alle Adressen gleichzeitig; begrenzen Sie in einer echten Aufgabe die Zahl gleichzeitiger Anfragen an dieselbe Website mit asyncio.Semaphore. Zweitens kann Retry-After auch als HTTP-Datum kommen; brauchen Sie auch diese Form, nutzen Sie die oben verlinkte Funktion. Die Unterschiede zwischen HTTPX und anderen Python-Bibliotheken finden Sie in HTTPX, Requests und AIOHTTP im Vergleich.

Fehler protokollieren und überwachen#

Nutzen Sie Statuscodes nicht nur für Entscheidungen im Moment, sondern auch zur Überwachung der Aufgabe. Diese Zahlen bei jedem Lauf zu erfassen, hilft, Probleme früh zu erkennen:

• Antworten nach Code: Steigt die 429-Rate, sind Sie zu schnell; steigt die 403-Rate, hat sich bei IP oder Headern etwas geändert.
• Verteilung nach Website und Endpunkt: Liegt das Problem bei einer Website oder bei allen? Steigen Fehler auf allen Websites gleichzeitig, deutet das meist auf Proxy oder Netz hin.
• Anzahl der Wiederholungen und Gesamtwartezeit: Nehmen Wiederholungen einen großen Teil der Laufzeit ein, ist die Nebenläufigkeit falsch eingestellt.
• 200-Antworten ohne erwartetes Element: das einzige Anzeichen stillen Datenverlusts.

Anwendungsfälle#

• Tägliche Preisbeobachtung: Produkte mit 404 werden aus der Liste entfernt, und für Websites mit 429 wird die Nebenläufigkeit beim nächsten Lauf gesenkt. Den allgemeinen Aufbau beschreibt unsere Seite zur Datenerfassung.
• Katalogerfassung von vielen Websites: Eine steigende 403-Rate bei einer Website erfordert eine eigene Diagnose für diese Website; zur Lastverteilung wird ein Rotierender Proxy genutzt.
• Ihr eigenes Panel mit Sitzung: Eine 302-Weiterleitung zur Anmeldeseite kann zeigen, dass sich die IP mitten in der Sitzung geändert hat; für dieselbe IP während der Sitzung wird ein Sticky-Proxy bevorzugt.
• Ein neuer Proxy-Aufbau: Liefern die ersten Anfragen 407 oder ProxyError, liegt das Problem nicht beim Ziel, sondern bei den Zugangsdaten.

Häufige Fehler#

• Bei jedem Fehler gleich oft wiederholen. 403 und 407 zu wiederholen, ändert das Ergebnis nicht, sondern erzeugt nur unnötigen Verkehr.
• Den Header Retry-After nicht lesen. Früher zurückkommen als vom Server angegeben.
• Beim Backoff keine Zufallskomponente nutzen. Hunderte gleichzeitig fehlgeschlagene Anfragen werden gleichzeitig wiederholt und erzeugen einen neuen Stau.
• Eine 200-Antwort ohne Blick auf den Inhalt akzeptieren. Prüfseiten erzeugen stillschweigend leere Daten.
• 407 für einen Fehler der Zielseite halten. Prüfen Sie die Proxy-Konfiguration, nicht das Ziel.
• Keine Obergrenze für Wiederholungen setzen. Eine Schleife, die bei einem dauerhaften Problem endlos läuft, erschöpft Ihre Ressourcen ebenso wie die Zielseite.

Entscheidungshilfe#

Häufig gestellte Fragen#

Was ist der Unterschied zwischen 403 und 401?#

401 Unauthorized besagt, dass die Anfrage eine Authentifizierung verlangt und Sie keine gültigen Zugangsdaten gesendet haben. 403 Forbidden besagt, dass der Server die Anfrage verstanden hat, sie aber unabhängig von Zugangsdaten ablehnt. Bei 401 kann das Hinzufügen von Zugangsdaten die Lösung sein, bei 403 meist nicht.

Warum kommt ein 407-Fehler vom Proxy und nicht von der Zielseite?#

Weil die Anfrage das Ziel nie erreicht hat. Der Proxy authentifiziert Sie, bevor er die Verbindung weiterleitet, und antwortet selbst, wenn die Authentifizierung fehlschlägt. Deshalb hat 407 nichts mit den Regeln der Zielseite zu tun.

Ist ein IP-Wechsel nach 429 eine Lösung?#

Wird das Rate-Limit pro IP gezählt, kann er vorübergehend helfen, ändert aber nichts an der Geschwindigkeit, die das Problem verursacht hat, und hilft gar nicht, wenn das Limit pro Sitzung oder Konto gilt. Die richtige Reaktion ist Warten und Verlangsamen; Rotation sollte von Anfang an zur Lastverteilung geplant werden.

Wie lange warte ich ohne Retry-After-Header?#

Nutzen Sie exponentiellen Backoff: Beginnen Sie mit einigen Sekunden, verdoppeln Sie bei jedem Versuch, setzen Sie eine Obergrenze und fügen Sie jeder Wartezeit eine Zufallskomponente hinzu. Scheitert es nach einigen Versuchen weiterhin, verschieben Sie die Adresse auf einen späteren Lauf.

Bedeutet ein 503-Fehler, dass die Website ausgefallen ist?#

Nicht immer. Es kann auch Wartung, vorübergehende Last oder eine Sperre durch Bot-Schutz sein. Sehen Sie sich den Body der Antwort an: Ist es eine Wartungsmeldung, eine allgemeine Fehlerseite oder ein Prüfbildschirm?

Mit Proxy erhalte ich 502-Fehler. Wo liegt das Problem?#

502 besagt, dass das Zwischengateway vom Server dahinter keine gültige Antwort erhalten hat. Im Proxy-Kontext kann das heißen, dass der Proxy das Ziel nicht erreicht oder das Ziel die Verbindung beendet hat. Testen Sie dieselbe Adresse ohne Proxy: Funktioniert sie ohne Proxy, liegt das Problem am Ausgangspunkt des Proxys; funktioniert sie auch ohne Proxy nicht, liegt es bei der Zielseite.

Fazit#

HTTP-Statuscodes sagen Ihrem Scraper, was zu tun ist: 429 und 503 verlangen Warten, 403 eine Diagnose, 407 eine korrigierte Proxy-Konfiguration und 404 das Entfernen der Adresse. Gibt es einen Retry-After-Header, folgen Sie ihm; wenn nicht, nutzen Sie exponentiellen Backoff mit Zufallskomponente und begrenzen jede Wiederholungsschleife. Vergessen Sie nicht, auch den Inhalt von 200-Antworten zu prüfen. Proxy-Typen für Ihre Datenerfassung finden Sie in unseren Proxy-Diensten.