Rotierende Proxys erklärt: So funktioniert IP-Rotation und wann sie deinen Job stört

Ein Preisüberwachungsskript prüfte monatelang jede Nacht einige Hundert Produktseiten problemlos. Dann stieg die Frequenz, ein zweiter Händler kam hinzu und die Logs füllten sich mit 429-Antworten und CAPTCHAs. Der übliche Forenrat: einen rotierenden Proxy verwenden. Mehr IPs bedeuten weniger Sperren, so die Annahme. Sie stimmt nur zur Hälfte.

Ein rotierender Proxy schickt Anfragen hinter einer festen Gateway-Adresse über wechselnde IPs. Das verteilt den Verkehr unter ein pro IP gezähltes Limit. Die Adresse kann aber auch während einer Anmeldung wechseln, was eine angemeldete Sitzung oft nicht übersteht. Rotation löst ein Problem und schafft ein neues.

Die Kurzfassung

• Ein rotierender Proxy bietet eine Gateway-Adresse mit Host und Port, leitet Anfragen über eine IP aus einem Pool weiter und bestimmt deren Wechsel per Rotationsregel.
• Rotation bei jeder Anfrage eignet sich für zustandslose Abrufe öffentlicher Seiten. Für Anmeldungen und Warenkörbe sind Sticky Sessions oder statische Proxys besser, insbesondere bei Prüfung der IP-Kontinuität.
• Ein Pool kann korrekt rotieren und trotzdem scheitern: Andere Kunden verschlechtern den Ruf geteilter IPs. Die Poolgröße sagt wenig über erfolgreiche Anfragen aus; frische und wenig geteilte Adressen sind aussagekräftiger.
• Gegen Limits pro Konto, Token oder Cookie hilft Rotation nicht. Bei geringem Volumen zuerst langsamer werden und den Wartehinweis Retry-After beachten.

Was ist ein rotierender Proxy?

Ein rotierender Proxy leitet Anfragen über IPs aus einem Pool. Die Regel bestimmt den Wechsel: pro Anfrage, nach Zeit oder pro Sitzung. Du verbindest dich immer mit demselben Host und Port; das Gateway wählt die für das Ziel sichtbare Adresse.

Der Weg einer Anfrage durch das Gateway:

1. Der Client sendet die Anfrage immer an denselben Host und Port des Gateways.
2. Das Gateway wendet die Rotationsregel an und wählt eine Ausgangs-IP.
3. Die Anfrage verlässt diese IP und erreicht die Zielwebsite.
4. Das Ziel sieht die Ausgangs-IP als Ursprung. Deine Adresse bleibt verborgen, sofern das Gateway sie nicht über einen Header wie X-Forwarded-For weitergibt.

Pool, Zustandsprüfungen und Ausfallsicherung verwaltet der Anbieter. Dein Skript kennt nur Host und Port; diese Bequemlichkeit macht Rotation zum Dienst. Ein eigener Proxy liefert Rotation jedoch nicht kostenlos: Er bietet normalerweise eine stabile Ausgangs-IP. Für den Betrieb des Pools würdest du einen Anbieter bezahlen.

Anbieter nennen Gateway plus Pool einen Backconnect-Proxy. MDNs Leitfaden zu Proxyservern nennt „Gateway“ als anderen, einfacheren Namen für einen Forward-Proxy. Ob der Pool Residential-, Rechenzentrums- oder Mobilfunkadressen enthält, ist unabhängig von der Wechselhäufigkeit.

Was bestimmt den IP-Wechsel eines rotierenden Proxys?

Die Rotationsregel bestimmt den Wechsel. Anbieter unterstützen neue IPs pro Anfrage oder Verbindung, feste Zeitfenster oder einen ausdrücklichen Wechselbefehl. Client oder Proxyverwaltung können auch vor einem erneuten Versuch rotieren. Prüfe „pro Anfrage“ genau: Mehrere HTTPS-Anfragen können einen Tunnel und damit eine IP teilen. Ein Gateway, das verschlüsseltes HTTPS weiterleitet, kann den Statuscode des Ziels normalerweise nicht selbst lesen und daraufhin rotieren.

