Proxyprobleme fühlen sich vielfältig an, wenn man mittendrin steckt, sind aber tatsächlich ziemlich repetitiv. Fast alles, was schiefgeht, fällt in neun Muster, und in den meisten Fällen verrät die Antwort selbst, um welches es sich handelt. Dies ist der Index: Finden Sie Ihr Symptom, erhalten Sie die wahrscheinliche Ursache und die sofortige Abhilfe, und folgen Sie dem Link, wenn Sie die längere Version brauchen.
Die Schnellübersicht
| Symptom | Bedeutet meist | Erster Schritt | Erneut versuchen? |
|---|---|---|---|
407 Proxy Authentication Required | Falsche Zugangsdaten oder ein fehlerhaftes Flag im Benutzernamen | Den nackten Benutzernamen ohne Flags testen | Nie |
502 Bad Gateway | Zu diesem Zeitpunkt passte keine Adresse zu Ihrem Filter | Filter erweitern | Erst nach Erweiterung |
509 Bandwidth Limit Exceeded | Plankontingent ausgeschöpft, Überschreitung deaktiviert | Guthaben und Plan prüfen | Nein |
| Verbindung verweigert oder Hänger | Sie haben das Gateway nie erreicht | nc -vz p.shifter.io 443 | Nein, zuerst Konnektivität beheben |
| Timeouts | Langsamkeit des Ziels, zu enger Filter oder eigene Nebenläufigkeit | Verbindungszeit von Lesezeit trennen | Ja, mit Backoff |
403 oder eine Challenge-Seite | Das Ziel hat die Identität abgelehnt, nicht der Proxy | Sitzung stilllegen, Header prüfen | Nicht in derselben Sitzung |
429 Too Many Requests | Das Ziel begrenzt Ihre Anfragerate | Retry-After beachten, dann verlangsamen | Ja, nach Wartezeit |
200 mit falschem oder leerem Inhalt | Ein weicher Block oder die falsche Locale | Body validieren, Geo-Signale prüfen | Nicht, bevor die Ursache behoben ist |
| Bei jeder Anfrage dieselbe IP | Fast immer Verbindungswiederverwendung im eigenen Client | Mit separaten Prozessen testen | Nicht zutreffend |
407: Authentifizierung abgelehnt
Das Gateway hat Ihre Zugangsdaten abgelehnt, was bedeutet, dass Ihr Traffic es erreicht hat und die Konnektivität in Ordnung ist.
Drei Ursachen machen fast alle Fälle aus: ein Tippfehler in den Zugangsdaten, ein fehlerhaftes Flag im erweiterten Benutzernamen, oder ein Passwort, das im Panel rotiert wurde, während irgendwo noch eine alte Kopie im Einsatz ist. Die mittlere Ursache ist am wenigsten offensichtlich, denn ein nicht erkannter Wert wie country-uk statt country-gb macht den gesamten Benutzernamen nicht parsbar, sodass er als Authentifizierungsfehler statt als Targeting-Fehler gemeldet wird.
Die Diagnose ist immer dieselbe: Entfernen Sie alle Flags und testen Sie zuerst den nackten Benutzernamen. Gelingt das, liegt der Fehler in den Flags, und Sie fügen sie nacheinander wieder hinzu. Schlägt es fehl, kopieren Sie das Passwort erneut aus dem Panel. Ausführliche Details in Behebung von 407- und Zugangsdatenfehlern.
Wiederholen Sie einen 407 niemals. Er ist endgültig, und eine Wiederholungsschleife dagegen verbrennt Bandbreite und wirkt von außen wie Credential Stuffing.
502: nichts passte zu Ihrem Filter
Ihre Zugangsdaten wurden akzeptiert, und dann war keine Adresse für die angeforderte Kombination verfügbar. Das ist ein Targeting-Problem, kein Fehler.
Das tritt meist auf, wenn ein Filter sehr eng ist, eine kleine Stadt, ein bestimmter ASN oder eine Kombination aus beidem, und es ist zu Zeiten wahrscheinlicher, in denen der lokale Pool dünn ist, da die Verfügbarkeit menschlicher Aktivität folgt. Erweitern Sie den Filter, gehen Sie von Stadt auf Region oder Land zurück, oder entfernen Sie strikte Zuordnung, damit das Gateway auf einen breiteren Pool zurückgreift. Wenn Sie sich absichtlich auf strikte Zuordnung verlassen, funktioniert das System bei diesem Fehler wie beabsichtigt. Hintergrund in Länderverfügbarkeit.
509: keine Bandbreite mehr
Das Plankontingent ist ausgeschöpft und die Überschreitung ist nicht aktiviert, sodass Anfragen gestoppt werden. Mit der Verbindung oder der Konfiguration ist nichts falsch. Zahlen Sie Guthaben ein, um die Überschreitung zu aktivieren, oder warten Sie auf den Zyklusreset, und wenn das regelmäßig passiert, ist der Plan zu klein bemessen, was eine Prognosefrage ist, die in monatliche Bandbreite schätzen behandelt wird.
Verbindung verweigert oder eine Anfrage, die ewig hängt
Sie sprechen überhaupt nicht mit dem Gateway. Zwei übliche Ursachen: Sie zeigen auf einen veralteten portbasierten Host statt auf p.shifter.io:443, oder Ihr eigenes Netzwerk blockiert ausgehenden Traffic auf diesem Port.
Testen Sie die reine Konnektivität, bevor Sie irgendetwas über den Proxy annehmen:
nc -vz p.shifter.io 443Schlägt das fehl, liegt ein Egress- oder Firewall-Problem auf Ihrer Seite vor. Gelingt es, aber Anfragen scheitern weiterhin, befinden Sie sich im oben beschriebenen Authentifizierungspfad.
Timeouts
Die uneindeutigste Klasse, weil mehrere verschiedene Probleme dasselbe Symptom erzeugen. Der nützlichste einzelne Schritt ist, die Verbindungszeit von der Gesamtzeit zu trennen, da sie in entgegengesetzte Richtungen weisen:
curl -o /dev/null -s -w "connect: %{time_connect}s total: %{time_total}s\n" \
-x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.comEine langsame Verbindung deutet auf den Proxy-Pfad oder einen zu engen Filter hin, der die Adressauswahl verlangsamt. Eine schnelle Verbindung mit langsamer Gesamtzeit deutet darauf hin, dass das Ziel langsam ist, was nichts ist, das eine Proxy-Änderung behebt. Prüfen Sie auch, ob Ihre Timeouts einfach auf Datacenter-Latenz abgestimmt sind, denn residential Verbindungen sind legitim langsamer, und ein Zwei-Sekunden-Timeout wird ständig aus Gründen fehlschlagen, die keine Fehler sind. Die vollständige Diagnose finden Sie in warum Anfragen einen Timeout erreichen, und die Optimierungsoptionen in Latenz reduzieren.
403, Captchas und Challenge-Seiten
Diese kommen vom Ziel, nicht vom Proxy, was bedeutet, dass sowohl Authentifizierung als auch Konnektivität funktioniert haben. Das Ziel hat sich die Anfrage angesehen und sie abgelehnt.
Die sofortige Reaktion besteht darin, diese Sitzung stillzulegen und eine neue zu übernehmen, statt mit derselben Identität erneut zu versuchen. Die dauerhafte Reaktion ist herauszufinden, warum, und die Reihenfolge der Wahrscheinlichkeit ist zuerst Tempo, dann Anfrageform, dann Verhalten, dann Adressqualität. Langsamer zu werden behebt mehr davon als alles andere, laut Rate Limiting und Throttling, und wenn das Tempo vertretbar ist, ist der nächste Verdächtige Header und User Agent, die sich gegenseitig widersprechen. Das Wiederherstellungs-Playbook finden Sie in was tun, wenn Ihre IPs gesperrt werden.
429: zu viele Anfragen
Das Ziel begrenzt Ihre Rate. Wie bei einem 403 kommt dies vom Ziel und nicht vom Proxy, also sind Ihre Zugangsdaten und Verbindung in Ordnung. Es bedeutet, dass Anfragen schneller eintreffen, als das Ziel von einem Besucher, einer Sitzung oder einem Netzwerk akzeptiert.
Verlangsamen Sie, statt sofort erneut zu versuchen. Wenn die Antwort einen Retry-After-Header enthält, warten Sie mindestens so lange, bevor Sie die nächste Anfrage an dieses Ziel senden. Wenn nicht, verwenden Sie exponentielles Backoff, senken Sie die Nebenläufigkeit für dieses Ziel und verteilen Sie Anfragen auf mehr Sitzungen, statt mehr über eine zu schicken. Einen 429 im gleichen Tempo erneut zu versuchen, macht aus einer vorübergehenden Begrenzung eine Blockierung. Die Methode zur Taktung finden Sie im Leitfaden zur Ratenbegrenzung, der oben im Abschnitt zu 403 verlinkt ist.
Ein 200, der nicht das ist, was Sie wollten
Der teuerste Fehler, weil nichts falsch aussieht. Eine Challenge-Seite, ein leeres Ergebnisset, eine abgeschnittene Liste oder eine generische regionale Seite können alle mit einem Erfolgsstatus ankommen, und eine Pipeline, die Statuscodes zählt, wird sie als Daten erfassen.
Wenn der Inhalt falsch statt fehlend ist, verdächtigen Sie zuerst die Geografie: ein Accept-Language-Header, der Ihrem Exit-Land widerspricht, oder ein DNS-Leak, der Hostnamen von Ihrem Standort statt vom Standort des Proxys auflöst, produzieren beide plausiblen Inhalt für den falschen Markt. Siehe Geo, Zeitzone und Locale abgleichen und DNS-Leaks verhindern.
Wenn der Inhalt eine Challenge oder ein Stub ist, behandeln Sie es als Block, laut blockierte oder gefälschte Inhalte erkennen. So oder so lautet die Lektion: Validieren Sie den Body, bevor Sie eine Antwort als Erfolg zählen, sonst bedeutet Ihr Monitoring nichts.
Dieselbe Adresse bei jeder Anfrage
Die Rotation scheint kaputt zu sein und ist es fast nie. Die übliche Ursache ist, dass Ihr HTTP-Client eine Verbindung wiederverwendet und die Exit-Adresse beim Verbindungsaufbau gewählt wird, nicht pro über sie gesendeter Anfrage.
Testen Sie zuerst mit separaten Prozessen:
for i in 1 2 3; do
curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 http://ip-info.com/json | head -c 60; echo
doneWenn das rotiert und Ihre Anwendung nicht, liegt die Ursache im Connection Pooling Ihres Clients. Wenn keines von beiden rotiert, prüfen Sie auf ein sid-Flag im Benutzernamen, das eine sitzungsgebundene Verbindung anfordert, und bestätigen Sie, dass die angezeigte Adresse nicht einfach Ihre eigene ist, was bedeuten würde, dass der Proxy gar nicht angewendet wird. Vollständige Ursachen in IP rotiert nicht.
Im Browser: ERR_PROXY_CONNECTION_FAILED und ERR_TUNNEL_CONNECTION_FAILED
Browser verstecken den Statuscode des Proxys oft hinter eigenen Fehlerbezeichnungen. Zwei davon decken die meisten Fälle ab.
ERR_PROXY_CONNECTION_FAILEDbedeutet, dass der Browser den Proxy überhaupt nicht erreichen konnte. Behandeln Sie es wie die verweigerte Verbindung oben: prüfen Sie, ob der Hostp.shifter.iound der Port443ist, und prüfen Sie dann, ob Ihr Netzwerk, Ihre Firewall oder Ihr Antivirenprogramm die Verbindung blockiert.ERR_TUNNEL_CONNECTION_FAILEDbedeutet, dass der Browser den Proxy erreicht hat, der Proxy aber den Tunnel zum Ziel nicht geöffnet hat. Das ist meist ein 407 (Zugangsdaten oder ein fehlerhaftes Flag) oder ein 502 (nichts passte zu Ihrem Filter), testen Sie also zuerst den nackten Benutzernamen, wie im Abschnitt zu 407.
TLS- und Zertifikatsfehler
Seltener und meist umgebungsbedingt. Eine veraltete TLS-Bibliothek, die die Cipher-Suite des Gateways ablehnt, oder eine Unternehmens-Middlebox, die die Vertrauenskette bricht. Aktualisieren Sie zuerst die Client-Bibliothek. Die Deaktivierung der Zertifikatsprüfung lässt den Fehler verschwinden und sollte nur zur Bestätigung der Diagnose verwendet werden, niemals in etwas, das Sie ausliefern.
Eine allgemeine Reihenfolge der Vorgehensweise
Wenn etwas kaputtgeht und Sie nicht wissen, wo Sie anfangen sollen: bestätigen Sie die reine Konnektivität, testen Sie dann nackte Zugangsdaten ohne Flags, fügen Sie dann Flags nacheinander wieder hinzu, und prüfen Sie dann, ob die Antwort wirklich das ist, was Sie angefordert haben, statt dem Statuscode zu vertrauen. Diese Reihenfolge isoliert die Ebene in ein paar Minuten, und es ist dieselbe Reihenfolge, egal ob das Symptom ein Fehlercode ist oder Daten, die subtil falsch aussehen.
Für alles Fortlaufende statt Akute finden Sie die Instrumentierung, die diese Probleme abfängt, bevor Sie sie manuell bemerken, in Proxy-Gesundheit im großen Maßstab überwachen.
Häufig gestellte Fragen
Welche Proxy-Fehler sollte ich erneut versuchen?
Versuchen Sie Timeouts mit Backoff erneut, und 429er, nachdem Sie auf Retry-After gewartet haben. Versuchen Sie einen 407 nie erneut: Es handelt sich um ein Problem mit Zugangsdaten oder Flags, und ein erneuter Versuch verbraucht nur Bandbreite. Erweitern Sie den Filter, bevor Sie einen 502 erneut versuchen, und nehmen Sie eine neue Sitzung, statt einen 403 in derselben erneut zu versuchen.
Was bedeutet 502 Bad Gateway bei einem Residential-Proxy?
Ihre Zugangsdaten wurden akzeptiert, aber zu diesem Zeitpunkt passte keine Adresse zu Ihrem Filter, meist weil eine Stadt, ein ASN oder eine Kombination sehr eng gefasst ist. Erweitern Sie den Filter, gehen Sie von Stadt auf Region oder Land zurück, und versuchen Sie es erneut.
Warum liefert mein Proxy einen 200, aber den falschen Inhalt?
Entweder handelt es sich um einen weichen Block, etwa eine Challenge-Seite oder ein leeres Ergebnis, das mit einem Erfolgsstatus ankommt, oder die Locale ist falsch, weil ein Accept-Language-Header oder ein DNS-Leak Ihrem Exit-Land widerspricht. Validieren Sie den Body, bevor Sie eine Antwort als Erfolg zählen.
Warum verwendet mein Residential-Proxy bei jeder Anfrage dieselbe IP?
Fast immer, weil Ihr HTTP-Client eine Verbindung wiederverwendet, und die Exit-Adresse beim Verbindungsaufbau gewählt wird. Testen Sie mit separaten Prozessen. Wenn sich diese rotiert und Ihre Anwendung nicht, liegt die Ursache im Connection Pooling Ihres Clients; wenn sich keine von beiden rotiert, prüfen Sie auf ein sid-Flag im Benutzernamen, das eine sitzungsgebundene Verbindung anfordert.
Fazit
Neun Muster decken fast alles ab. 407 sind Zugangsdaten oder ein fehlerhaftes Flag und niemals eine Wiederholung wert. 502 ist ein leerer Filter, kein Fehler. 509 ist Bandbreite. Verbindung verweigert bedeutet, dass Sie das Gateway nie erreicht haben. Bei Timeouts muss zuerst die Verbindungszeit von der Gesamtzeit getrennt werden, bevor irgendetwas anderes unternommen wird. Ein 403 oder eine Challenge ist das Ziel, das Sie ablehnt, also wechseln Sie die Identität und finden Sie dann heraus, warum. Ein 429 bittet Sie, das Ziel zu verlangsamen, also beachten Sie Retry-After und reduzieren Sie das Tempo. Ein 200 mit falschem Inhalt ist der gefährliche Fall und der Grund, warum Body-Validierung nicht optional ist. Und dieselbe Adresse bei jeder Anfrage ist fast immer Verbindungswiederverwendung im eigenen Client. Arbeiten Sie von der Konnektivität nach außen, und prüfen Sie, was tatsächlich zurückkam, statt dem, was der Statuscode behauptet.
Das Gateway selbst ist dokumentiert in wie man sich verbindet, das Vokabular im Glossar, und das Produkt sind Residential Proxies mit Preisen pro GB.