---
title: "Was ist IP-Rotation und wie funktioniert sie?"
description: "IP-Rotation heißt: Die Ausgangs-IP Ihrer Anfragen wechselt innerhalb eines Pools. Drei Rotationsmodi, der Gateway-Ablauf und wann die IP trotzdem gleich bleibt."
url: https://proxynet.io/de/blog/ip-rotation-explained
date: 2026-09-19
author: "Acar Diveroli"
category: "Proxy 101, Web Scraping"
lang: de
---

# Was ist IP-Rotation und wie funktioniert sie?

Sie haben einen rotierenden Proxy gekauft, Ihr Skript angebunden und drei Anfragen hintereinander an einen IP-Echo-Dienst geschickt. Alle drei Male kam dieselbe Adresse zurück. Oder es war umgekehrt: Ein Skript, das sich in Ihrem eigenen Dashboard anmeldet, landete auf der zweiten Seite wieder auf dem Anmeldebildschirm, weil die Ausgangs-IP mitten in der Sitzung gewechselt hat. In beiden Fällen ist der Proxy nicht defekt. Der Aufbau wurde eingerichtet, ohne zu wissen, welches Ereignis die Rotation auslöst.

In diesem Beitrag definieren wir IP-Rotation kurz und gehen dann zum eigentlichen Thema über, dem Ablauf: dem Weg einer Anfrage hinter einem Gateway, den drei Rotationsmodi (pro Anfrage, zeitgesteuert, Sticky-Sitzung), den Begriffen, die durcheinandergeraten, der Wiederverwendung von Verbindungen als häufigstem Grund dafür, dass die IP nicht wie erwartet wechselt, und den Dingen, die durch Rotation kaputtgehen. Am Ende stehen ein kurzes, erprobtes Python-Beispiel, das die Rotation überprüft, und eine Entscheidungshilfe.

> **Hinweis: Kurzantwort**
>
> IP-Rotation bedeutet, dass die Ausgangs-IP-Adresse Ihrer ausgehenden Anfragen innerhalb eines Pools gewechselt wird. Sie verbinden sich mit einer einzigen Adresse (dem Gateway); welche Ausgangs-IP verwendet wird, entscheidet das Gateway. Der Wechsel wird auf drei Arten ausgelöst: bei jeder neuen Verbindung, nach Ablauf einer bestimmten Zeit oder wenn sich die von Ihnen festgelegte Sitzungs-ID ändert. Rotation ist kein Mittel, um eine Sperre zu ignorieren; sie dient dazu, Last auf Adressen zu verteilen, Inhalte standortabhängig zu sehen und Sitzungen voneinander zu trennen.

## Was ist IP-Rotation?

IP-Rotation (auch Proxy-Rotation genannt) bedeutet, dass die Ausgangs-IP ausgehender Netzwerkanfragen nicht bei einer einzigen Adresse bleibt, sondern zwischen den Adressen eines IP-Pools wechselt. Der Dienst, der das für Sie übernimmt, heißt rotierender Proxy oder englisch [Rotating Proxy](/de/rotating-proxy); Definition, Pool und Targeting-Optionen des Produkts stehen auf dieser Seite. Hier geht es nicht um das Produkt, sondern um den Ablauf: wann die IP wechselt, wann nicht und wer das bestimmt.

Ganz fremd ist das Konzept nicht. Auch die dynamische IP Ihres Internetanschlusses zu Hause ist eine Art Rotation: Ihr Anbieter ändert Ihre Adresse von Zeit zu Zeit, aber wann sie wechselt und welche Adresse Sie bekommen, entscheiden nicht Sie. Diese Seite haben wir in [Statische oder dynamische IP: Was ist der Unterschied?](/de/blog/static-ip-vs-dynamic-ip) und [IP-Adresse ändern](/de/blog/how-to-change-ip-address) beschrieben. Bei der Proxy-Rotation liegt die Kontrolle dagegen bei Ihnen: Sie wählen, wie oft gewechselt wird, aus welchem Land die Adresse stammt und welche Anfragen über dieselbe Adresse hinausgehen.

## Wofür eignet sich Rotation und wofür nicht?

Rotation hat drei legitime Zwecke:

