So behältst du Session, Cookies und Tokens bei IP-Rotation: Schritt-für-Schritt-Anleitung

Du kennst das sicher: Das Skript läuft, du meldest dich auf der Website an, legst ein Produkt in den Warenkorb – und dann wechselt die IP. Plötzlich tut der Server so, als wärst du zum ersten Mal da. Du bist ausgeloggt, der Warenkorb ist leer, das Token ist ungültig. Nervig? Allerdings. Aber für dieses Problem gibt es eine klare technische Lösung, und in diesem Guide gehen wir sie von Anfang bis Ende durch.

Einleitung: Warum du nach einem IP-Wechsel ausgeloggt wirst und der Warenkorb leer ist

Seien wir ehrlich: Wenn die Session nach einer IP-Rotation fliegt, ist der erste Impuls, dem IP-Wechsel die Schuld zu geben. Also: Die IP hat sich geändert, der Server hat das gesehen und alles zurückgesetzt. Manchmal stimmt das sogar. Aber viel häufiger liegt das Problem nicht an der IP selbst, sondern an deinem Code. Er vermischt den Zustand verschiedener Sessions, verliert Cookies oder schickt alte Tokens von der neuen Adresse aus. Wir zeigen dir, wie du das verhinderst.

Was du am Ende können wirst

Am Ende dieser Anleitung kannst du Folgendes: Erstens verstehst du, was serverseitig wirklich an die IP gebunden ist und was ein Mythos ist. Zweitens baust du eine klare Zuordnungsregel auf: Eine logische Session entspricht genau einem Cookie-Satz und genau einer IP. Drittens schreibst du funktionierenden Code in Python und Node.js, der den Zustand zwischen verschiedenen Proxys isoliert und keine Daten durcheinanderbringt. Viertens speicherst du den Zustand zwischen Programmläufen und weißt, wann du ihn besser verwirfst.

Für wen dieser Guide ist

Der Guide richtet sich an Fortgeschrittene. Du schreibst bereits Code in Python oder JavaScript, weißt, was ein HTTP-Request ist, und kannst dir etwas unter Proxys vorstellen. Wir besprechen nicht, welche Art von Rotation du wählen sollst – dafür gibt es separate Materialien. Hier gehen wir davon aus, dass die IP-Rotation bereits nach deinen Regeln läuft, und lösen genau eine Aufgabe: Wie verlierst du bei dieser Rotation nicht den Zustand.

Was du vorher wissen solltest

Es hilft, die Grundlagen zu kennen. Ein Cookie ist ein kleines Datum, das der Server den Browser oder Client bitten, sich zu merken und bei jeder Anfrage zurückzuschicken. Eine Session ist die Methode des Servers, dich zwischen Anfragen wiederzuerkennen. Ein Token ist eine Zeichenkette, die deine Identität oder dein Recht auf eine Aktion bestätigt. Wenn diese Begriffe noch vage sind, keine Sorge: Im Abschnitt zu den Grundlagen erklären wir jeden einfach und verständlich.

Wie viel Zeit du einplanen solltest

Zum Lesen und Verstehen der Theorie brauchst du etwa vierzig Minuten. Zum Durcharbeiten und Ausführen des Codes in deiner Sprache kommen noch ein bis anderthalb Stunden dazu. Wenn du alles mit Experimenten an echten Aufgaben vertiefst, sind es zwei bis drei Stunden. Mach keinen Stress. Lieber das Prinzip langsam verstehen, als schnell Code zu kopieren, der später auf unerklärliche Weise kaputtgeht.

Vorbereitung: Werkzeuge und Umgebung

Bevor wir Code schreiben, richten wir deine Arbeitsumgebung ein. Das dauert etwas, spart dir aber später Stunden beim Debuggen.

Was du brauchst

• Python 3.10 oder neuer – wenn du mit Python arbeitest. 2026 sind die Versionen 3.12 und 3.13 aktuell, aber alles hier Beschriebene funktioniert ab 3.10.
• Node.js 20 LTS oder neuer – wenn du mit JavaScript arbeitest. Node 22 LTS geht auch.
• Proxy mit IP-Rotation – du solltest bereits Zugang zu einem Adresspool haben. Der Verbindungsaufbau hat üblicherweise dieses Format: Protokoll, Host, Port, Benutzername und Passwort.
• Code-Editor – irgendeiner reicht, zum Beispiel ein kostenloser Editor mit Syntax-Hervorhebung.
• Terminal oder Kommandozeile – zum Installieren von Bibliotheken und Ausführen von Skripten.

Systemvoraussetzungen

Die Anforderungen sind bescheiden. Jeder moderne Computer schafft das. Vom Arbeitsspeicher reichen vier Gigabyte, aber wenn du viele parallele Sessions planst, nimm besser acht oder mehr. Wichtiger ist eine stabile Internetverbindung, denn bei Verbindungsabbrüchen können Cookies sonst nicht korrekt gespeichert werden.

Was du installieren musst

Für Python installierst du zwei Bibliotheken. Öffne das Terminal und führe den Befehl zum Installieren des Pakets requests und des Pakets für die Proxy-Verwaltung aus. Das sieht so aus: erst der Installationsbefehl des Paketmanagers, dann der Name requests. Für die Serialisierung des Zustands reicht das Standardmodul, das musst du nicht extra installieren.

