Rotation ist die stärkste Eigenschaft eines Residential Proxy — und zugleich die am häufigsten falsch konfigurierte. Die Standardeinstellung „IP bei jeder Anfrage wechseln" senkt in den meisten Szenarien die Erfolgsquote senkt, denn natürliches Nutzerverhalten sieht anders aus.
In diesem Beitrag behandeln wir Rotationsauslöser, die Wahl der zielbasierten Strategie und die Frage, warum übermäßige Rotation schädlich ist.
Drei Rotationsmodelle
Das dritte Modell ist eine Kombination aus beiden: Es arbeitet grundsätzlich ergebnisbasiert, setzt aber eine Obergrenze (etwa maximal 50 Anfragen) und verhindert so eine Überlastung der IP.
Wann sollte rotiert werden?
Nach einer erfolgreichen Anfrage die IP zu wechseln, heißt eine funktionierende Ressource zu verschwenden. Setzen Sie Rotation als Korrektur -Instrument ein, nicht als Standardverhalten.
Warum ist übermäßige Rotation schädlich?
Ein echter Nutzer wechselt beim Besuch einer Website nicht die IP. Ein „Nutzer", der bei jeder Anfrage aus einem anderen Land kommt, ist für verhaltensanalysierende Systeme ein äußerst deutliches Signal. Außerdem:
- Cookies und Sessions gehen kaputt: Warenkorb, Filter und Spracheinstellungen gehen verloren.
- Die TLS-Session-Wiederverwendung entfällt: Jede neue IP bedeutet einen neuen Handshake — langsam und teuer zugleich.
- Die Paginierung wird inkonsistent: Verschiedene Exits können unterschiedliche A/B-Varianten oder unterschiedliche Preise sehen.
- Das Kontingent ist schnell aufgebraucht: Jeder Handshake bedeutet einige KB zusätzlichen Traffic.
Die Verbindung über dieselbe IP wiederzuverwenden ist drei- bis viermal schneller als Rotation bei jeder Anfrage. Rotation ist ein Werkzeug mit einem Preis in Geschwindigkeit.
Zielbasierte Strategie
Eine einzige Rotationseinstellung kann nicht für alle Ziele richtig sein. Definieren Sie je nach Schutzniveau des Ziels unterschiedliche Profile:
| Zieltyp | Sticky-Dauer | Anfragen pro IP | Rotationsauslöser |
|---|---|---|---|
| Ungeschützte Inhalte | Unnötig | 100+ | Nur bei Fehler |
| Mittelstark geschützter Marktplatz | 3–5 Min. | 20–40 | Fehler + Obergrenze |
| Grosser Marktplatz | 1–2 Min. | 5–10 | Fehler + kurze Dauer |
| Vorgang mit Login-Pflicht | 15–30 Min. | Über die gesamte Session | Nur am Session-Ende |
Nehmen Sie diese Tabelle als Ausgangspunkt und messen Sie anschließend. Liegt die Erfolgsquote über 95 %, können Sie die Anzahl der Anfragen pro IP schrittweise erhöhen und so die Kosten senken. Fällt sie unter 85 %, nehmen Sie die Änderung zurück.
Umsetzung: Die Logik adaptiver Rotation
Diese Struktur kombiniert zwei Auslöser: sofortige Rotation im Fehlerfall, andernfalls an der Obergrenze. Erfolgreiche Anfragen verbrauchen keine IPs unnötig.
Das Verhältnis von Rotation und Parallelität
Rotation allein genügt nicht. Wenn Sie 50 Anfragen gleichzeitig senden und alle unterschiedliche IPs nutzen, bemerkt das Ziel den intensiven Traffic dennoch binnen kurzer Zeit. Rotation verteilt die Identität , die Geschwindigkeit verteilt sie nicht.
Definieren Sie für jedes Ziel ein eigenes Geschwindigkeits- und Parallelitätsprofil. Eine einzige globale Einstellung verbrennt das empfindlichste Ziel oder bremst das toleranteste aus.
Zur Berechnung der Parallelitaet siehe unseren Beitrag zum Limit gleichzeitiger Verbindungen lesen Sie nach.
Die Rotationseinstellung messen
Der einzige Weg zur richtigen Einstellung ist das Messen. Drei Metriken, die Sie beobachten sollten:
Lesen Sie die drei Metriken gemeinsam. Wenn Sie das Verhältnis IP/Anfrage bei gleichbleibender Erfolgsquote senken können, haben Sie Ihre Kosten unmittelbar reduziert.
Zusammenfassung
Rotation ist kein Standard, sondern ein korrigierendes Werkzeug. Nach erfolgreichen Anfragen die IP zu wechseln verschwendet Geschwindigkeit und Budget zugleich und wirkt unnatürlich. Der richtige Aufbau kombiniert einen ergebnisbasierten Auslöser mit einer sinnvollen Obergrenze, definiert zielbasierte Profile und betrachtet Rotation gemeinsam mit der Geschwindigkeitssteuerung. Um Ihre Implementierung zu testen Proxy-Check, für Produktoptionen Rotating Proxy an.