- **Last verteilen.** Ein Job, der die öffentlich zugänglichen Seiten von Hunderten Websites einsammelt und den gesamten Traffic über eine Adresse schickt, belastet diese Adresse mit mehr Anfragen, als ein echter Besucher je erzeugen könnte. Rotation hält die Last pro Adresse in einem vertretbaren Rahmen.
- **Inhalte standortabhängig sehen.** Preise, Lagerbestand und Suchergebnisse hängen vom Land des Besuchers ab. Wer den Pool auf ein Land oder eine Stadt festlegt und innerhalb dieses Standorts rotiert, sieht die tatsächliche Ansicht dieses Marktes.
- **Sitzungen trennen.** Voneinander unabhängige Aufgaben (verschiedene Kundenkonten, verschiedene Testszenarien) gehen jeweils über eine eigene Adresse hinaus; keine trägt die Spur der anderen.

Ebenso klar ist, wo Rotation nichts bringt. Wenn die Website Sie mit `429` zum Verlangsamen aufgefordert, einen Pfad per robots.txt gesperrt oder automatisierten Zugriff in ihren Nutzungsbedingungen untersagt hat, löst ein IP-Wechsel bei gleichem Tempo das Problem nicht; er übergeht eine Entscheidung, die der Betreiber ausdrücklich mitgeteilt hat. Den vollständigen Rahmen finden Sie in [Web Scraping ohne Sperren](/de/blog/web-scraping-without-getting-blocked), die richtige Reaktion auf `429` in [429 Too Many Requests und Rate Limiting erklärt](/de/blog/http-429-too-many-requests).

## Wie funktioniert Rotation über ein Gateway (Backconnect)?

Bei der Rotation alter Schule halten Sie eine Proxy-Liste, und Ihr Code wählt die nächste Adresse. Im Gateway-Modell liegt die Liste nicht bei Ihnen. Sie verbinden sich mit einer einzigen `host:port`-Adresse, den Pool dahinter verwaltet der Anbieter. Diese Architektur heißt Backconnect. Eine HTTPS-Anfrage nimmt folgenden Weg:

1. **Der Client verbindet sich mit dem Gateway.** Ihr Skript öffnet eine TCP-Verbindung zu einem festen Endpoint wie `pr.proxynet.io:8000`.
2. **Zugangsdaten und Parameter werden gelesen.** Das Gateway prüft die `user:pass`-Angabe im Header `Proxy-Authorization`. Vorgaben wie Land, Stadt und Sitzungs-ID werden ebenfalls an dieser Stelle gelesen, aus Parametern, die an den Benutzernamen angehängt sind. Die beiden Authentifizierungsmethoden stehen in [Proxy-Authentifizierung: User:Pass oder IP-Whitelist](/de/blog/proxy-authentication-methods).
3. **Der Pool wird gefiltert.** Haben Sie ein Standortziel angegeben, betrachtet das Gateway nur die passenden Ausgänge als Kandidaten. Die Rotation findet innerhalb dieser Teilmenge statt.
4. **Ein Ausgangsknoten wird gewählt.** Je nach Rotationsmodus wird entweder ein neuer Ausgang zugewiesen oder der Ausgang wiederverwendet, der bereits an Ihre Sitzung gebunden ist. Dieser Schritt unterscheidet die drei Rotationsmodi.
5. **Der Tunnel wird aufgebaut.** Das Gateway verbindet sich über den gewählten Ausgang mit dem Ziel und antwortet dem Client mit `200 Connection Established`. Der TLS-Handshake findet danach statt, zwischen Client und Zielseite.
6. **Der Traffic wird weitergeleitet.** Die Zielseite sieht die Anfrage so, als käme sie von der IP des Ausgangsknotens. Weder die Adresse des Gateways noch Ihre eigene erreicht das Ziel.

Die ersten Zeilen, die der Client an das Gateway sendet, sehen etwa so aus:

```text
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz
```