Für Node.js installierst du drei Pakete: axios für Anfragen, tough-cookie für das Cookie-Storage und https-proxy-agent für die Verbindung über einen Proxy. Alle drei werden mit einem einzigen Paketinstallations-Befehl in deinem Projekt installiert.

Tipp: Lege für das Projekt einen separaten virtuellen Ordner an. In Python ist das eine virtuelle Umgebung, in Node.js ein eigenes Verzeichnis mit einer Abhängigkeitsdatei. So vermischst du nicht die Bibliotheken verschiedener Projekte und vermeidest Versionskonflikte.

Backups erstellen

Wenn du Cookies bereits in Dateien oder einer Datenbank speicherst, mach vor den Experimenten eine Kopie. Wir ändern die Serialisierungslogik, und dabei könnten bestehende Daten beschädigt werden. Kopiere einfach den Ordner mit den gespeicherten Zuständen an einen Ort mit dem Hinweis backup.

Check: Nach der Installation solltest du prüfen, ob alles läuft. Starte im Terminal einen kurzen Versionscheck für Python oder Node.js. Du solltest die Versionsnummer ohne Fehler sehen. Danach versuche, die installierten Bibliotheken im interaktiven Modus zu importieren – wenn der Import still passiert, ist alles bereit.

Grundlagen: Was wirklich an der IP hängt und was Mythos ist

Das ist der wichtigste theoretische Abschnitt. Solange du nicht verstehst, was wirklich mit der IP zusammenhängt, behandelst du die falsche Krankheit. Wir gehen die Datentypen der Reihe nach durch.

Cookie-Session

Eine Cookie-Session entsteht, wenn der Server dir eine Session-ID als Cookie ausstellt und den Zustand selbst speichert. Zum Beispiel ein Cookie mit dem Namen sessionid und einer langen Zufallszeichenfolge. Anhand dieser Zeichenfolge findet der Server deinen Datensatz in seinem Speicher. Hängt dieser Mechanismus an der IP? Für sich genommen: nein. Das Cookie funktioniert unabhängig von der Adresse. Aber viele Dienste bauen eine zusätzliche Prüfung ein: Sie merken sich, von welcher IP die Session erstellt wurde. Kommt eine Anfrage mit demselben Cookie von einer anderen Adresse, gilt das als verdächtig. Genau dann wirst du ausgeloggt.

CSRF-Token

Ein CSRF-Token schützt vor gefälschten Anfragen. Der Server gibt dir ein Token, das du beim Absenden eines Formulars oder einer wichtigen Aktion wieder mitschicken musst. Dieses Token hängt fast nie an der IP. Es ist mit der Session verbunden, nicht mit der Adresse. Das Problem entsteht aus einem anderen Grund: Wenn du das Session-Cookie verloren hast, wird auch das CSRF-Token ungültig, weil der Server es keiner Session zuordnen kann. Das Problem ist also sekundär – eine Folge des Cookie-Verlusts.

JWT

JWT ist ein Token, das Informationen in sich trägt und vom Server signiert ist. Der Client speichert es und schickt es bei jeder Anfrage im Header mit. Ein klassisches JWT ist überhaupt nicht an die IP gebunden. Es ist in sich abgeschlossen: Der Server prüft Signatur und Ablaufdatum, die Adresse ist ihm egal. Es gibt aber Implementierungen, bei denen der Server das Token zusätzlich an eine IP koppelt oder die Adresse ins Token schreibt. In solchen Fällen zerbricht ein IP-Wechsel die Prüfung. Das ist keine Eigenschaft von JWT, sondern eine Entscheidung des jeweiligen Dienstes.

Serverseitige Session

Eine serverseitige Session ist der Oberbegriff für den Zustand, den der Server bei sich speichert und mit deiner ID verbindet. Warenkorb, Verlauf, Anmeldestatus – all das liegt oft in der serverseitigen Session. Ob die IP hier eine Rolle spielt, hängt von den Einstellungen des Dienstes ab. Manche binden die Session aus Sicherheitsgründen fest an die erste IP. Andere sind tolerant gegenüber Adresswechseln. In der Regel weißt du das vorher nicht, also baust du den Code so, als gäbe es die Bindung – das ist die sichere Strategie.

Warenkorb

Der Warenkorb ist ein Sonderfall der serverseitigen Session oder ein Cookie. In einfachen Shops liegt der Warenkorb als Cookie direkt beim Client. In komplexen Shops liegt er auf dem Server, an die Session gebunden. Wenn der Warenkorb nach einem IP-Wechsel leer ist, war er an eine serverseitige Session gebunden, die die Adresse prüft. Die Lösung ist dieselbe: Ändere die IP innerhalb einer logischen Session nicht – oder speichere den kompletten Cookie-Satz sauber.

Fazit: Wo die IP wirklich eine Rolle spielt

Schauen wir uns das Gesamtbild an. Die HTTP-Mechanismen Cookies, CSRF und JWT sind nicht an die IP gebunden. Die Bindung entsteht als zusätzliche Prüfung beim Dienst, und du kannst sie nicht steuern. Das Einzige, was du steuern kannst, ist die Zuordnung zwischen Session, Cookie-Satz und IP auf deiner Seite. Daraus ergibt sich die wichtigste Regel dieses Guides.

