Master Proxy-IP-Rotation: Vermeiden Sie Sperren im Jahr 2026

Sie bemerken das Problem normalerweise erst, nachdem das Skript bereits live ist. Anfragen beginnen sauber, dann verlangsamt die Zielseite Ihre Antworten, wirft Anmeldeherausforderungen auf, setzt Sitzungen zurück oder hört auf, die erwarteten Daten zurückzugeben. Auf sozialen Plattformen zeigt sich der Schmerz anders. Eine Kontohandlung funktioniert einmal, dann wird der nächste Schritt herausgefordert, weil die Plattform nicht mehr glaubt, dass derselbe Benutzer noch da ist.

Hier hört Proxy-IP-Rotation auf, ein Schlagwort zu sein, und wird zu einer operativen Kontrolle. Es geht nicht nur darum, eine IP zu verbergen. Es geht darum zu entscheiden, wann man die Identität ändern, wann man sie stabil halten und wie man den Rest der Sitzung konsistent hält, damit der Workflow abgeschlossen werden kann.

Warum Ihre Automatisierungsskripte immer wieder fehlschlagen

Die meisten fehlerhaften Automatisierungen scheitern nicht aufgrund von Syntax. Sie scheitern, weil das Zielsystem Vertrauen aufbaut, dass Ihr Verkehr künstlich ist. Das einfachste Signal, das zu erkennen ist, ist wiederholte Aktivität von derselben Quell-IP. Sobald dieses Muster offensichtlich wird, werden die Ratenlimits strenger, CAPTCHAs erscheinen oder der Endpunkt verhält sich nicht mehr wie während der Tests.

Deshalb hat sich die Proxy-Infrastruktur im Laufe der Zeit verändert. Anbieter haben Rotation entwickelt, weil Websites gelernt haben, wiederholte Anfragen von einer IP zu blockieren, und moderne Systeme jetzt automatisch durch Pools rotieren, entweder pro Anfrage oder nach einem Timer, oft mit Sticky-Session-Optionen für Kontinuität, wie in LiveProxies' Übersicht über rotierende Proxys beschrieben. Dieser Wandel hat Proxys von einfachen Maskierungstools in eine Infrastruktur für großangelegte Automatisierung verwandelt.

Die praktische Lektion ist einfach. Wenn Ihr Skript viele Anfragen über eine statische Route sendet, hat das Ziel einen einfachen Korrelationspunkt.

Wie sich Fehler in realen Workflows darstellen

Die Symptome hängen vom Job ab:

• Web-Scraping: Sie beginnen, unvollständige Seiten, Herausforderungsseiten, leere Antworten oder abrupte Sperren zu erhalten.

• Soziale Medienoperationen: Anmeldungen funktionieren, aber Folgeaktionen lösen Sicherheitsprüfungen aus, weil sich die Sitzungsidentität zur falschen Zeit ändert.

• QA-Tests: Sie können regionensensible oder sitzungsabhängige Probleme nicht reproduzieren, weil sich das Netzwerkverhalten zu statisch verhält oder zu aggressiv ändert.

Praktische Regel: Wenn ein Workflow Anmeldungen, Warenkorbzustände, mehrstufige Formulare oder Kontohandlungen enthält, wird die falsche Rotationspolitik ihn brechen, selbst wenn der Code korrekt ist.

Ein Junior-Teammitglied versucht oft, dies zu lösen, indem es so schnell wie möglich rotiert. Das funktioniert für einige Scraping-Jobs und schlägt bei zustandsabhängigen Jobs schlecht fehl. Die Kernfrage ist nicht „Soll ich rotieren?“ sondern „Welcher Teil dieses Workflows benötigt Kontinuität und welcher Teil benötigt Wechsel?“

Die Kontrolle, die Sie tatsächlich benötigen

Ein funktionierendes Setup balanciert drei Dinge:

1. Ändern Sie die Identität ausreichend, um offensichtliche IP-basierte Korrelationen zu reduzieren.

2. Halten Sie die Identität stabil genug, um sitzungsbasierte Aufgaben abzuschließen.

3. Überprüfen Sie das Verhalten, anstatt anzunehmen, dass der Anbieter auf die Weise rotiert, wie Sie denken.