Die Tabelle zeigt eine Verteilungsentscheidung. Streuung hält jede Adresse unter dem IP-Limit; Kontinuität lässt das Ziel denselben Besucher erkennen. Rotation pro Anfrage setzt alles auf Streuung. Rotation bei Fehlern wirkt wie ein belastbarer Mittelweg, verbirgt ihre Kosten aber besonders gut: Die Logs zeigen erfolgreiche Wiederholungen, bis nichts mehr gelingt. Eine andere Regel kehrt den Kompromiss um und hält eine IP für ein Zeitfenster: die Sticky Session.

Wie unterscheidet sich eine Sticky Session von Rotation oder einem statischen Proxy?

Eine Sticky Session reserviert vorübergehend eine IP aus dem rotierenden Pool, damit Anfragen wie von einem Besucher erscheinen, und gibt sie danach frei. Ein statischer Proxy hält eine feste IP, solange du ihn behältst. Rotation pro Anfrage reserviert nichts. Entscheidend ist, ob das Ziel dich zwischen Anfragen erkennen muss.

Für zustandslose Abrufe ist Rotation pro Anfrage üblich. Bei Anmeldungen bleiben die beiden haltenden Optionen; die Dauer entscheidet. Eine Sticky Session leiht eine IP aus dem gemeinsamen Pool und gibt sie bei Ablauf zurück. Der statische Proxy bleibt zugewiesen: Tägliche Anmeldungen von derselben Adresse sehen wie ein wiederkehrender Nutzer aus. Anbieter definieren unterschiedliche Zeitfenster; vergleiche sie mit deinem längsten Ablauf. Prüfe auch Ausfälle: Manche wechseln vorzeitig die IP, strikte Einzel-IP-Modi lassen die Anfrage stattdessen scheitern. Ein ausreichend langes Fenster allein garantiert keine Kontinuität.

Wann stört IP-Rotation einen Job?

Wechselt die IP innerhalb eines wiedererkennbaren Ablaufs, können Anmeldung, 2FA, Warenkorb, Checkout oder mehrstufige Formulare scheitern. Ein Sitzungscookie wird nicht grundsätzlich durch den IP-Wechsel ungültig. Websites mit IP-gebundenen Sitzungen oder Betrugsprüfung bei Netzwerkwechseln können aber abmelden, erneut prüfen oder die Sitzung markieren.

Das ist aus meiner Sicht kein gezieltes Vorgehen gegen Proxys, sondern die Aufgabe der Website. Ein Cookie behauptet, derselbe Browser wie bei der Anmeldung vor einer Minute zu sein; die IP liefert überprüfbare Hinweise. Ein Netzwechsel mitten in einer authentifizierten Sitzung ähnelt einem gestohlenen, anderswo wiederverwendeten Cookie. Genau darauf achten Betrugssysteme. Abmeldung und 2FA-Abfrage sind angemessene Reaktionen.

OWASPs Leitfaden zur Sitzungsverwaltung beschreibt die Prüfung veränderter Clientmerkmale wie IP und User-Agent. Je nach Schutzmaßnahmen kann ein unerwarteter Wechsel Alarm auslösen oder die Sitzung beenden.

Die entscheidende Frage: Muss das Ziel dich zwischen zwei Anfragen wiedererkennen? Dann halte die IP für den Ablauf, andernfalls rotiere. Nächtliche Preisprüfungen öffentlicher Seiten benötigen das nicht. Eine Dashboard-Anmeldung zum Berichtsexport braucht dieselbe Ausgangs-IP von Anfang bis Ende.

Praxistipp: Trenne gemischte Lasten: rotierender Pool für zustandslose Datenabrufe, Sticky Session oder statische IP für Anmeldung und angemeldete Arbeit. Die Anforderungen sind gegensätzlich und brauchen getrennte Rotationsregeln.