Check: Überprüfe dein Verständnis. Wenn die Session nach einem IP-Wechsel fliegt, aber bei der Rückkehr zur alten IP alles wieder funktioniert, prüft der Server die Adresse streng. Wenn sie sich auch auf der alten IP nicht erholt, hast du die Cookies im Code einfach verloren. Das sind zwei verschiedene Diagnosen mit verschiedenen Behandlungen.

Schritt 1: Die Zuordnungsregel formulieren

Ziel dieses Schritts: Das wichtigste Prinzip verankern und verstehen, wie du es in der Codestruktur umsetzt.

Die Regel klingt einfach: Eine logische Session entspricht einem Cookie-Satz und einer IP. Schauen wir uns an, was das in der Praxis bedeutet.

1. Eine logische Session ist eine Kette von Anfragen, die eine zusammenhängende Arbeit darstellen: reingehen, anmelden, etwas tun, rausgehen. Das alles ist eine logische Session.
2. Ein Cookie-Satz ist ein separates Cookie-Storage, das nur zu dieser logischen Session gehört und zu sonst niemandem.
3. Eine IP bedeutet: Innerhalb einer logischen Session ändert sich die Adresse nicht. Falls doch eine Rotation passiert, gilt die logische Session als beendet.

Wie setzt du das im Code um? Ganz anschaulich: Du erstellst ein Container-Objekt, das sowohl das Cookie-Storage als auch die Proxy-Konfiguration enthält. Solange dieses Objekt lebt, lebt die logische Session. Wenn es Zeit für einen IP-Wechsel ist, erstellst du entweder einen neuen Container – oder, falls der Dienst tolerant gegenüber Adresswechseln ist, überträgst du die Cookies vorsichtig in einen neuen Container mit neuer IP.

⚠️ Achtung: Der häufigste Architekturfehler ist, einen gemeinsamen Cookie-Satz zu speichern und verschiedene Proxys daranzuhängen. Das garantiert, dass alles zerbricht. Verschiedene logische Sessions überschreiben gegenseitig ihre Cookies, und der Server bekommt widersprüchliche Daten. Mach das niemals.

Tipp: Stell dir die logische Session wie einen Menschen vor. Ein Mensch hat einen Ausweis (Cookies) und ein Zuhause (IP). Es geht nicht, dass zwei Menschen denselben Ausweis benutzen, und es geht nicht, dass ein Mensch gleichzeitig in zwei Häusern wohnt. Diese Analogie bewahrt dich vor den meisten Fehlern.

Check: Zeichne deine zukünftige Struktur auf Papier. Du solltest mehrere unabhängige Blöcke bekommen, jeder mit eigenem Cookie-Storage und eigenem Proxy. Zwischen den Blöcken gibt es keine gemeinsamen Daten. Wenn das so ist, hast du die Regel verstanden.

Schritt 2: Praxis mit Python – eine Session pro Proxy

Ziel dieses Schritts: Funktionierenden Code schreiben, in dem jede logische Session ihr eigenes requests.Session-Objekt, ihren eigenen CookieJar und ihren eigenen Proxy hat – voneinander isoliert.

In der Bibliothek requests gibt es das Session-Objekt. Es ist selbst ein Container: Es enthält das Cookie-Storage und kann Einstellungen auf alle Anfragen anwenden. Das ist die ideale Basis für unsere logische Session.

Grundstruktur

1. Erstelle eine Funktion, die die Daten eines Proxys entgegennimmt und ein fertiges Session-Objekt zurückgibt.
2. Innerhalb der Funktion erstellst du ein neues Session-Objekt.
3. Setze die proxies-Einstellung des Objekts – ein Wörterbuch mit der Proxy-Adresse für die Protokolle http und https.
4. Gib das Objekt zurück. Jetzt hast du einen isolierten Container.

Der Code sieht so aus. Zeile für Zeile: Wir importieren requests. Wir definieren die Funktion make_session, die eine Zeichenkette proxy_url entgegennimmt. Innen schreiben wir s = requests.Session(). Dann s.proxies = ein Wörterbuch, in dem der Schlüssel http auf proxy_url zeigt und der Schlüssel https auf proxy_url. Am Ende return s. Fertig ist die Funktion.

Warum das den Zustand isoliert

Jeder Aufruf von make_session erzeugt ein völlig neues Objekt. Das neue Objekt hat sein eigenes internes Cookie-Storage, den sogenannten CookieJar. Cookies, die eine Session erhält, können physisch nicht in eine andere Session gelangen, weil es verschiedene Objekte im Speicher sind. Genau das wollten wir erreichen.

Session verwenden

1. Hole dir das Session-Objekt, indem du die Funktion mit dem gewünschten Proxy aufrufst.
2. Führe Anfragen über die Methoden dieses Objekts aus: s.get oder s.post.
3. Cookies, die der Server im Header Set-Cookie schickt, werden automatisch im Objekt gespeichert.
4. Bei den nächsten Anfragen über dasselbe Objekt werden diese Cookies automatisch zurückgeschickt.

Tipp: Erstelle nicht für jede einzelne Anfrage innerhalb einer logischen Session eine neue Session. Dann sammeln sich die Cookies nicht an. Erstelle das Objekt einmal für die gesamte logische Session und nutze es für alle Anfragen dieser Session.

Isolation zwischen Threads

Wenn du mit mehreren Threads arbeitest, muss jeder Thread sein eigenes Session-Objekt haben. Das Session-Objekt ist nicht threadsicher. Das heißt: Wenn zwei Threads gleichzeitig Cookies in dasselbe Objekt schreiben, können die Daten beschädigt werden.