Das ist der Unterschied zwischen einem Skript, das in einem Labor läuft, und einem, das den Produktionsverkehr übersteht.

Was ist Proxy-IP-Rotation

Auf der einfachsten Ebene bedeutet Proxy-IP-Rotation, dass Ihre Software mit einem Proxy-Endpunkt kommuniziert, während die Zielseite im Laufe der Zeit Anfragen von verschiedenen IP-Adressen sieht. Dies funktioniert ähnlich wie das Senden desselben Operators durch verschiedene Eingänge, jedes Mal mit einem anderen Ausweis, anstatt den ganzen Tag durch dieselbe Tür mit derselben sichtbaren Identität zu gehen.

Das mentale Modell, das es klickt

Wenn Sie neu in rotierenden Pools sind, ist das einfachste mentale Modell folgendes:

• Ihr Skript verbindet sich mit einem Gateway.

• Dieses Gateway hat Zugriff auf viele mögliche Ausgangs-IPs.

• Das Gateway entscheidet, ob es eine IP eine Weile lang weiterverwendet oder basierend auf der Rotationspolitik zu einer anderen wechselt.

Deshalb fühlen sich rotierende Proxys anders an als das selbstständige Verwalten einer Liste statischer Proxys. Ihre Anwendung kann ein Verbindungsmuster beibehalten, während der Anbieter das Poolverhalten dahinter verwaltet.

Ein rotierender Proxy kann als einzelner Endpunkt implementiert werden, der bei jeder Anfrage oder nach einem festen Intervall eine andere IP zuweist. Dieses Setup reduziert IP-basierte Korrelationen, weil das Ziel eine sich ändernde Quelladresse sieht, anstatt einer beständigen. Es senkt auch die Wahrscheinlichkeit von Ratenlimit-Auslösungen und IP-Sperren, obwohl es mehr Verbindungsaufbau-Overhead als ein statischer Proxy einführen kann, wie in Oxylabs' Beschreibung des Verhaltens rotierender IPs erklärt.

Später im Workflow hilft es, das Konzept in Bewegung zu sehen:

Was sich ändert und was nicht

Viel Verwirrung entsteht durch das Verwechseln des Endpunkts mit der sichtbaren IP.

Was normalerweise nicht ändert von Ihrer Seite:

• Der Proxy-Hostname

• Der Port

• Ihr Authentifizierungsmuster

• Ihr Anwendungscodepfad

Was sich ändert von der Seite des Ziels:

• Die scheinbare Client-IP

• Manchmal die Region, ASN oder das Mobilfunknetzprofil, abhängig vom Pool

• Das Korrelationssignal, das die Seite verwendet, um Ihre Anfragen zu gruppieren

Rotieren Sie die Netzwerkidentität, wenn die Seite Anfragen korreliert. Halten Sie die Sitzungsidentität stabil, wenn die Seite eine Benutzerreise verfolgt.

Dieser letzte Satz ist wichtiger als die grundlegende Definition. Viele Teams verstehen, was rotierende Proxys sind. Weniger Teams wählen ein Rotationsverhalten, das zur Aufgabe passt.

Wählen Sie Ihre Rotationsstrategie

Die nützlichste Unterscheidung liegt nicht zwischen „rotierend“ und „nicht rotierend“. Es ist der Unterschied zwischen Pro-Anfrage-Rotation und Sticky-Session-Rotation. Das ist die Entscheidung, die beeinflusst, ob Ihre Jobs sauber abgeschlossen werden oder mitten im Prozess fehlschlagen.

Pro-Anfrage-Rotation

Die Pro-Anfrage-Rotation ändert die IP bei jeder Anfrage. Laut Webshares Erklärung zu rotierenden Proxys maximiert dieses Modell die Anonymität, während Sticky Sessions eine IP für ein definiertes Zeitfenster wie 1, 10 oder 30 Minuten beibehalten, wenn Kontinuität wichtig ist.

Verwenden Sie die Pro-Anfrage-Rotation, wenn jede Anfrage für sich allein stehen kann. Das bedeutet normalerweise Sammeljobs, bei denen das Abrufen einer Seite nicht von dem vorherigen Seitenabruf abhängt, der dieselbe Netzwerkidentität teilt.

Gute Passungen:

• Breites Web-Scraping über viele Seiten

• Sammlung von Suchergebnissen

