“Meine Anfragen laufen in Timeouts” ist eine der häufigsten Support-Nachrichten, die wir bekommen, und auch eine der unspezifischsten. Ein Timeout ist ein Symptom, keine Ursache. Derselbe Fehler taucht auf, ob das Gateway keine passende Exit-IP finden konnte, Ihr Client nach 5 Sekunden bei einer Verbindung aufgab, die 8 gebraucht hätte, die Zielseite langsam ist, oder Ihr eigener Container fehlkonfiguriert ist und den Proxy nie erreicht.
Dies ist ein Diagnose-Leitfaden: wie Sie erkennen, welche davon tatsächlich vorliegt, in der Reihenfolge, die es am schnellsten findet. Es ist der Begleiter zu Latenz senken, wo es darum geht, ein funktionierendes Setup schneller zu machen; hier geht es um ein Setup, das hängt oder scheitert, und warum.
Schritt 0: ist es überhaupt ein Timeout?
Klassifizieren Sie vor der Diagnose präzise, denn drei verschiedene Fehler werden als “Timeout” gemeldet und haben unterschiedliche Lösungen:
- Connect-Timeout — Ihr Client konnte überhaupt keine Verbindung zum Gateway aufbauen. Das deutet auf Ihre Seite: Netzwerk-Egress, Firewall, falscher Host/Port, oder Container-Konfiguration.
- Read-/Response-Timeout — Sie haben sich verbunden, die Anfrage ging durch, aber es kam keine Antwort rechtzeitig zurück. Das deutet auf den Exit oder das Ziel: keine passende IP, ein langsames Exit-Gerät, oder eine langsame Zielseite.
- Gar kein Timeout — ein
407(Auth), ein502(keine IP passte zu Ihrem Filter), oder eine hängende CAPTCHA-Seite. Diese werden oft von Wrapper-Code, der alles als eine Exception fängt, als Timeouts gemeldet.
Die meisten Clients lassen Sie Connect- und Read-Timeouts explizit trennen. Das zu tun ist der wertvollste Diagnoseschritt, und meist eine Ein-Zeilen-Änderung:
import requests
# (connect_timeout, read_timeout) - trennen Sie sie, übergeben Sie keine einzelne Zahlr = requests.get(url, proxies=proxies, timeout=(10, 30))Scheitert es in den ersten 10 Sekunden, ist es ein Connect-Problem. Übersteht es den Connect und stirbt bei 30, ist es ein Read-Problem. Lesen Sie beim passenden Abschnitt weiter.
Ursache 1: Ihr Geo-Filter ist zu eng
Das ist die häufigste echte Ursache, und die am leichtesten behobene.
Jedes Targeting-Flag verengt den Pool berechtigter Exit-IPs. country-us wählt aus einer riesigen Menge. country-us-city-scranton-asn-12345 wählt womöglich aus fast nichts. Wenn wenige oder keine Exits passen, warten Anfragen, scheitern dann, und je nach Client taucht das als Timeout oder 502 auf.
Diagnostizieren Sie es, indem Sie ein Flag nach dem anderen lockern:
# Funktioniert es nur mit country?curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30
# Dann die Stadt wieder hinzufügen und vergleichencurl -x customer-USER-country-us-city-chicago:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30Wenn Country-only erfolgreich ist und der engere Filter in ein Timeout läuft, haben Sie es gefunden. Lösung: behalten Sie nur die Präzision, die Ihre Daten wirklich brauchen. Wenn Ihr Anwendungsfall diese Stadt wirklich erfordert, rechnen Sie mit einem kleineren Pool und geringerem Durchsatz, und budgetieren Sie das ein (wann Targeting auf Stadtebene zählt behandelt, wann es die Kosten wert ist).
Ursache 2: Ihr Timeout ist auf Datacenter getrimmt, nicht auf Residential
Ein knapper Zweiter, und er erzeugt “Timeouts” bei Anfragen, die nie kaputt waren.
Residential-Traffic routet über ein echtes Verbrauchergerät in einem Heimnetz, hat also einen Latenz-Boden, den Datacenter-Proxies nicht haben (Residential vs Datacenter). Ein Gesamt-Timeout von 5 Sekunden, völlig vernünftig für Datacenter, schneidet eine gesunde Residential-Anfrage mitten im Flug ab und meldet sie als Fehler.
Diagnostizieren Sie es, indem Sie vor dem Tunen messen: erheben Sie p50- und p95-Latenz für Ihr tatsächliches Ziel über den Proxy (wie man Proxy-Geschwindigkeit, Erfolgsrate und Standortgenauigkeit testet hat die Methode). Liegt Ihr Timeout unter Ihrem p95, produzieren Sie die Fehler selbst.
Lösung: setzen Sie das Timeout mit Spielraum über Ihr gemessenes p95, nicht nach Gefühl. Als Ausgangspunkt sind rund 10s Connect-Timeout und 30s oder mehr Read-Timeout für Residential vernünftig; danach straffen Sie nach Ihren eigenen Zahlen.
Ursache 3: das Ziel ist langsam, nicht der Proxy
Leicht zu bestätigen, leicht falsch zu machen. Timen Sie denselben Anfragepfad gegen einen schnellen, neutralen Endpunkt und gegen Ihr echtes Ziel über denselben Proxy:
# Neutraler Endpunkt - misst den Proxy-Overheadrequests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))
# Ihr echtes Ziel - misst Proxy-Overhead + Ziel-Latenzrequests.get("https://your-target.example/page", proxies=proxies, timeout=(10, 30))Ist der neutrale Endpunkt schnell und das Ziel langsam, ist der Proxy nicht Ihr Problem, und kein Maß an Proxy-Tuning wird es beheben. Erhöhen Sie das Read-Timeout für dieses Ziel, oder reduzieren Sie, wie viel der Seite Sie ziehen.
Ursache 4: die Nebenläufigkeit ist zu hoch
Timeouts, die nur unter Last auftreten und bei einer einzelnen Testanfrage verschwinden, deuten hierauf.
Zwei Mechanismen: Sie erschöpfen womöglich lokale Ressourcen (Connection-Pool-Slots, File-Deskriptoren, Event-Loop-Kapazität), sodass Anfragen auf Ihrer eigenen Seite anstehen, bevor sie überhaupt rausgehen; oder das Ziel rate-limitet Sie und hängt, statt ein sauberes 429 zurückzugeben.
Diagnostizieren Sie es, indem Sie die Nebenläufigkeit auf 1 senken und erneut testen. Verschwinden die Timeouts, ist es lastbedingt. Lösung: wenden Sie Nebenläufigkeitslimits pro Host an statt einer globalen Zahl, das ist die Architektur in Proxy-Lastverteilung.
Ursache 5: Verbindungshandhabung
Zwei gegensätzliche Fehler, beide erzeugen Timeouts:
Keine Verbindungs-Wiederverwendung. Pro Anfrage eine frische Verbindung zu erstellen bedeutet, jedes Mal einen vollen TCP- und TLS-Handshake durch den Proxy zu zahlen, was langsam ist und Ihrem Timeout viel weniger Luft lässt. Nutzen Sie eine Session/einen Client mit Pooling.
Veraltete gepoolte Verbindungen. Poolen Sie Verbindungen, rotieren aber Exit-IPs pro Anfrage, können gepoolte Sockets auf nicht mehr gültige Exits zeigen, und die hängen. Paaren Sie Pooling mit einer Sticky Session, damit die gepoolte Verbindung auf einem Exit bleibt, und recyceln Sie Verbindungen periodisch.
Ursache 6: das Exit-Gerät selbst
Residential-Exits sind echte Verbrauchergeräte in echten Heimnetzen. Manche hängen an überlasteten Leitungen, manche sind mobil, manche fallen mitten in der Anfrage weg. Ein kleiner Prozentsatz langsamer oder fehlgeschlagener Anfragen ist bei Residential normal und zu erwarten, kein Defekt.
Lösung: erhöhen Sie Ihr Timeout nicht, um dem schlechtesten Gerät entgegenzukommen, das macht nur jeden Fehler langsamer. Scheitern Sie schnell und wiederholen Sie auf einer neuen Identität, was Ihnen einen anderen Exit verschafft. Der gestrige Failover-Leitfaden behandelt die Klassifizierung von Transportfehlern und korrektes Retryen. Die Poolqualität bestimmt, wie dick dieser Tail ist (IP-Reputation).
Ursache 7: es erreichte den Proxy nie
Früh prüfenswert, wenn alles in Timeouts läuft, besonders in Containern.
Bestätigen Sie, dass die Anfrage tatsächlich über das Gateway hinausgeht:
curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org# Gibt eine Residential-IP zurück -> Proxy funktioniert.# Gibt Ihre eigene IP zurück -> Ihr Client ignoriert den Proxy.# Hängt komplett -> lokaler Egress ist blockiert (Firewall, VPN, Firmennetz).In Docker und Kubernetes ist das eine häufige Ursache: der Client beachtet HTTP_PROXY gar nicht, oder NO_PROXY ist fehlkonfiguriert, oder localhost bedeutet im Container nicht, was Sie denken. Der Docker-Konfigurationsleitfaden behandelt diese Fälle speziell.
Ursache 8: getarnte Auth- oder Credential-Fehler
Ein fehlerhafter Benutzername (ein Tippfehler in einem Targeting-Flag, ein nicht unterstützter Parameter) oder falsche Zugangsdaten können sich je nach Umgang Ihres Clients mit einem 407 als Hänger oder generischer Fehler zeigen. Scheitert Ihre lockerste mögliche Konfiguration weiterhin, verifizieren Sie die Credential-Zeichenfolge Zeichen für Zeichen, bevor Sie ein Netzwerkproblem annehmen.
Die Diagnose-Reihenfolge
Führen Sie diese der Reihe nach aus; jeder Schritt eliminiert eine große Ursachenklasse:
- Trennen Sie Connect von Read. Connect-Fehler heißt Ihre Seite; Read-Fehler heißt Exit oder Ziel.
- Verifizieren Sie, dass Sie überhaupt auf dem Proxy sind (der ipify-Check oben).
- Testen Sie nur mit
country. Funktioniert das, war Ihr Geo-Filter zu eng. - Vergleichen Sie einen neutralen Endpunkt mit Ihrem Ziel. Isoliert Proxy-Overhead von Ziel-Langsamkeit.
- Senken Sie die Nebenläufigkeit auf 1. Verschwinden die Timeouts, ist es Last, nicht der Proxy.
- Prüfen Sie Ihr Timeout gegen Ihr gemessenes p95. Liegt es darunter, erzeugen Sie die Fehler.
Sechs Checks, und in der Praxis erklärt einer davon nahezu jede Timeout-Meldung, die wir sehen.
Wann Timeouts tatsächlich in Ordnung sind
Ein kleiner Tail langsamer und fehlgeschlagener Anfragen ist Residential Proxies inhärent, weil echte Verbrauchergeräte inhärent variabel sind. Eine 100%-Erfolgsrate mit immer längeren Timeouts zu jagen, ist das falsche Ziel, es macht Ihre Fehler langsamer, nicht seltener.
Das richtige Ziel ist ein SLO: definieren Sie eine akzeptable Erfolgsrate und ein p95 für Ihren Workload, scheitern Sie schnell am Tail, und retryen Sie auf einer frischen Identität. Eine Pipeline, die eine Anfrage in 30 Sekunden scheitern lässt und beim Retry Erfolg hat, ist gesünder als eine, die 120 Sekunden hoffend wartet.
FAQ
Warum bekomme ich Timeouts mit einem Stadt- oder ASN-Filter, aber nicht mit Country allein? Weil jedes Flag den berechtigten Exit-Pool verengt. Country + City + ASN kann sehr wenige passende IPs übriglassen, also warten Anfragen und scheitern dann. Lockern Sie auf die Präzision, die Ihre Daten wirklich brauchen, und rechnen Sie mit geringerem Durchsatz, wenn Sie enges Targeting wirklich benötigen.
Welche Timeout-Werte sollte ich für Residential Proxies nutzen? Messen Sie zuerst: Ihr Timeout sollte mit Spielraum über Ihrem beobachteten p95 liegen. Als Ausgangspunkt sind grob 10s Connect und 30s+ Read für Residential vernünftig, dann tunen Sie nach Ihren eigenen Zahlen. Auf Datacenter getrimmte Timeouts schneiden gesunde Residential-Anfragen ab.
Wie erkenne ich, ob der Proxy oder das Ziel langsam ist? Timen Sie einen schnellen neutralen Endpunkt und Ihr echtes Ziel über denselben Proxy. Der neutrale Endpunkt misst den Proxy-Overhead; die Differenz ist die Eigenlatenz des Ziels. Ist der neutrale Endpunkt schnell, ist der Proxy nicht das Problem.
Alles läuft in Timeouts, sogar einfache Anfragen. Was ist falsch? Prüfen Sie, ob Sie den Proxy überhaupt erreichen: curlen Sie einen IP-Echo-Endpunkt darüber. Ihre eigene IP heißt, der Client ignoriert den Proxy; ein Totalhänger heißt, lokaler Egress ist blockiert (Firewall, VPN, Container-Konfiguration). Dann verifizieren Sie Ihre Zugangsdaten und Flags.
Sollte ich einfach mein Timeout erhöhen? Meist nicht. Ist die Ursache ein enger Geo-Filter, ein langsames Ziel oder ein schlechtes Exit-Gerät, macht ein längeres Timeout den Fehler nur langsamer. Beheben Sie die Ursache, und für den unvermeidlichen Tail scheitern Sie schnell und retryen auf einer neuen Identität.
Fazit
Ein Timeout ist ein Symptom mit mindestens acht verschiedenen Ursachen, und die Lösung hängt vollständig davon ab, welche Sie haben. Trennen Sie Connect von Read, bestätigen Sie, dass Sie tatsächlich auf dem Proxy sind, lockern Sie Ihren Geo-Filter, isolieren Sie Ziel-Langsamkeit vom Proxy-Overhead, testen Sie bei Nebenläufigkeit 1, und prüfen Sie Ihr Timeout gegen Ihr gemessenes p95. Diese Sequenz löst die überwiegende Mehrheit der Fälle, meist in Minuten.
Und akzeptieren Sie den Tail: Residential-Exits sind echte Geräte, also ist etwas Variabilität der Preis für Echtnutzer-Vertrauen. Scheitern Sie schnell, retryen Sie auf einer frischen Identität, und beurteilen Sie das Setup nach Erfolgsrate und p95 statt danach, ob je eine Anfrage in ein Timeout läuft. Wenn Sie nach den sechs Checks noch feststecken, können die Docs des Residential-Gateways und unser Team beim Eingrenzen helfen, bringen Sie Ihre Connect/Read-Aufteilung und ein Beispiel der fehlschlagenden Credential-Zeichenfolge mit, und die Antwort ist meist schnell gefunden.