1. Nutze den Mechanismus für thread-lokale Daten. In Python ist das das Objekt threading.local.
2. Beim Start jedes Threads erstellst du eine separate Session und speicherst sie im lokalen Speicher des Threads.
3. Innerhalb des Threads greifst du nur auf deine eigene Session zu und fasst fremde nicht an.

In der Praxis sieht das so aus: Wir erstellen ein globales Objekt local = threading.local(). Zu Beginn der Thread-Arbeit prüfen wir, ob local das Attribut session hat. Wenn nicht, erstellen wir es mit make_session und dem Proxy, der diesem Thread zugewiesen ist. Danach verwenden wir im Thread local.session für alle Anfragen.

⚠️ Achtung: Gib niemals ein einzelnes Session-Objekt als gemeinsame Ressource zwischen Threads weiter. Selbst wenn es so aussieht, als würden die Anfragen nacheinander laufen, kann der Scheduler die Threads im ungünstigsten Moment umschalten – und du bekommst vermischte Cookies. Jeder Thread bekommt sein eigenes Objekt.

Rotation in der Logik

Wenn die IP-Rotation erfolgt ist und du eine neue Adresse brauchst, gehst du so vor: Beende die aktuelle logische Session. Wenn der Server streng an die IP gebunden ist, erstellst du einfach ein neues Session-Objekt mit neuem Proxy und beginnst auf der grünen Wiese – melde dich also neu an. Wenn der Server toleranter ist, kannst du die Cookies übertragen; dazu mehr im Schritt zur Zustandsspeicherung.

Check: Starte zwei Sessions mit verschiedenen Proxys, melde dich in jedem bei einem Testdienst an, der deine IP und Cookies anzeigt. Stelle sicher, dass jede Session ihre eigene IP und ihren eigenen Cookie-Satz sieht. Wenn sich die Daten nicht vermischen, funktioniert die Isolation korrekt.

Schritt 3: Dasselbe in Node.js

Ziel dieses Schritts: Die äquivalente Konstruktion in JavaScript mit axios, tough-cookie und dem Proxy-Agent aufbauen.

Im Node.js-Ökosystem gibt es kein fertiges Session-Objekt, also bauen wir es aus drei Teilen zusammen. Das Cookie-Storage kommt von tough-cookie. Die Verbindung über den Proxy übernimmt der Agent. Die Anfragen macht axios.

Den Container bauen

1. Importiere die Klasse CookieJar aus der Bibliothek tough-cookie.
2. Importiere die Funktion zum Erstellen des Proxy-Agents aus der Bibliothek https-proxy-agent.
3. Importiere axios.
4. Erstelle eine Funktion makeClient, die eine Proxy-Adresse entgegennimmt und ein konfiguriertes Objekt zurückgibt.

Innerhalb der Funktion erstellst du eine neue Instanz des Storages: const jar = new CookieJar(). Erstelle den Proxy-Agent, indem du ihm die Adresse übergibst: const agent = new HttpsProxyAgent(proxyUrl). Erstelle eine axios-Instanz mit den Einstellungen über axios.create, mit httpsAgent: agent und httpAgent: agent.

Automatisches Cookie-Handling anbinden

Bloßes axios kann Cookies aus Antworten nicht selbst ins Storage legen und für Anfragen wieder herausholen. Es gibt zwei Wege.

1. Erster Weg: Du nimmst einen fertigen Wrapper, der axios und tough-cookie verbindet. Er wird als separates Paket installiert. Er liest und schreibt Cookies automatisch über das übergebene jar-Storage.
2. Zweiter Weg: Du machst es manuell mit Interceptors für Anfragen und Antworten. Vor der Anfrage holst du die Cookie-Zeichenkette aus dem Storage für die gewünschte Adresse und legst sie in den Cookie-Header. Nach der Antwort nimmst du den Set-Cookie-Header und schreibst jedes Cookie ins Storage.

Tipp: Nutze anfangs den fertigen Wrapper – weniger Fehlerquellen. Den manuellen Weg hebst du dir für Fälle auf, in denen du den Prozess fein steuern musst, zum Beispiel um jedes Cookie zu loggen.

Isolation zwischen parallelen Aufgaben

In Node.js ist das Modell anders – keine Threads, sondern asynchrone Aufgaben im selben Event-Loop-Thread. Aber das Prinzip ist dasselbe: Jede logische Session hat ihr eigenes client-Objekt mit eigenem jar und eigenem Agent.

1. Rufe makeClient für jede parallele Aufgabe separat auf.
2. Speichere die Clients in einem Array oder einer Map, in der der Schlüssel die Aufgaben-ID ist.
3. Verwende niemals ein einzelnes jar für mehrere Clients gleichzeitig.

⚠️ Achtung: In asynchronem Code teilt man schnell versehentlich einen client zwischen mehreren Promise-Ketten. Dann vermischen sich Cookies zwischen logischen Sessions. Prüfe immer, dass jede Kette ihren eigenen Client nutzt, der mit einem separaten Aufruf von makeClient erstellt wurde.

Rotation in Node.js

Die Logik ist identisch mit Python. Wenn eine neue IP gebraucht wird und der Dienst die Session an die Adresse bindet, erstellst du einen neuen client mit neuem Proxy und leerem jar und meldest dich neu an. Wenn der Dienst tolerant ist, überträgst du den Inhalt des alten jar in den neuen client mit neuem Agent.