• Öffentliche Datenabrufe, bei denen der Zustand nicht wichtig ist

• Hochvolumige Abrufe, bei denen eine IP schnell ratenbegrenzt wird

Schlechte Passungen:

• Kontoanmeldungen

• Checkout-Prozesse

• Mehrstufige Formulare

• Soziale Aktionen, die an eine aktive Sitzung gebunden sind

Die Falle ist offensichtlich, sobald Sie sie in Protokollen gesehen haben. Eine Anmeldung landet auf einer IP, die nächste Anfrage kommt von einer anderen, und die Plattform behandelt es wie eine Kontohandübertragung oder eine gehackte Sitzung.

Sticky-Session-Rotation

Sticky Sessions behalten die gleiche IP für ein begrenztes Zeitfenster und rotieren später. Dies ist der Modus, den die Leute häufiger für soziale Medienoperationen, Affiliate-Flows, Browserautomatisierung und QA-Sitzungen wählen sollten.

Verwenden Sie die Sticky-Rotation, wenn das Ziel glauben muss, dass derselbe Benutzer über mehrere Schritte hinweg noch vorhanden ist. Eine stabile IP wird nicht alles lösen, aber ohne sie sind viele zustandsabhängige Workflows von Anfang an zum Scheitern verurteilt.

Sticky Sessions sind normalerweise die richtige Wahl für:

• Einloggen in ein Dashboard und Abschluss von Aktionen

• Ausfüllen von mehrseitigen Formularen

• Testen von Benutzerreisen, die von Kontinuität abhängen

• Verwalten von sozialen Konten, bei denen die Konsistenz der Identität wichtig ist

Rotationsstrategie Trade-Offs

Wie man schnell entscheidet

Wenn ich einen Automatisierungsplan überprüfe, stelle ich drei betriebliche Fragen:

• Hat die Aufgabe eine Sitzungsgrenze? Wenn ja, starte sticky.

• Kann jede Anfrage unabhängig fehlschlagen, ohne den gesamten Job zu brechen? Wenn ja, könnte pro-Anfrage gut funktionieren.

• Ist das Ziel empfindlicher gegenüber Volumen- oder Identitätsinkonsistenz? Volumendruck drängt zu mehr Rotation. Identitätsempfindliche Abläufe drängen zu mehr Stabilität.

Wenn der Browser wie ein Benutzer agieren soll, lass das Netzwerk nicht wie fünf verschiedene Benutzer in derselben Minute agieren.

Es gibt auch eine Kontrollfrage. Einige Anbieter rotieren nach einem Timer, einige pro Anfrage, und einige zeigen beide Muster. Zeitgesteuerte Rotation ist nützlich, wenn du ein stabiles Fenster möchtest, ohne manuell Sitzungslogik in der Anwendungsschicht zu erzwingen. Pro-Anfrage-Rotation ist nützlich, wenn du möchtest, dass der Anbieter die Fluktuation automatisch behandelt.

Was nicht funktioniert, ist die Verwendung einer Standardrichtlinie für jeden Job. Teams tun das, weil es einfach ist, einmal zu konfigurieren. Dann verbringen sie Wochen mit dem Debuggen von Kontoproblemen, die tatsächlich Fehler in der Sitzungsrichtlinie sind.

Erweiterte Sitzungs- und Fingerabdruckverwaltung

IP-Rotation löst einen Erkennungsvektor. Sie löst nicht die Identitätskonsistenz von selbst. Moderne Anti-Missbrauchssysteme vergleichen mehr als nur die Quelladresse, insbesondere auf sensiblen Plattformen und authentifizierten Abläufen.

Eine IP ist nur ein Teil der Identität

Denke in Bezug auf Sitzungsidentität, nicht nur IP. Eine Sitzungsidentität umfasst die Netzwerkroute, Cookies, Anfrage-Header, Browser-Fingerabdruck und den Rhythmus der Benutzeraktionen. Wenn diese Teile nicht übereinstimmen, wird dich die Rotation der IP nicht retten.

Häufige Unstimmigkeiten, die Probleme auslösen:

• Eine neue IP erscheint, aber die gleichen Cookies bleiben auf eine Weise bestehen, die unplausibel aussieht

• Header ändern sich unvorhersehbar zwischen Anfragen

