Was zu tun ist, wenn Ihre Residential-Proxy-IPs gesperrt werden

Die Erfolgsquote bei einem Ziel sinkt, Challenge-Seiten tauchen auf, und der naheliegende erste Gedanke ist, dass die eigenen IPs gesperrt wurden. Manchmal stimmt das genau. Oft stimmt es nicht, und der Unterschied ist entscheidend, denn die Reaktionen sind gegensätzlich: Die eine verlangt einen Adresswechsel, die andere verlangt, langsamer zu werden und sonst nichts zu ändern.

Dazu kommt der strukturelle Punkt, der das ganze Problem neu rahmt. Bei einem rotierenden residentiellen Pool besitzt man die Adressen nicht, es gibt also keine Adresse zu rehabilitieren. Erholung bedeutet, dass die nächste Anfrage akzeptiert wird, und der einzig dauerhafte Weg dorthin ist herauszufinden, was die letzte abgelehnt hat.

Zuerst bestätigen, dass es sich wirklich um eine Sperre handelt

Vier Dinge sehen von außen ähnlich aus und bedeuten unterschiedliche Dinge.

Ein Rate-Limit ist vorübergehend und betrifft das Tempo. Es kündigt sich meist mit einem 429 an, manchmal mit einem Retry-After, und löst sich von selbst, wenn man langsamer wird. Darauf mit einem Adresswechsel zu reagieren ist der klassische Fehler, denn das gleiche Tempo von frischen Adressen aus beizubehalten ist genau das Muster, das aus Drosselung etwas Dauerhaftes macht.

Eine Sperre (Block) ist eine Ablehnung, die auf die Adresse oder die Session zielt: eine Challenge-Seite, ein anhaltender 403, eine Zwischenseite. Das ist der Fall, in dem eine frische Identität tatsächlich hilft.

Ein Soft Block ist der gefährliche Fall, weil er einen 200 zurückgibt. Eine Challenge-Seite, ein generisches Ergebnis, eine abgeschnittene Auflistung oder eine Weiterleitung auf eine Landingpage können sich alle wie Daten parsen lassen, und eine Pipeline, die nur Statuscodes zählt, meldet Gesundheit, während sie nichts sammelt. Wenn man die Antwortinhalte nicht validiert, kann man das gar nicht von Erfolg unterscheiden, siehe detecting blocked or fake content.

Der eigene Fehler lohnt sich früh auszuschließen. Ein fehlerhaftes Username-Flag liefert 407, ein zu eng gefasster Filter liefert 502, und eine Parser-Änderung kann gute Seiten leer erscheinen lassen. Nichts davon ist eine Sperre.

Der schnelle Test: dieselbe URL über eine völlig andere Route anfragen, idealerweise ein anderes Land, und über eine einfache Verbindung. Schlägt alles fehl, hat das Ziel Probleme oder die Anfrageform ist falsch. Schlägt nur die Produktionsroute fehl, liegt ein echtes Identitätsproblem vor.

Dann den Umfang bestimmen

Die Größe des Problems verrät, wie tief die Ursache liegt.

Eine einzelne fehlschlagende Session, während andere erfolgreich sind, ist Routine. Diese Session aussortieren, eine frische Kennung nehmen und weitermachen. Bei einem rotierenden Pool geschieht das laufend und braucht keinen Eingriff über die automatische Aussortierung hinaus, die in building a proxy manager beschrieben wird.

Eine einzelne degradierende Route, also eine Kombination aus Ziel und Land, deren Erfolgsquote gesunken ist, während andere Routen stabil bleiben, deutet auf etwas hin, das mit der Art zusammenhängt, wie dieses Ziel angesprochen wird. Das ist der häufige und interessante Fall, und der Rest dieses Textes behandelt genau ihn.

Jede Route zu einem Ziel schlägt fehl, das bedeutet, das Ziel hat seine Abwehr geändert oder hat einen Vorfall, und keine Menge an Rotation hilft, bis man ändert, wie man hinschaut, nicht woher man kommt.

Jedes Ziel schlägt gleichzeitig fehl, das ist fast nie eine Sperre. Vor allem anderen die eigene Bereitstellung, die Zugangsdaten und das eigene Netzwerk prüfen.

Die Gesundheit auf Routenebene ist es, was diese Diagnose schnell statt spekulativ macht, das ist das Argument in monitoring proxy health at scale.

Die unmittelbare Reaktion

Wenn eine Route tatsächlich gesperrt ist, lautet der Instinkt, stärker zu drängen. Das Gegenteil ist richtig.

Mit dieser Route aufhören. Weiter auf ein Ziel einzuschlagen, das einen ablehnt, vertieft das Problem, verschwendet Bandbreite auf Antworten, die man nicht nutzen kann, und verbreitet den Schaden, da jede neue berührte Adresse ebenfalls markiert wird. Ein Circuit Breaker sollte das automatisch erledigen, statt auf einen Menschen zu warten.

Nicht aggressiv erneut versuchen. Ein Retry-Sturm gegen ein blockierendes Ziel ist der schnellste Weg, aus einem engen Problem ein breites zu machen, weshalb Retries Budgets und Klassifizierung brauchen statt einer Schleife, siehe retry and backoff.