Check: Erstelle zwei Clients mit verschiedenen Proxys. Mache Anfragen an einen Testdienst, der IP und Cookies anzeigt. Stelle sicher, dass der erste Client eine IP und seine eigenen Cookies sieht, der zweite eine andere IP und seine eigenen. Es darf keine Überschneidungen geben.

Schritt 4: Zustand zwischen Programmläufen speichern

Ziel dieses Schritts: Lernen, Cookies auf der Festplatte zu speichern und beim nächsten Programmlauf wiederherzustellen – unter Berücksichtigung der Lebensdauer.

Oft muss ein Skript gestoppt und später wieder gestartet werden, ohne die Anmeldung zu verlieren. Dazu müssen die Cookies serialisiert werden – also in Text umgewandelt und in einer Datei oder Datenbank gespeichert.

Serialisierung in Python

Der CookieJar von requests lässt sich auf verschiedene Weise speichern. Am portabelsten ist es, die Cookies in ein einfaches Wörterbuch zu sammeln und als JSON zu schreiben.

1. Gehe alle Cookies des Session-Objekts über s.cookies durch.
2. Sammle für jedes Cookie Name, Wert, Domain, Pfad und Ablaufdatum.
3. Lege das in eine Liste von Wörterbüchern.
4. Schreibe die Liste als JSON in eine Datei.

Beim Wiederherstellen machst du es umgekehrt: Lies die Datei, gehe die Liste durch und füge jedes Cookie mit der Set-Cookie-Methode in ein neues Session-Objekt ein, mit Angabe von Domain und Pfad.

Tipp: Speichere zusammen mit den Cookies die Proxy-ID oder zumindest einen Hinweis, zu welcher logischen Session sie gehören. So stellst du keine fremden Cookies mit der falschen IP wieder her und verletzt nicht die Zuordnungsregel.

Serialisierung in Node.js

Die Bibliothek tough-cookie hat eine eingebaute Serialisierungsmethode. Das jar-Objekt hat eine asynchrone Methode, die das gesamte Storage in ein JSON-Objekt verwandelt. Die umgekehrte Methode stellt das jar aus diesem Objekt wieder her.

1. Rufe die Serialisierungsmethode des Storages auf und erhalte ein Objekt.
2. Wandle das Objekt in eine Zeichenkette um und speichere es in einer Datei.
3. Beim Start liest du die Datei und parst die Zeichenkette zurück in ein Objekt.
4. Stelle das jar mit der Deserialisierungsmethode wieder her, indem du das Objekt übergibst.

Das ist bequemer als in Python, weil tough-cookie selbst alle nötigen Felder speichert, inklusive Ablaufdatum und Sicherheits-Flags.

Lebensdauer von Cookies

Jedes Cookie hat ein Ablaufdatum. Es gibt Session-Cookies – sie leben bis zum Schließen des Browsers und haben kein explizites Datum. Und es gibt dauerhafte Cookies mit einem konkreten Ablaufdatum. Es ist nur sinnvoll, dauerhafte Cookies zu speichern, deren Ablaufdatum noch nicht erreicht ist. Session-Cookies sind nach einem Neustart serverseitig meistens ungültig.

1. Prüfe vor dem Speichern das Ablaufdatum jedes Cookies.
2. Verwirf die abgelaufenen.
3. Prüfe beim Wiederherstellen erneut die Ablaufdaten und lade keine abgelaufenen Cookies.

Wann du den Zustand besser verwirfst

Es lohnt sich nicht immer, an gespeicherten Cookies festzuhalten. Manchmal ist ein sauberer Neustart schneller und zuverlässiger.

• Wenn seit dem letzten Lauf viel Zeit vergangen ist, ist die Session auf dem Server sicher abgelaufen – da gibt es nichts wiederherzustellen.
• Wenn der Server bei der ersten Anfrage mit wiederhergestellten Cookies einen Autorisierungsfehler zurückgibt, wirf sie weg und melde dich neu an.
• Wenn du dir nicht sicher bist, ob die Zustandsdatei intakt ist, starte lieber auf der grünen Wiese, statt seltsames Verhalten zu debuggen.

⚠️ Achtung: Dateien mit Cookies und Tokens enthalten Zugangsdaten. Bewahre sie an einem geschützten Ort auf, lege sie nicht in ein öffentliches Repository und verschicke sie nicht über ungesicherte Kanäle. Der Verlust einer solchen Datei ist gleichbedeutend mit dem Verlust des Account-Zugangs.

Check: Speichere den Zustand, schließe das Programm vollständig, starte es neu, stelle den Zustand wieder her und mache eine Anfrage, die eine Autorisierung erfordert. Wenn der Server antwortet wie bei einem angemeldeten Benutzer, funktioniert das Speichern. Wenn du ausgeloggt wirst, prüfe die Ablaufdaten und ob Domain und Pfad korrekt wiederhergestellt wurden.

Schritt 5: Häufige Architekturfehler verstehen

Ziel dieses Schritts: Drei Hauptfehler im Detail durchgehen, damit du sie in deinem Code erkennst und vermeidest.

Fehler 1: Ein gemeinsamer CookieJar für alle Proxys