Warum funktioniert ein rotierender Pool nach einigen Tagen nicht mehr?

Rotation kann korrekt laufen und der Pool dennoch versagen: Sie ändert die verwendete IP, nicht deren Ruf. Geteilte Adressen erben frühere Aktivitäten; starke Wiederverwendung bei denselben Zielen kann Markierungen und sinkende Erfolgsquoten verursachen.

Ein gemeinsamer Pool ähnelt einer begrenzten Allmende. Sein Ruf bei Websites ist der Vorrat, den jeder Kunde beansprucht. Verwenden andere dieselben Adressen bei deinen Zielen, bezahlst du mit CAPTCHAs und Sperren. Im Support habe ich IP-Reputation als Ökosystem aus Websites und Sperrlisten erlebt, die jeweils auf beobachtete Aktivitäten reagieren.

Die leicht beworbene Poolgröße sagt deshalb weniger voraus als erwartet. Ob eine IP durchkommt, hängt ab von:

• Letzter Nutzung beim selben Ziel. Eine vor einer Stunde von einem anderen Kunden verwendete Adresse ist dort bereits gezählt.
• Anzahl der mitnutzenden Kunden. Je mehr Jobs eine Adresse teilen, desto schneller verschleißt sie.
• Netzwerkvielfalt. In wenigen Bereichen gebündelte Adressen können gemeinsam per Bereichsregel gesperrt werden.
• Vorhandenen Markierungen. Bereits als missbräuchlich erkannte Adressen werden von einem Pool, der sie behält, weiter normal verteilt.

Ein großer, stark wiederverwendeter Pool kann schlechter abschneiden als ein kleiner, dessen IPs bei deinen Zielen frisch sind. Vergleiche Erfolgsquoten dort über längere Zeit. Ein guter erster Test beweist keine dauerhafte Leistung.

Brauchst du überhaupt einen rotierenden Proxy?

Ein rotierender Proxy kann Anfragen unter einem IP-Limit verteilen, ersetzt aber nicht die Einhaltung von Limits und Wiederholungsanweisungen. Laut MDNs 429-Referenz beziehen sich Limits meist auf IPs, bei Authentifizierung oder Cookies aber auch auf Nutzer und Anwendungen. Kontolimits ignorieren neue IPs; kleine Jobs sollten zuerst Retry-After beachten.

Die zugrunde liegende Norm ist RFC 6585, die Statuscode 429 definierte. Eine Antwort darf Retry-After mit der Wartezeit enthalten; Nutzererkennung und Zählweise bleiben offen. Als Beispiel nennt sie Authentifizierungsdaten oder ein zustandsbehaftetes Cookie zur Nutzererkennung.

Drei Fälle sprechen gegen den Kauf: Konten-, API-Token- oder Cookielimits, bei denen alle IPs dasselbe Kontingent verbrauchen und 429 bleibt; kleine Jobs, die einige Hundert Seiten pro Nacht verteilen, Retry-After abwarten und kostenlos mit exponentiellem Backoff wiederholen können; und angemeldete Jobs mit Bedarf an stabiler Identität und fester IP.

Rotation lohnt sich bei IP-bezogenen Limits, volumenabhängigem Nutzen und unabhängigen Anfragen innerhalb der erlaubten Nutzung. Auch dann gelten die Nutzungsbedingungen. Außerdem bewertet das Ziel Verbindungsmerkmale des Clients und das Anfragetempo. Rotation allein garantiert keinen Zugriff.

Prüfe vor dem Kauf Dokumentation und Antwortheader. Erhalten vergleichbare authentifizierte Anfragen 429, während anonyme von derselben Adresse gelingen, deutet das auf ein Konto- oder Authentifizierungslimit hin, beweist es aber nicht. Scheitern beide, kann das Limit pro IP, Ressource oder Server gelten. Halte Endpunkt und Frequenz vergleichbar und beachte Retry-After vor weiteren Tests.

Häufig gestellte Fragen