Die Methode `CONNECT` ist in [Abschnitt 9.3.6 von RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-connect) definiert, und hier steckt ein wichtiges Detail: Sobald der Tunnel steht, transportiert der Proxy nur noch Bytes. Die einzelnen HTTPS-Anfragen, die hindurchlaufen, kann er nicht sehen. Die Ausgangs-IP wird beim Aufbau des Tunnels gewählt und ändert sich nicht, solange der Tunnel offen bleibt. Deshalb bedeutet „bei jeder Anfrage eine neue IP“ in der Praxis „bei jeder neuen Verbindung eine neue IP“. Bei unverschlüsseltem HTTP sieht der Proxy jede Anfrage einzeln, dort ist ein Wechsel pro Anfrage tatsächlich möglich; da die meisten Websites heute aber über HTTPS laufen, sollten Sie grundsätzlich von der Verbindung ausgehen.

## Drei Rotationsmodi: pro Anfrage, zeitgesteuert und Sticky-Sitzung

Die Modi unterscheiden sich darin, welches Ereignis in Schritt vier die Entscheidung „neuer oder alter Ausgang“ auslöst.

### Rotation pro Anfrage

Jede neue Verbindung zum Gateway erhält einen anderen Ausgang aus dem Pool. Der Client hält keinen Zustand, und auch das Gateway merkt sich nichts für Sie. Das ist der Modus für Jobs, die viele voneinander unabhängige Seiten einsammeln: Jede Produktseite ist eine einzelne Anfrage, und die nächste muss nicht von derselben Adresse kommen. Der Preis dafür ist ein neuer TCP- und TLS-Handshake bei jeder Anfrage; die Latenz steigt gegenüber einem Aufbau, der Verbindungen wiederverwendet.

### Zeitgesteuerte Rotation

Die Ausgangs-IP wechselt in einem festen Intervall. Bis das Intervall abläuft, gehen alle Verbindungen, die Sie öffnen, über dieselbe Adresse hinaus; danach wechseln alle gemeinsam zur neuen Adresse. Auslöser ist die Uhr, nicht Ihre Anfragen. Häufig ist das bei mobilen Proxy-Ports, die über ein einzelnes Modem oder Gerät laufen: Die IP wird erneuert, wenn sich das Gerät neu mit dem Mobilfunknetz verbindet. Die Einrichtung ist einfach, aber Sie können nicht wählen, an welcher Stelle Ihres Jobs der Wechsel eintritt.

### Sticky-Sitzung