Das ist die Wurzel allen Übels. Ein Entwickler erstellt ein einziges Cookie-Storage und hängt verschiedene Proxys daran, um zu sparen. Was passiert: Cookies von der Session auf der ersten IP landen in der Anfrage auf der zweiten IP. Der Server sieht ein Cookie, das unter einer anderen Adresse erstellt wurde, und setzt entweder die Session zurück oder hält das Verhalten für verdächtig.

Die Lösung ist einfach: Jeder Proxy bekommt sein eigenes Cookie-Storage. Keine Ausnahmen. Das haben wir in den Code-Schritten bereits verankert: eine separate Session oder ein separater Client mit eigenem jar für jede logische Session.

Fehler 2: Race Condition bei parallelen Anfragen

Eine Race Condition entsteht, wenn zwei Operationen gleichzeitig auf dieselben Daten zugreifen und sich gegenseitig stören. Wenn zwei Threads in denselben CookieJar schreiben, kann ein Schreibvorgang den anderen überschreiben. Ergebnis: Ein Teil der Cookies geht zufällig verloren, und der Fehler tritt nur manchmal auf – das ist eine Qual beim Debuggen.

1. Gib jedem Thread seine eigene Session über die Thread-lokalen Daten, wie wir es beschrieben haben.
2. Teile in asynchronem Code einen Client nicht zwischen unabhängigen Aufgabenketten.
3. Wenn das Objekt aus irgendeinem Grund doch gemeinsam genutzt wird, verwende eine Sperre (Lock), damit zu jedem Zeitpunkt nur ein Thread damit arbeitet.

Tipp: Der beste Weg, eine Race Condition zu vermeiden, ist, gar keine gemeinsamen veränderlichen Daten zu haben. Die Isolation nach logischen Sessions löst das Problem an der Wurzel: Wenn Daten nicht gemeinsam sind, kann es keine Race Condition geben.

Fehler 3: Set-Cookie bei Redirects verlieren

Wenn der Server mit einer Weiterleitung antwortet, setzt er oft gleich in dieser Antwort wichtige Cookies über den Header Set-Cookie. Manche Client-Konfigurationen verlieren diese Cookies beim automatischen Verfolgen des Redirects – sie landen nicht im Storage.

1. Stelle sicher, dass dein Client Cookies auf jedem Schritt der Redirect-Kette speichert, nicht nur in der finalen Antwort.
2. In requests funktioniert das standardmäßig, wenn du das Session-Objekt verwendest – Cookies werden unterwegs gesammelt. Prüfe, dass du das Redirect-Folgen nicht unnötig deaktiviert hast.
3. In axios verarbeitest du bei manueller Cookie-Arbeit Set-Cookie auf jeder Zwischenantwort. Wenn du einen Wrapper verwendest, prüfe, ob er Redirects abfängt.

⚠️ Achtung: Wenn die Anmeldung klappt, aber die nächste Anfrage dich ausloggt, liegt das oft genau an einem beim Redirect verlorenen Cookie. Aktiviere das Logging aller Set-Cookie-Header und schau nach, ob alle erwarteten Cookies im Storage angekommen sind.

Check: Suche auf dem Zieldienst eine Aktion, die einen Redirect auslöst, zum Beispiel das Einloggen über ein Formular. Verfolge die Kette und vergleiche die Cookies nach jedem Schritt. Alle ausgegebenen Cookies sollten in deinem Storage landen. Wenn eines fehlt, hast du das Leck gefunden.

Schritt 6: Alles in einen Workflow zusammenführen

Ziel dieses Schritts: Das Gelernte zu einem vorhersehbaren Workflow von Start bis Rotation zusammenführen.

Jetzt hast du alle Bausteine. Fügen wir sie zu einer wiederholbaren Aktionskette zusammen.

1. Nimm einen Proxy aus deinem Pool und erstelle darunter eine isolierte logische Session – in Python eine Session, in Node.js einen Client.
2. Wenn es für diese logische Session einen gespeicherten Zustand gibt und er nicht abgelaufen ist, stelle die Cookies wieder her. Sonst melde dich neu an.
3. Führe die gewünschten Anfragen über das Objekt dieser Session aus. Cookies sammeln sich automatisch an.
4. Speichere den Zustand regelmäßig auf der Festplatte, um bei einem Absturz keine Fortschritte zu verlieren.
5. Wenn der Zeitpunkt für die IP-Rotation kommt, beende die logische Session sauber.
6. Wenn der Dienst streng an die IP gebunden ist, starte eine neue logische Session auf der grünen Wiese unter der neuen Adresse.
7. Wenn der Dienst tolerant ist, erstelle einen neuen Container mit neuem Proxy und übertrage die Cookies aus dem alten hinein.

Tipp: Führe ein Ereignisprotokoll: Wann wurde die Session erstellt, mit welcher IP, wann fand die Rotation statt, gab es einen Logout? Ein solches Protokoll zeigt dir in fünf Minuten ein Muster, das du sonst stundenlang gesucht hättest.

Check: Spiele den kompletten Zyklus durch: Session erstellen, anmelden, ein paar Aktionen ausführen, speichern, rotieren, weitermachen. Stelle sicher, dass sich der Zustand auf jedem Schritt vorhersehbar verhält und du nur dann ausgeloggt wirst, wenn du es erwartest.

Ergebnis prüfen: die finale Checkliste

Gehe diese Liste durch. Wenn alle Punkte erfüllt sind, funktioniert dein System korrekt.