• Ein headless Browser zeigt einen seltsamen Fingerabdruck, während die IP wie eine normale Benutzerverbindung aussieht

• Das Konto führt Aktionen schneller und konsistenter aus, als es eine menschliche Sitzung tun würde

Hier sieht viel Automatisierung amateurhaft aus. Der Ingenieur rotiert IPs, lässt aber jedes andere Signal statisch oder unrealistisch.

Wann die Rotation stoppen sollte

Die meisten Erklärungen konzentrieren sich darauf, wie Rotation funktioniert. Betriebliche ist die wichtigere Frage wann man eine Weile aufhören sollte zu rotieren. Für soziale Medien, Affiliate-Trichter und QA ist die Dauer der Stabilität oft wichtiger als die maximale Fluktuation. Die Sitzungsdokumentation von Bright Data hebt den Trade-off deutlich hervor: Wenn eine Sitzung länger als 5 Minuten inaktiv ist, kann die nächste Anfrage an einen anderen Proxy weitergeleitet werden, was Workflows unterbrechen kann, die Kontinuität benötigen, wie in der API-Referenz zur Proxy-Rotation von Bright Data beschrieben.

Das ist in der Praxis wichtig, weil viele Teams nur den glücklichen Weg testen. Sie melden sich an, klicken einmal und nehmen an, dass die Einrichtung in Ordnung ist. In der Produktion pausieren Benutzer, Seiten warten auf Skripte, Genehmigungen erfolgen und Aktionen verteilen sich über die Zeit. Wenn deine sticky-Richtlinie kürzer ist als der Workflow, bricht die Sitzung mitten im Fluss zusammen.

Ein stabiler Anmeldefluss benötigt Konsistenz über IP, Cookies, Header und Browserprofil. Breche eines davon und die Seite beginnt, schwierigere Fragen zu stellen.

Ein funktionierendes Betriebsmodell

Für empfindliche Automatisierung halte diese innerhalb einer Sitzung ausgerichtet:

• Cookies bleiben angehängt an derselben Aufgabeninstanz.

• Header bleiben kohärent mit dem Browser oder HTTP-Client, den du verwendest.

• Fingerabdruckeinstellungen bleiben stabil für diese Sitzung, anstatt jede Anfrage zu randomisieren.

• IP-Rotation erfolgt an Sitzungsgrenzen, es sei denn, die Aufgabe ist zustandslos.

Für Scraping kannst du oft mit einem dünneren Identitätsmodell auskommen. Für Kontoarbeiten kannst du das normalerweise nicht.

Implementierung und Test deiner Rotation

Ein rotierender Endpunkt ist einfach zu integrieren. Der schwierigere Teil ist zu bestätigen, dass er sich so verhält, wie das Projekt es benötigt. Vertraue nicht nur auf die Beschreibung des Dashboards. Teste den Endpunkt gegen einen einfachen IP-Echo-Dienst und beobachte, ob die IP sich pro Anfrage ändert oder innerhalb deines gewählten Fensters stabil bleibt.

Ein einfaches Python-Beispiel

Dieses Beispiel sendet wiederholte Anfragen über einen Proxy-Endpunkt und gibt die sichtbare öffentliche IP zurück, die vom Zielservice zurückgegeben wird.

import requests
import time

proxy = "http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT"
proxies = {
    "http": proxy,
    "https": proxy,
}

for i in range(5):
    r = requests.get("https://ifconfig.me", proxies=proxies, timeout=30)
    print(f"Anfrage {i + 1}: {r.text.strip()}")
    time.sleep(2)

Wenn der Endpunkt für die pro-Anfrage-Rotation konfiguriert ist, solltest du unterschiedliche Ausgaben über die Aufrufe hinweg sehen. Wenn er sticky ist, solltest du normalerweise die gleiche Ausgabe während des aktiven Sitzungsfensters sehen.

Ein schneller curl-Test

Für einen schnellen Terminaltest führe dasselbe Ziel ein paar Mal über den Proxy aus:

curl -x http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT https://ifconfig.me
curl -x http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT https://ifconfig.me
curl -x http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT https://ifconfig.me

Das beweist nicht, dass die Einrichtung produktionsbereit ist, aber es bestätigt das grundlegende Routing-Verhalten.