Sie hängen eine Sitzungs-ID (Session-ID) an den Benutzernamen an. Verbindungen mit derselben ID werden an denselben Ausgang gebunden, verschiedene IDs an verschiedene Ausgänge. Wie lange die Sitzung auf derselben IP gehalten wird, wählen Sie im Dashboard, zwischen 1 und 60 Minuten; läuft die Zeit ab oder ändern Sie die ID, weist das Gateway einen neuen Ausgang zu. Der Unterschied zur zeitgesteuerten Rotation: Die Gruppierung nehmen Sie selbst vor. Geben Sie zwanzig parallelen Jobs jeweils eine eigene ID, läuft jeder mit seiner eigenen festen Adresse neben den anderen. Das ist der Modus für Aufgaben, bei denen der Server Zustand hält, etwa Dashboards mit Anmeldung, Warenkorbabläufe und Paginierung. Die Produktseite dazu: [Sticky-Proxy](https://proxynet.io/de/sticky-proxy).

Eine Grenze gibt es: In Residential- und Mobile-Pools ist der Ausgangsknoten ein echtes Gerät und kann das Netz verlassen. Dann verlegt das Gateway die Sitzung vor Ablauf der Zeit auf einen anderen Ausgang. Eine Sticky-Sitzung bedeutet „versuche, dieselbe IP so lange zu halten“, keine Garantie. Für Aufgaben, die lückenlose Kontinuität brauchen, wird [Statischer Proxy](https://proxynet.io/de/static-proxy) verwendet, bei dem die Adresse Ihnen zugeteilt ist.

| | Pro Anfrage | Zeitgesteuert | Sticky-Sitzung | Statisch (zum Vergleich) |
|---|---|---|---|---|
| Ereignis, das die IP ändert | Jede neue Verbindung | Ablauf des Intervalls | Änderung der Sitzungs-ID oder Ablauf der Zeit | Ändert sich nicht |
| Wer die Kontrolle hat | Das Gateway | Die Uhr | Sie | Niemand |
| Abläufe mit Zustand | Brechen | Brechen im Moment des Wechsels | Bleiben erhalten | Bleiben erhalten |
| Bei parallelen Jobs | Eigene IP pro Verbindung | Alle auf derselben IP | Eigene IP pro ID | So viele, wie Sie IPs haben |
| Typische Aufgabe | Massenhaftes Lesen unabhängiger Seiten | Mobiler Port mit einem Gerät | Anmeldung, Warenkorb, Paginierung | API-Allowlist, langlebiges Konto |

## Begriffe: Rotating Proxy, Backconnect, Sticky und die übrigen

Die Begriffe geraten durcheinander, weil dieselbe Sache mehrere Namen trägt und verschiedene Dinge denselben Namen. „Rotierender Proxy“, „Proxy mit IP-Rotation“ und „Rotating Proxy“ in deutschsprachigen Quellen meinen dasselbe Produkt.

| Begriff | Was er beschreibt | Womit er oft verwechselt wird |
|---|---|---|
| IP-Rotation / Proxy-Rotation | Der Ablauf: Die Ausgangs-IP wechselt innerhalb eines Pools | Wird für den Produktnamen gehalten |
| Rotierender Proxy / Rotating Proxy | Das Produkt: ein Proxy-Dienst, der am Gateway rotiert | Proxy-Liste |
| Backconnect | Die Architektur: ein Endpoint, dahinter ein Pool | Wird für einen eigenen Proxy-Typ gehalten; es ist die Arbeitsweise des rotierenden Proxys |
| Gateway | Das `host:port`, mit dem Sie sich verbinden; der Server, der den Ausgang wählt | Ausgangs-IP. Die Zielseite sieht die Adresse des Gateways nicht |
| Ausgangsknoten / Ausgangs-IP | Die Adresse, die die Zielseite sieht | Adresse des Gateways |
| IP-Pool | Die Menge der Adressen, aus der das Gateway wählt | Adressen, die Ihnen gehören. Der Pool wird geteilt |
| Sticky-Sitzung | Dieselbe Sitzungs-ID bleibt eine Zeit lang an denselben Ausgang gebunden | Statische IP. Sticky ist vorübergehend |
| Statischer Proxy | Eine Ihnen zugeteilte, unveränderliche Adresse | Lange Sticky-Sitzung |
| Proxy-Liste | Eine feste Reihe von Adressen, die Sie mit eigenem Code rotieren | Rotierender Proxy |

Ein Hinweis: Wer nach „Sticky Session“ sucht, stößt auch auf Dokumentation zu Load Balancern. Dort beschreibt der Begriff, dass ein Besucher immer an denselben Backend-Server geleitet wird. Die Logik ist dieselbe, die Richtung umgekehrt: Beim Load Balancer wird eingehender Traffic festgelegt, beim Proxy ausgehender.

## Soll der Code rotieren oder das Gateway?

Wenn Sie eine Liste fester, Ihnen gehörender Adressen haben, übernimmt Ihr Code die Rotation: Vor jeder Anfrage wird die nächste oder eine zufällige Adresse aus der Liste gewählt. Die Auswahl der Reihe nach verteilt die Last gleichmäßig; die zufällige Auswahl kommt ohne gemeinsamen Zähler zwischen parallel laufenden Jobs aus. Eine Adresse, die nicht mehr antwortet, aus der Liste zu nehmen und die Rate pro Adresse zu begrenzen, bleibt ebenfalls Ihre Aufgabe. Den Python-Code für beide Verfahren haben wir Schritt für Schritt mit Requests in [Proxys in Python rotieren](/de/blog/how-to-rotate-proxies-in-python) gezeigt; hier schreiben wir ihn nicht noch einmal.

Im Gateway-Modell wandert all das auf die Gegenseite. In Ihrem Code bleibt eine einzige Proxy-Adresse, der Rotationsmodus wird über Parameter im Benutzernamen gewählt. Dafür kennen Sie die Adressen nicht einzeln: Sie wissen nicht im Voraus, über welche IP die nächste Anfrage hinausgeht, sondern legen nur Land, Stadt und Sitzungsverhalten fest. Für einen kleinen Job mit wenigen Adressen genügt eine Liste; je größer der Pool wird, desto mehr Zeit kostet die Pflege der Liste im Vergleich zur eigentlichen Arbeit.

## Warum hat die IP nicht gewechselt? Wiederverwendung von Verbindungen

Wenn Sie trotz Rotation pro Anfrage immer dieselbe IP sehen, liegt das meist nicht am Proxy, sondern an Ihrem Client. In HTTP/1.1 sind Verbindungen standardmäßig persistent ([RFC 9112, 9.3](https://www.rfc-editor.org/rfc/rfc9112#name-persistence)): Nach einer Antwort hält der Client dieselbe TCP-Verbindung für die nächste Anfrage offen. Hinter einem Proxy heißt das, dass derselbe `CONNECT`-Tunnel wiederverwendet wird. Weil der Ausgang des Tunnels beim Aufbau gewählt wird, findet das Gateway keinen Moment, um zu rotieren.

Mehr Clients verwenden Verbindungen wieder, als man annimmt. In Python Requests erledigt das `Session`-Objekt dies von selbst; die [Requests-Dokumentation](https://requests.readthedocs.io/en/latest/user/advanced/#keep-alive) hält fest, dass Keep-Alive innerhalb einer Session automatisch ist. `Client` in HTTPX, `ClientSession` in AIOHTTP, Agents mit aktiviertem Keep-Alive in Node.js und alle Browser verhalten sich genauso. Die Unterschiede zwischen den Bibliotheken stehen in [HTTPX, Requests und AIOHTTP im Vergleich](/de/blog/httpx-vs-requests-vs-aiohttp).

Was Sie tun, hängt davon ab, was Sie wollen:

- **Wenn Sie bei jeder Anfrage eine neue IP möchten**, öffnen Sie für jede Anfrage eine neue Verbindung oder fügen Sie der Anfrage den Header `Connection: close` hinzu. Das Ziel schließt die Verbindung nach der Antwort, und der Tunnel schließt sich mit ihr. Die Kosten eines neuen Handshakes nehmen Sie damit jedes Mal in Kauf.
- **Wenn Sie auf derselben IP bleiben möchten**, verlassen Sie sich nicht auf Keep-Alive. Die Verbindung kann durch ein Timeout, serverseitig oder bei einem Wiederholungsversuch abbrechen, und eine neue Verbindung bringt eine neue IP. Stellen Sie Kontinuität über die Sitzungs-ID her, also über eine Sticky-Sitzung.
- **Bei der Browser-Automatisierung** öffnet eine einzige Seite viele parallele Verbindungen, um ihre Ressourcen zu laden. Mit Rotation pro Anfrage wird das HTML derselben Seite über eine Adresse angefordert, die Bilder über andere. Verwenden Sie mit einem Browser eine Sticky-Sitzung; die Einrichtung steht in [Was ist Playwright und wie nutzt man es mit Proxy?](/de/blog/playwright-proxy).

## Rotation überprüfen: drei Anfragen hintereinander

Ob sich Ihr Aufbau wie erwartet verhält, sehen Sie, indem Sie einige Anfragen hintereinander an einen Dienst schicken, der Ihre Ausgangs-IP als Antwort zurückgibt. Das folgende Beispiel sendet dieselben drei Anfragen auf zwei Arten: zuerst jedes Mal mit einer neuen Verbindung, dann über eine einzige `Session`.

```python
import requests

PROXY = "http://user:pass@pr.proxynet.io:8000"
PROXIES = {"http": PROXY, "https": PROXY}
IP_ECHO = "https://api.ipify.org"

def new_connection_each_time(count=3):
    ips = []
    for _ in range(count):
        # Aufruf ohne Session: Jede Anfrage öffnet und schließt ihre eigene Verbindung
        response = requests.get(IP_ECHO, proxies=PROXIES, timeout=20)
        ips.append(response.text.strip())
    return ips

def shared_session(count=3):
    ips = []
    with requests.Session() as session:
        session.proxies.update(PROXIES)
        for _ in range(count):
            # Dieselbe Session: Der bei der ersten Anfrage geöffnete Tunnel wird wiederverwendet
            response = session.get(IP_ECHO, timeout=20)
            ips.append(response.text.strip())
    return ips

def report(label, ips):
    print(f"{label}: {ips} -> {len(set(ips))} verschiedene IPs")

report("jedes Mal neue Verbindung", new_connection_each_time())
report("gemeinsame Session (Keep-Alive)", shared_session())
```

Bei einem Gateway, das pro Anfrage rotiert, sieht die erwartete Ausgabe etwa so aus (die Adressen stammen aus den für Dokumentation reservierten Beispielbereichen):

```text
jedes Mal neue Verbindung: ['203.0.113.24', '198.51.100.7', '203.0.113.181'] -> 3 verschiedene IPs
gemeinsame Session (Keep-Alive): ['198.51.100.92', '198.51.100.92', '198.51.100.92'] -> 1 verschiedene IPs
```

Beim Test des Beispiels an einem lokalen Testproxy zeigte das Proxy-Protokoll, dass die erste Funktion drei getrennte `CONNECT`-Tunnel öffnete und die zweite nur einen; nachdem der `Session` der Header `Connection: close` hinzugefügt wurde, stieg die Zahl der Tunnel wieder auf drei. Sehen Sie auch in der ersten Zeile nur eine IP, verbinden Sie sich mit einem Sticky-Benutzernamen oder einer statischen Adresse. Um zusätzlich das Land der Ausgangs-IP und mögliche Leaks zu prüfen, lesen Sie [Funktioniert mein Proxy? So testen Sie einen Proxy](/de/blog/how-to-test-a-proxy).

## Wie funktioniert ein rotierender mobiler Proxy?

Bei „rotierender mobiler Proxy“ denkt man an einen Tisch voller Smartphones, doch der eigentliche Mechanismus liegt im Netz des Mobilfunkanbieters. Mobilfunkanbieter teilen eine einzige öffentliche IPv4-Adresse gleichzeitig unter vielen Kunden auf (CGNAT); verbindet sich ein Gerät neu mit dem Netz, kann es eine andere Adresse aus dem Pool des Anbieters erhalten. Die Rotation mobiler Proxys beruht auf diesem Verhalten: Entweder verbindet sich ein einzelnes Gerät in festen Abständen neu (zeitgesteuerte Rotation), oder das Gateway wählt unter vielen Geräten aus. Wie CGNAT funktioniert, steht in [Was ist CGNAT? So erkennen Sie es und kommen heraus](/de/blog/what-is-cgnat).

Daraus folgen zwei praktische Dinge. Erstens wird eine mobile Ausgangs-IP in diesem Moment mit echten Kunden geteilt; eine starke Nutzung der Adresse trifft nicht nur Sie, sondern auch diese Kunden, deshalb ist eine niedrige Anfragerate im mobilen Pool keine Höflichkeit, sondern Pflicht. Zweitens bedeutet „neue IP“ im mobilen Pool nicht immer eine Adresse, die Sie noch nie gesehen haben: Der Pool des Anbieters ist begrenzt, und dieselbe Adresse kann erneut bei Ihnen landen. Die Produktseite dazu: [Mobile-Proxy](https://proxynet.io/de/mobile-proxy).

## Was durch Rotation kaputtgeht

Einige Dinge gehen still kaputt, sobald Rotation eingeschaltet ist. Gemeinsam ist ihnen, dass der Server Sie auch an etwas anderem als der IP erkennt.

- **Cookie und IP passen nicht zusammen.** Ihr Cookie-Speicher bleibt gleich, die IP wechselt bei jeder Anfrage. Die Website sieht dasselbe Sitzungs-Cookie innerhalb von Minuten aus verschiedenen Städten; ihre Sicherheitslogik beendet die Sitzung oder verlangt eine erneute Bestätigung. Die Regel ist einfach: ein Cookie-Speicher, eine Sitzungs-ID, eine IP. Den Aufbau für Aufgaben, die eine Anmeldung mit Ihrem eigenen Konto erfordern, zeigt [Login, Sessions und Cookies in Python](/de/blog/python-login-session-cookies).
- **Sitzung bricht mitten in der Paginierung ab.** Suchergebnisse und gefilterte Listen hängen oft an einem Zustand, der auf dem Server gehalten wird (Cursor, Suchsitzung). Wechselt die IP auf Seite fünf, kann die Website Sie auf Seite eins zurückschicken oder dieselben Datensätze noch einmal liefern; die Daten sind unvollständig oder doppelt, und Sie sehen keinen Fehlercode. Details stehen in [Paginierung beim Web Scraping](/de/blog/pagination-web-scraping).
- **Rotation ohne Standortziel.** Ohne Ziel rotieren Sie im gesamten Pool: Eine Anfrage geht aus Deutschland hinaus, die nächste aus Brasilien. Preise kommen in unterschiedlichen Währungen, Seiten in unterschiedlichen Sprachen, und die gesammelten Daten lassen sich untereinander nicht vergleichen.
- **Zähler, die nicht an der IP hängen.** Wird das Rate Limit pro Konto, Cookie oder API-Schlüssel gezählt, ändert Rotation nichts. Was bei welchem Code zu tun ist, haben wir in [HTTP-Statuscodes beim Web Scraping](/de/blog/http-status-codes-web-scraping) zusammengestellt.

## Einsatzbereiche

- **Preis- und Bestandsüberwachung über viele Websites.** Jede Produktseite ist eine unabhängige Anfrage; das Land wird festgelegt, der Modus ist pro Anfrage. Den Aufbau zeigt unsere Seite zur [Preisüberwachung](/de/price-monitoring), die Methoden stehen in [Wettbewerberpreise im E-Commerce überwachen](/de/blog/competitor-price-tracking).
- **Öffentliche Kataloge und Anzeigen erfassen.** Geringe Parallelität pro Website, Rotation zum Verteilen der Last: [Data-Scraping-Lösung](/de/data-scraping).
- **Ansicht nach Standort prüfen.** Um über Heimanschlüsse zu prüfen, wie eine Anzeige, ein Preis oder eine Seite aus einer bestimmten Stadt aussieht: [Residential-Proxy](https://proxynet.io/de/residential-proxy).
- **Dashboards, in denen Sie mit eigenen Konten arbeiten.** Eine Sitzungs-ID pro Konto und dieselbe IP für die Dauer dieser Sitzung: Sticky-Sitzung.
- **APIs, die eine IP-Allowlist verlangen.** Wenn die Gegenseite Ihre Adresse in ihre Liste einträgt, hilft Rotation nicht, die Adresse darf sich nicht ändern: [Statische IP für den API-Zugriff](/de/blog/static-ip-for-api-access).

## Häufige Fehler

- **Mit einer `Session` Rotation pro Anfrage erwarten.** Die Session verwendet die Verbindung wieder; die IP bleibt gleich, bis der Tunnel geschlossen wird.
- **Allen parallelen Jobs dieselbe Sitzungs-ID geben.** Alle stauen sich auf einer IP, und der Vorteil der Lastverteilung geht verloren.
- **Rotation an die Stelle eines Rate Limits setzen.** Die Adresse wechselt, die Gesamtlast auf dem Ziel bleibt gleich; eine Parallelitätsgrenze pro Website und Wartezeiten sind zusätzlich nötig.
- **Den Wiederholungsversuch sofort mit neuer IP starten.** Nach `429` oder `503` ohne Wartezeit erneut zu senden, übergeht die Verlangsamung, die der Server verlangt hat.

## Entscheidungshilfe

| Bedarf | Empfehlung |
|---|---|
| Viele voneinander unabhängige öffentliche Seiten | Rotation pro Anfrage, Land festgelegt |
| Anmeldung, Warenkorb oder mehrstufiges Formular | Sticky-Sitzung, eine ID pro Ablauf |
| Lange Liste, die per Paginierung durchlaufen wird | Sticky-Sitzung; ID wechseln, wenn die Liste fertig ist |
| Browser-Automatisierung (Playwright, Selenium) | Sticky-Sitzung, eine ID pro Browserprofil |
| Unabhängige Konten, die gleichzeitig laufen | Eigene Sitzungs-ID pro Konto |
| IP-Allowlist, eine langlebige Identität | Statischer Proxy |
| Sie haben einige feste Adressen | Listenrotation im Code |
| Die Website antwortet mit `429` | Keine Rotation: warten und die Rate senken |

## Häufige Fragen

### Sind IP-Rotation und rotierender Proxy dasselbe?

Das eine ist ein Ablauf, das andere ein Produkt. IP-Rotation ist der Wechsel der Ausgangsadresse, und das können Sie mit einer Proxy-Liste auch im eigenen Code tun. Ein rotierender Proxy (Rotating Proxy) ist der Dienst, der das am Gateway für Sie übernimmt.

### Ist ein Backconnect-Proxy ein eigener Proxy-Typ?

Nein. Backconnect ist der Name einer Architektur: Sie verbinden sich mit einem einzigen Endpoint, und das Gateway wählt den Ausgang aus dem Pool dahinter. Rotierende Residential- und Mobile-Proxy-Dienste arbeiten so. Den Typ der IP (Heimanschluss, Mobilfunk, Rechenzentrum) bestimmt nicht Backconnect, sondern die Herkunft des Pools; den Unterschied zwischen den Typen erklärt [ISP- oder Residential-Proxy: Unterschied und Auswahl](/de/blog/isp-vs-residential-proxy).

### Warum wechselt die IP trotz Rotation nicht bei jeder Anfrage?

Sehr wahrscheinlich verwendet Ihr Client dieselbe Verbindung wieder. Bei HTTPS wird die Ausgangs-IP beim Aufbau des `CONNECT`-Tunnels gewählt und ändert sich nicht, solange der Tunnel offen ist. Öffnen Sie für jede Anfrage eine neue Verbindung oder senden Sie den Header `Connection: close`. Prüfen Sie außerdem, ob in Ihrem Benutzernamen noch ein Sticky-Parameter steht.

### Wie lange dauert eine Sticky-Sitzung?

Die Dauer wählen Sie im Dashboard, zwischen 1 und 60 Minuten, und durch Ändern der Sitzungs-ID können Sie jederzeit zu einer neuen IP wechseln. Die Dauer ist eine Obergrenze, keine Garantie: Verlässt der Ausgangsknoten das Netz, verlegt das Gateway die Sitzung früher auf eine andere Adresse. Schreiben Sie Ihren Code so, dass er den Ablauf von vorn beginnt, wenn die IP mitten in der Sitzung wechselt.

### Macht Rotation das Einhalten von Rate Limits überflüssig?

Nein. Rotation senkt die Last pro Adresse, nicht die Gesamtlast auf dem Zielserver. Eine Parallelitätsgrenze pro Website, Wartezeiten zwischen den Anfragen und das Beachten des Headers `Retry-After` sind auch mit Rotation nötig.

### Wie viele IPs braucht man für Rotation?

Eine einzige richtige Zahl gibt es nicht; gerechnet wird von der Anfragerate pro Adresse aus. Im Gateway-Modell müssen Sie diese Rechnung nicht anstellen, weil Sie keine Adressen kaufen: Sie rotieren im gesamten Pool, und abgerechnet wird meist nach Traffic. Die Auswahlkriterien stehen in [Proxy kaufen: Worauf sollten Sie achten?](/de/blog/proxy-buying-guide).

## Fazit

IP-Rotation ist der Wechsel der Ausgangsadresse innerhalb eines Pools, und die Entscheidung trifft das Gateway: bei jeder neuen Verbindung, nach Ablauf der Zeit oder bei einer neuen Sitzungs-ID. Weil der Ausgang bei HTTPS beim Tunnelaufbau gewählt wird, ist Rotation „pro Anfrage“ in Wahrheit Rotation pro Verbindung; ein Client, der seine Verbindung wiederverwendet, bleibt auf derselben IP. Wählen Sie Rotation pro Anfrage für unabhängige Seiten, eine Sticky-Sitzung für Abläufe mit Zustand und eine statische Adresse für Identitäten, die sich nicht ändern dürfen, und geben Sie das Land immer ausdrücklich an. Rotation ersetzt kein Rate Limit; sie verteilt die Last, ein rücksichtsvolles Crawl-Tempo bleibt trotzdem nötig. Die passenden Typen können Sie in unseren [Proxy-Diensten](/de/proxy) vergleichen.