• Jede logische Session hat ein eigenes Container-Objekt mit eigenem Cookie-Storage.
• An jedem Container hängt für die gesamte Lebensdauer der Session genau ein Proxy.
• Es gibt keine Stelle, an der Cookies einer Session in eine andere gelangen können.
• In Multithread-Code nutzt jeder Thread seine eigene Session über die Thread-lokalen Daten.
• In asynchronem Code hat jede unabhängige Kette ihren eigenen Client.
• Cookies werden auf allen Redirect-Schritten korrekt gesammelt.
• Der Zustand wird zwischen Läufen gespeichert und unter Berücksichtigung der Ablaufdaten wiederhergestellt.
• Bei einem IP-Wechsel wird die logische Session entweder neu gestartet oder die Cookies werden bewusst übertragen.
• Dateien mit Cookies und Tokens sind geschützt gespeichert.

So testest du

1. Finde einen Testdienst, der deine aktuelle IP und die gesendeten Cookies anzeigt.
2. Erstelle zwei Sessions mit verschiedenen Proxys und stelle sicher, dass die Daten vollständig isoliert sind.
3. Melde dich an, speichere den Zustand, starte das Programm neu, stelle den Zustand wieder her – prüfe, ob die Anmeldung noch lebt.
4. Simuliere eine Rotation und beobachte, wie sich die Session verhält.

Erfolgskriterien: Daten verschiedener Sessions vermischen sich nie, ein Logout passiert nur bei strenger Serverbindung an die IP, der wiederhergestellte Zustand funktioniert, und es gibt keine Race Conditions bei paralleler Arbeit.

Typische Fehler und Lösungen

Problem: Nach einem IP-Wechsel wird der Benutzer ausgeloggt. Ursache: Der Server bindet die Session streng an die Adresse. Lösung: Die IP innerhalb einer logischen Session nicht ändern; bei einem Wechsel die Session auf der neuen Adresse neu starten.

Problem: Cookies verschiedener Sessions vermischen sich. Ursache: Ein gemeinsamer CookieJar für mehrere Proxys. Lösung: Jede logische Session bekommt ein eigenes Storage, niemals teilen.

Problem: Der Fehler tritt bei paralleler Arbeit nur manchmal auf. Ursache: Race Condition beim Schreiben in ein gemeinsames Objekt aus mehreren Threads. Lösung: Sessions über Thread-lokale Daten isolieren oder eine Sperre verwenden.

Problem: Die Anmeldung klappt, fliegt aber sofort wieder. Ursache: Ein Cookie geht bei einem Redirect verloren. Lösung: Prüfe das Sammeln von Cookies auf allen Schritten der Umleitungskette und aktiviere das Logging für Set-Cookie.

Problem: Der wiederhergestellte Zustand funktioniert nicht. Ursache: Abgelaufene oder Session-Cookies wurden gespeichert, oder Domain und Pfad sind falsch angegeben. Lösung: Nur gültige dauerhafte Cookies speichern und mit korrekter Domain und Pfad wiederherstellen.

Problem: Das CSRF-Token ist ständig ungültig. Ursache: Das Session-Cookie, an das das Token gebunden ist, wurde verloren. Lösung: Zuerst die Integrität der Session-Cookies wiederherstellen, das Token folgt automatisch.

Problem: JWT funktioniert nach der Rotation nicht mehr. Ursache: Ein bestimmter Dienst hat das Token serverseitig an die IP gebunden. Lösung: Die IP während der Token-Lebensdauer nicht ändern oder auf der neuen Adresse ein neues Token holen.

Weitere Möglichkeiten und Optimierung

Wenn das Grundschema funktioniert, kannst du es erweitern.

Pool vorbereiteter Sessions

Statt jedes Mal eine Session zu erstellen, hältst du einen Pool im Voraus vorbereiteter und angemeldeter logischer Sessions bereit, jede mit eigenem Proxy. Nimm eine freie Session, nutze sie, gib sie zurück in den Pool. Das beschleunigt die Arbeit, weil die Anmeldung nicht unnötig wiederholt wird.

Automatische Lebendigkeitsprüfung

Füge eine Funktion hinzu, die eine leichte Anfrage an den Dienst stellt und prüft, ob die Session noch lebt. Wenn der Server wie für einen nicht angemeldeten Benutzer antwortet, wird die Session zur Neu-Anmeldung markiert. So erwischst du das Ablaufen, bevor es eine wichtige Operation ruiniert.

Tipp: Mach die Lebendigkeitsprüfung nicht vor jeder Anfrage, sondern nach Zeitplan oder nach langen Pausen. Zu häufige Checks erzeugen unnötige Last und bringen keinen Nutzen.

Zentraler Zustandsspeicher

Für größere Projekte nutze statt Dateien eine Datenbank als Cookie-Storage. Der Schlüssel ist die ID der logischen Session, der Wert der serialisierte Zustand. Das lässt sich besser skalieren und sicherer aufbewahren.

Metriken und Beobachtbarkeit

Zähle, wie oft ein Logout passiert, wie viele Sessions neu erstellt werden mussten und wie oft die Wiederherstellung erfolgreich war. Diese Zahlen zeigen den Gesundheitszustand deines Systems und verraten, wo etwas nicht optimal eingestellt ist.

FAQ: Häufige Fragen