Was du überprüfen solltest, bevor du der Einrichtung vertraust

Überprüfe mehr als nur „die IP hat sich geändert.“

• Überprüfe das Sitzungsverhalten: Wenn du Stabilität benötigst, bestätige, dass die IP während der gesamten Aktionssequenz stabil bleibt, nicht nur bei zwei schnellen Anfragen.

• Beobachte Leerlaufpausen: Pausiere zwischen den Schritten und sieh, ob die Sitzung weiterhin hält.

• Teste den Produktionsclient: Wenn die Produktion Playwright, Selenium oder einen benutzerdefinierten HTTP-Stack verwendet, teste mit diesem Client. Validere nicht nur mit curl und gehe davon aus, dass der Browserfluss übereinstimmt.

• Protokolliere den Anfragekontext: Speichere Zeitstempel, Sitzungs-IDs und die beobachtete externe IP, damit du später Breakpoints nachverfolgen kannst.

Eine überraschend hohe Anzahl von Fehlern resultiert daraus, dass diese Phase übersprungen wird. Das Team geht davon aus, dass die Rotation korrekt erfolgt, und verbringt dann Zeit damit, die Zielseite zu beschuldigen, wenn das tatsächliche Problem eine Diskrepanz zwischen der konfigurierten Richtlinie und dem Workflow ist.

Optimierung der Rotation mit EVOproxy

Ein sozialer Login, der auf einer IP beginnt und auf einer anderen endet, wird oft markiert, bevor das Skript seine beabsichtigte Aufgabe erreicht. Die Lösung ist nicht „mehr Rotation.“ Die Lösung besteht darin, eine Rotation zu wählen, die zum Job passt, und dann den Sitzungsstatus genau so lange intakt zu halten, wie der Job es benötigt.

Mit EVOproxy sind die nützlichen Steuerungen einfach. Du kannst nach einem Timer rotieren oder eine IP-Änderung auf Anfrage erzwingen. Das gibt dir genug Flexibilität, um sehr unterschiedliche Workflows auszuführen, ohne Scraping, QA und Kontoaktionen als dasselbe Netzwerkproblem zu behandeln.

Wie man Einstellungen auf den Job abbildet

Beginne mit der Sitzungsgrenze. Definiere den genauen Punkt, an dem eine Aufgabe eine neue IP tolerieren kann.

1. Zustandslose Sammlung
   Verwende kurze zeitgesteuerte Rotation. Dies passt zu Jobs, bei denen jede Anfrage für sich steht und eine neue IP die Kontinuität nicht bricht.

2. Zustandsbehaftete Browseraufgaben
   Halte die IP stabil für die gesamte Aktionskette. Anmeldung, MFA, Seitenübergänge und Aktionen nach der Anmeldung sollten auf derselben Netzwerkidentität bleiben, es sei denn, die Plattform toleriert Änderungen eindeutig.

3. Kontrollierte Test-Szenarien
   Verwenden Sie manuelle Rotation an bekannten Kontrollpunkten. QA-Arbeiten profitieren von vorhersehbarem Wechsel, da Sie Fehler reproduzieren und nicht in zufälligem Wechsel verstecken möchten.

Diese Unterscheidung ist wichtiger als der Proxy-Typ selbst. Ein schwacher Rotationsplan mit guten IPs wird trotzdem blockiert. Ein Rotationsplan, der auf den Arbeitsablauf abgestimmt ist, funktioniert in der Regel besser, selbst bevor Sie mit der Feinabstimmung von Parallelität oder Wiederholungslogik beginnen.

Empfehlungen für Anwendungsfälle

Für soziale Medienarbeit verwenden Sie eine sticky Session, die lange genug dauert, um den gesamten Block von Kontoaktionen abzuschließen. Dazu gehören Anmeldung, Aufwärm-Navigation, Posten und alle nachfolgenden Überprüfungen. Wenn das Tool zwischen den Schritten pausiert, lassen Sie genug Spielraum, damit die Session nicht mitten im Lauf abläuft. Sitzungsunterbrechungen während der Kontowartung sind eine der schnellsten Möglichkeiten, eine Überprüfung auszulösen.