Warten. Die meisten Sperren sind zeitlich begrenzt. Eine Abkühlphase von einigen zehn Minuten bis wenigen Stunden löst den Zustand häufig vollständig auf, und ein Wiederaufnehmen mitten in der Abkühlphase setzt die Uhr zurück.

Identität ändern, nicht nur Adresse. Wenn die Sperre durch das Auftreten verursacht wurde und nicht durch die Herkunft, ändert eine neue Adresse allein nichts Wesentliches.

Die tatsächliche Ursache finden

Sperren entstehen aus vier Bereichen, und es lohnt sich, sie in dieser Reihenfolge zu prüfen, da dies ungefähr ihrer Häufigkeit entspricht.

Tempo. Zu viele Anfragen, zu regelmäßig, von zu wenigen Adressen. Perfekt gleichmäßiger Abstand ist selbst schon ein Signal, da menschlicher Traffic stoßweise und unregelmäßig ist. Die Lösung ist eine niedrigere Rate pro Adresse, Jitter und breitere Verteilung, siehe rate limiting and throttling und die Verteilungsmathematik in how many proxy IPs you actually need.

Anfrageform. Header, die nicht zum vorgegebenen Browser passen, fehlende Client Hints, ein Accept-Language, das dem Ausgangsland widerspricht, oder ein TLS-Fingerabdruck, der Python verrät, während der User-Agent Chrome behauptet. Das sind Widersprüche und keine Auslassungen, und sie sind leicht zu erkennen, siehe setting the right headers und matching geo, timezone and locale.

Verhalten. Endpunkte in einer Reihenfolge ansteuern, die kein Mensch wählen würde, nie etwas laden, was ein Browser laden würde, Identität mitten im Ablauf wechseln oder eine Paginierungsfolge mit Maschinengeschwindigkeit durchlaufen. Abläufe, die nur für ein Skript Sinn ergeben, werden tendenziell als Skript erkannt.

Adressqualität. Manchmal liegt es tatsächlich am Pool: Adressen mit schlechter Reputation ziehen Challenges an, unabhängig vom eigenen Verhalten, und ein angeblich residentieller Pool, der mit Datacenter-Raum verdünnt ist, verhält sich genau wie Datacenter-Raum, siehe spotting datacenter IPs sold as residential.

Wenn eine Route gesperrt ist und sowohl Tempo als auch Anfrageform vertretbar sind, ist das der Moment, in dem Adressqualität zur führenden Hypothese wird statt zur ersten Annahme.

Ohne Wiederholung zurückkehren

Schlecht zurückzukehren ist der Weg, wie aus einer aufgelösten Sperre eine wiederkehrende wird.

Mit einem Kanarienvogel statt dem vollen Job beginnen: eine Handvoll Anfragen über eine frische Session, ordentlich validiert, um zu bestätigen, dass das Ziel wieder akzeptiert. Wenn sie durchgehen, schrittweise hochfahren statt sofort beim vorherigen Tempo weiterzumachen, denn sofort zum Tempo zurückzukehren, das das Problem verursacht hat, ist selbst ein erkennbares Muster. Etwas ändern, bevor man wieder aufnimmt, sei es das Tempo, die Header, die Sessionstrategie oder die Geografie, denn identisch fortzufahren ist eine Wette darauf, dass die Sperre zufällig war. Und die validierte Erfolgsquote beim Hochfahren beobachten, damit man es in den ersten Minuten erfährt statt am nächsten Morgen.

Erweist sich ein Ziel nach alledem als dauerhaft feindselig, sind die ehrlichen Optionen, die Ambition dafür zu reduzieren, anders vorzugehen oder zu akzeptieren, dass es die Kosten nicht wert ist, was die Eskalationslogik in scraping heavily protected sites ist.

Fazit

Zuerst die vier Doppelgänger unterscheiden, denn ein mit Rotation beantwortetes Rate-Limit verschlimmert sich, und ein als Erfolg gezählter Soft Block ist unsichtbar. Den Umfang feststellen, denn eine fehlschlagende Session ist Routine, eine degradierte Route ist eine Ursache, die es zu finden lohnt, und alles gleichzeitig fehlschlagend ist meist die eigene Bereitstellung. Wenn eine Route tatsächlich gesperrt ist, aufhören statt drängen, nicht hineinretryen, eine Abkühlphase abwarten und Identität statt nur Adresse ändern. Dann die Ursache in Reihenfolge der Wahrscheinlichkeit finden: Tempo, Anfrageform, Verhalten und erst dann Poolqualität. Mit einem Kanarienvogel und einem schrittweisen Hochfahren zurückkehren, nachdem etwas geändert wurde, und dabei die validierte Erfolgsquote beobachten. Bei einem rotierenden Pool war die Adresse nie der Wert; der Zugang ist es, und Zugang verdient man sich, indem man gewöhnlich wirkt.

Einen sauberen Ausgangspunkt für die Erholung zu haben ist das, was residential proxies bieten: ein großer Pool echter, heimischer Adressen mit Länder- und Stadt-Targeting, sodass eine aussortierte Session ersetzt statt wiederverwendet wird, mit per-GB pricing, das eine disziplinierte Erholung günstiger macht als eine stur beharrliche.