Muss ich bei jedem IP-Wechsel ein neues Session-Objekt erstellen? Wenn der Dienst die Adresse streng prüft – ja, denn die alte Session wird auf der neuen IP ohnehin nicht akzeptiert. Wenn tolerant – kannst du die Cookies in einen neuen Container mit neuem Proxy übertragen und weitermachen.

Kann ich einen Proxy für mehrere logische Sessions verwenden? Aus Codesicht ja, aber jede logische Session braucht trotzdem ihr eigenes Cookie-Storage. Gemeinsam dürfen nur die Verbindungseinstellungen sein, nicht der Zustand.

Warum kann ich nicht einfach alle Cookies an einem Ort speichern und nach Domain filtern? Weil das Problem nicht an der Domain liegt, sondern an der Bindung an eine bestimmte logische Session und IP. Cookies einer Session auf derselben Domain dürfen nicht in eine andere Session auf derselben Domain gelangen.

Wie erkenne ich, ob ein Dienst die Session an die IP bindet? Mach ein Experiment: Melde dich unter einer IP an, wechsle die Adresse und sende eine Anfrage. Wenn du ausgeloggt wirst, gibt es wahrscheinlich eine Bindung. Geh zurück zur alten IP: Wenn es sich erholt, merkt sich der Server die erste Adresse.

Was mache ich mit Session-Cookies beim Speichern auf der Festplatte? Sie zu speichern ergibt normalerweise keinen Sinn, weil der Server sie nach einem Verbindungsabbruch für ungültig hält. Speichere dauerhafte Cookies mit gültigem Ablaufdatum.

Was tun, wenn die Bibliothek Cookies bei Redirects nicht selbst speichert? Verarbeite den Set-Cookie-Header manuell bei jeder Zwischenantwort der Umleitungskette und lege die Cookies in dein Storage.

Brauche ich eine Sperre, wenn jeder Thread seine eigene Session hat? Nein. Wenn die Daten nicht gemeinsam sind, kann es keine Race Condition geben, und eine Sperre ist unnötig. Eine Sperre ist nur bei erzwungenem gemeinsamem Zugriff auf ein Objekt nötig.

Wie lange kann ich einen wiederherstellbaren Zustand aufbewahren? Genau so lange, wie der Server die Session als lebendig betrachtet. Der genaue Zeitraum hängt vom Dienst ab. Es ist praktischer, die Lebendigkeit per Anfrage zu prüfen, als nach Zeit zu raten.

Was ist wichtiger – Cookies oder Token zu speichern? Das hängt vom Autorisierungsmechanismus des Dienstes ab. Manchmal reicht das Token, manchmal wird der komplette Cookie-Satz gebraucht. Sicherer ist es, den gesamten Zustand zu speichern – dann verpasst du nichts Nötiges.

Kann ich Cookies zwischen Python und Node.js übertragen? Ja, wenn du sie in einem gemeinsamen neutralen Format wie JSON speicherst, mit Feldern für Name, Wert, Domain, Pfad und Ablaufdatum. Dann kann jedes System sie lesen.

Fazit

Lass uns ein Fazit aus allem ziehen, was du durchgearbeitet hast. Du hast verstanden, dass dich nach einem IP-Wechsel nicht der Wechsel selbst ausloggt, sondern Serverprüfungen und Fehler in deiner Architektur. Du weißt jetzt, dass Cookies, CSRF und JWT von sich aus nicht an die Adresse gebunden sind – die Bindung fügt ein bestimmter Dienst hinzu. Du hast die Hauptregel verinnerlicht: Eine logische Session entspricht einem Cookie-Satz und einer IP.

Danach hast du funktionierenden Code geschrieben. In Python – über ein separates Session-Objekt mit eigenem CookieJar für jeden Proxy und Thread-Isolation. In Node.js – über die Kombination aus axios, tough-cookie und Proxy-Agent mit einem separaten Client für jede logische Session. Du hast gelernt, den Zustand zwischen Läufen zu speichern, die Ablaufdaten von Cookies zu berücksichtigen und zu erkennen, wann du den Zustand besser verwirfst.

Du hast drei tückische Fehler analysiert: den gemeinsamen CookieJar, die Race Condition bei paralleler Arbeit und den Verlust von Set-Cookie bei Redirects. Und jetzt hast du eine Checkliste für vor dem Go-Live, die verhindert, dass du eine unfertige Lösung rausbringst.

Wie du weitermachst

Fang klein an. Nimm ein reales Szenario, setze dafür eine isolierte logische Session um und stelle sicher, dass der Zustand nicht verloren geht. Danach ergänzt du das Speichern auf der Festplatte. Danach skalierst du auf mehrere Sessions. Geh Schritt für Schritt vor und prüfe das Ergebnis bei jedem Schritt.

Wo du dich weiterentwickeln kannst

Als Nächstes lohnt es sich, tiefer in die Beobachtbarkeit einzusteigen: Metriken für die Lebendigkeit der Sessions und Event-Logging einzurichten. Dann kannst du lernen, wie du den Zustand bewusst überträgst, wenn der Dienst tolerant gegenüber Adresswechseln ist. Und schließlich baust du einen Pool fertiger Sessions auf, um die Arbeit zu beschleunigen. Jeder dieser Schritte macht dein System stabiler und vorhersehbarer. Du schaffst das – das Prinzip hast du schon verstanden, der Rest ist Übungssache.