Für QA-Tests verwenden Sie eine bedarfsorientierte Rotation, um eine spezifische Bedingung zu schaffen. Ändern Sie die IP vor einem Checkout-Schritt, nach der Authentifizierung oder während eines Wiederverbindungs-Szenarios und zeichnen Sie auf, wie die Anwendung reagiert. Dieses Setup ist nützlich, wenn Sie Betrugsprüfungen, Sitzungswiederherstellung, geoabhängige Inhalte oder Timeout-Handling testen.

Für Web-Scraping und Marktforschung funktioniert eine kürzere zeitgesteuerte Rotation in der Regel besser, aber nur, wenn die Anfragen unabhängig sind. Wenn das Ziel die Paginierung, Warenkörbe, Ratenbuckets oder lokalisierte Inhalte miteinander verknüpft, halten Sie die Sitzung länger. Teams überrotieren hier oft und fragen sich dann, warum die Datenqualität sinkt, obwohl die Blockraten besser aussehen.

Eine Regel hilft in allen drei Fällen. Rotieren Sie die IP nur an einer Grenze, an der Cookies, Header und die nächste Anfrage weiterhin zusammen sinnvoll sind.

Die zeitgesteuerte Rotation und die bedarfsorientierten Änderungsoptionen von Evoproxy sind nützlich, da sie es Ihnen ermöglichen, diese Grenze selbst zu wählen, anstatt eine einzige Standardrichtlinie zu akzeptieren. Für soziale Abläufe bedeutet das in der Regel einen persönlichen Port mit genügend Haftung, um den Arbeitsablauf sauber abzuschließen. Für QA bedeutet es erzwungene Änderungen an genauen Kontrollpunkten. Für breitere Sammlungen bedeutet es kürzere Intervalle mit einer Sitzungsdauer, die auf die Toleranz des Ziels abgestimmt ist.

Eine gute Rotationsrichtlinie sollte in den Hintergrund treten. Wenn das Team ständig Abmeldungen, Herausforderungsseiten oder einen fehlerhaften Zustand nach einer IP-Änderung debuggt, kämpfen die Rotations Einstellungen immer noch gegen den Arbeitsablauf, anstatt ihn zu unterstützen.

Häufige Fallstricke und wie man sie vermeidet

Die meisten Proxy-Fehler resultieren aus einer kleinen Anzahl von Fehlern. Die Lösung ist in der Regel einfach, sobald Sie aufhören, jeden Arbeitsablauf gleich zu behandeln.

• Verwendung von per-Anfrage-Rotation für einen Anmeldefluss: Wenn die Aufgabe Authentifizierung und nachfolgende Aktionen umfasst, halten Sie die IP für die gesamte Sitzung stabil.

• Verwendung von sticky Sessions für aggressives Scraping standardmäßig: Wenn Anfragen unabhängig sind und Ratenlimits das Hauptproblem darstellen, verkürzen Sie die Sitzung oder rotieren Sie pro Anfrage.

• Ignorieren von Cookies und Browser-Konsistenz: Halten Sie Cookies, Header und Fingerabdruckverhalten mit der Sitzung in Einklang, anstatt nur die IP zu rotieren.

• Vergessen von Leerlaufzeiten: Ein Arbeitsablauf, der pausiert, kann das sticky Fenster überschreiten und zu einem ungünstigen Zeitpunkt eine neue IP erhalten.

• Überspringen der Validierung: Testen Sie den Endpunkt mit wiederholten Aufrufen und bestätigen Sie, dass das beobachtete Verhalten mit der beabsichtigten Richtlinie übereinstimmt.

• Die falsche Geografie für den Anwendungsfall wählen: Wenn die Plattform oder der Testfall regionssensitiv ist, wählen Sie einen Pool, der dem erwarteten Standort des Benutzers entspricht.

Die stärkste Gewohnheit ist einfach. Bevor Sie starten, notieren Sie die Sitzungsgrenze für die Aufgabe. Konfigurieren Sie dann die Rotation um diese Grenze, nicht um eine allgemeine Vorstellung von Anonymität.

Wenn Sie französische mobile Proxy-Infrastruktur für soziale Medienoperationen, QA-Flows, Affiliate-Tests oder Kontowork benötigen, Evoproxy bietet zeitgesteuerte Rotation von einer bis fünf Minuten und bedarfsorientierte IP-Änderungen, die zum oben beschriebenen Sitzungssteuerungsansatz passen.