How to Keep Your Session, Cookies, and Tokens When Rotating IPs: A Step-by-Step Guide

You’ve probably been there: the script is running, you log into a site, add an item to the cart, and then the IP changes — and suddenly the server responds as if you’ve never visited before. The user is logged out, the cart is empty, the token is invalid. Annoying? You bet. But there’s a clear engineering solution to this problem, and in this guide we’ll walk through it from start to finish.

Introduction: Why You Get Logged Out and Your Cart Empties After an IP Change

Let’s be honest: when your session drops after an IP rotation, the first instinct is to blame the IP change itself. Like, the IP changed, the server noticed, and reset everything. Sometimes that’s exactly what happens. But far more often, the problem isn’t the IP itself — it’s how your code is built. It mixes up the state of different sessions, loses cookies, and sends old tokens from a new address. We’ll learn how to make sure that doesn’t happen.

What You’ll Get by the End

By the end of this guide, you’ll be able to do the following. First, understand what’s actually tied to the IP on the server side and what’s a myth. Second, establish a strict rule: one logical session equals one set of cookies equals one IP. Third, write working code in Python and Node.js that isolates state between different proxies and doesn’t mix data. Fourth, save state between program runs and understand when it’s better to just throw it away.

Who This Guide Is For

This guide is aimed at an intermediate level. You already write code in Python or JavaScript, you know what an HTTP request is, and you understand why proxies are needed. We won’t discuss which rotation type to choose — there are separate articles for that. Here, we assume IP rotation is already happening according to your rules, and we solve exactly one problem: how not to lose state during that rotation.

What You Should Know in Advance

It helps to understand the basics. A cookie is a small piece of data that a server asks the browser or client to remember and send back with every request. A session is how the server recognizes you between requests. A token is a string that confirms your identity or permission to act. If these terms are still fuzzy, don’t worry: in the basic concepts section, we’ll break each one down in plain language.

How Long This Will Take

Reading and understanding the theory will take about forty minutes. Reviewing and running the code in your language will take another hour or an hour and a half. Fully absorbing it with experiments on real tasks will take two to three hours. Don’t rush. It’s better to slowly understand the principle than to quickly copy code that will later break in mysterious ways.

Preparation: Tools and Environment

Before we write code, let’s get your working environment in order. It’ll take a little time, but it’ll save you hours of debugging later.

Required Tools

• Python 3.10 or newer — if you’re working in Python. In 2026, versions 3.12 and 3.13 are current, but everything described here works starting from 3.10.
• Node.js 20 LTS or newer — if you’re working in JavaScript. Version 22 LTS also works.
• Proxy with IP rotation — you should already have access to a pool of addresses. The connection format is usually: protocol, host, port, username, and password.
• Code editor — any editor will do, like a free one with syntax highlighting.
• Terminal or command line — for installing libraries and running scripts.

System Requirements

The requirements are modest. Any modern computer will handle it. Four gigabytes of RAM is enough, but if you plan to run many parallel sessions, eight or more is better. A stable internet connection is more important, because if connectivity drops, cookies may not save correctly.

What to Install

For Python, install two libraries. Open a terminal and run the command to install the requests package and a proxy support package. It looks like this: first the package manager install command, then the name requests. For serializing state, the standard module will do — no separate installation needed.

For Node.js, install three packages: axios for requests, tough-cookie for managing the cookie store, and https-proxy-agent for connecting through a proxy. All three are installed with a single package install command in your project.

Tip: Create a separate virtual folder for your project. In Python, that’s a virtual environment; in Node.js, it’s a separate directory with a dependency manifest file. That way you won’t mix libraries from different projects and avoid version conflicts.

Backing Up

If you already save cookies to files or a database, make a backup before experimenting. We’ll be changing the serialization logic, and there’s a risk of corrupting existing data. Just copy the folder with saved states to a location marked backup.

Check: After installing, make sure everything works. Run a quick Python or Node.js version check in the terminal. You should see the version number without errors. Then try importing the installed libraries in interactive mode — if the import goes through silently, you’re all set.

Basic Concepts: What’s Actually Tied to an IP and What’s a Myth

This is the most important theoretical section. Until you understand what’s really connected to the IP, you’ll be treating the wrong disease. Let’s go through the data types one by one.

Cookie Session

A cookie session is when the server gives you a session ID as a cookie and stores the state on its side. For example, a cookie named sessionid with a long random string inside. The server uses that string to find your record in its memory. Is this mechanism tied to the IP? By itself, no. The cookie works regardless of the address. But many services add an extra check: they remember which IP the session was created from, and if a request with the same cookie comes from another address, they consider it suspicious. That’s when you get logged out.

CSRF Token

A CSRF token is protection against request forgery. The server issues a token, and you need to send it back when submitting a form or performing an important action. This token is almost never tied to the IP. It’s linked to the session, not the address. The problem with it arises for a different reason: if you lose the session cookie, the CSRF token becomes invalid too, because the server can’t associate it with your session. So the problem here is secondary — a consequence of losing cookies.

JWT

JWT is a token that carries information inside itself and is signed by the server. The client stores it and sends it in a header with every request. A classic JWT isn’t tied to the IP at all. It’s self-contained: the server checks the signature and expiration, and the address doesn’t matter. But there are implementations where the server additionally binds the token to an IP on its side or puts the address inside the token. In those cases, an IP change breaks validation. That’s not a property of JWT — it’s a decision made by a specific service.

Server-Side Session

A server-side session is a general term for state that the server stores and associates with your identifier. Cart contents, browsing history, auth status — all of that often lives in a server-side session. Whether it’s tied to the IP depends on the service’s settings. Some services, for security, hard-bind the session to the first IP it was created from. Others tolerate address changes. You usually don’t know in advance, so you build your code as if the binding exists — that’s a safe strategy.

Shopping Cart

The cart is a special case of either a server-side session or cookies. In simple shops, the cart is stored in a cookie on the client. In complex ones, it’s stored on the server, tied to the session. If your cart empties after an IP change, it means it was tied to a server-side session that checks the address. The solution is the same: don’t change the IP within one logical session, or carefully save the entire set of cookies.

Summary: Where the IP Really Matters

Let’s put the picture together. The HTTP mechanisms of cookies, CSRF, and JWT are not tied to the IP. The binding appears as an additional check on the service’s side, and you can’t control it. The only thing you control is the correspondence between the session, the cookie set, and the IP on your side. That leads to the guide’s main rule.

Check: Test your understanding. If the session drops after an IP change, but everything comes back when you return to the old IP, the server is strictly checking the address. If it doesn’t come back even on the old IP, you simply lost the cookies in your code. Those are two different diagnoses with different treatments.

Step 1: Define the Mapping Rule

Goal of this step: solidify the core principle and understand how to express it in your code structure.

The rule is simple: one logical session equals one set of cookies equals one IP. Let’s break down what that means in practice.

1. A logical session is a chain of requests that represent one continuous workflow: you enter, authenticate, do something, and exit. All of that is one logical session.
2. One set of cookies is a separate cookie store that belongs only to this logical session and no one else.
3. One IP — during a single logical session, the address doesn’t change. If rotation does happen, the logical session is considered ended.

How do you express that in code? Very clearly: create a container object that holds both the cookie store and the proxy configuration inside itself. As long as that object is alive, the logical session is alive. When it’s time to change the IP, we either create a new container or, if the service tolerates address changes, carefully transfer the cookies to a new container with the new IP.

⚠️ Caution: The most common architectural mistake is keeping one shared cookie set and plugging different proxies into it. That’s guaranteed to break everything. Different logical sessions start overwriting each other’s cookies, and the server gets contradictory data. Never do that.

Tip: Think of a logical session as a person. One person has one set of documents (cookies) and one home (IP). Two people can’t share the same documents, and one person can’t live in two homes at once. This analogy will keep you from most mistakes.

Check: Sketch your future structure on paper. You should get several independent blocks, each with its own cookie store and its own proxy. There’s no shared data between blocks. If that’s the case, you’ve understood the rule.

Step 2: Python Practice — A Session for Each Proxy

Goal of this step: write working code where each logical session has its own requests.Session object, its own CookieJar, and its own proxy, all isolated from each other.

The requests library has a Session object. It’s a container by itself: it holds a cookie store inside and can apply settings to all requests. It’s an ideal foundation for our logical session.

Basic Structure

1. Create a function that takes a single proxy’s data and returns a ready-to-use Session object.
2. Inside the function, create a new Session object.
3. Set the proxies configuration on the object — a dictionary with the proxy address for both http and https protocols.
4. Return the object. Now you have an isolated container.

The code looks like this. Line by line: you import requests. You define a function make_session that takes a proxy_url string. Inside, you write s = requests.Session(). Then you set s.proxies to a dictionary where the http key maps to proxy_url and the https key maps to proxy_url. At the end, you return s. That’s it — the function is ready.

Why This Isolates State

Each call to make_session creates a completely new object. The new object has its own internal cookie store, called a cookiejar. Cookies received by one session physically cannot end up in another session, because they are different objects in memory. That’s exactly what we wanted.

Using the Session

1. Get a session object by calling the function with the proxy you need.
2. Make requests through that object’s methods: s.get or s.post.
3. Cookies that the server sends in the Set-Cookie header are automatically stored inside the object.
4. On subsequent requests through the same object, those cookies are automatically sent back.

Tip: Don’t create a new Session for each individual request within the same logical session. Then cookies won’t accumulate. Create the object once for the entire logical session and use it for all requests in that session.

Isolation Between Threads

If you’re working with multiple threads, each thread must have its own Session object. The Session object is not thread-safe. That means if two threads write cookies to the same object at the same time, the data can get corrupted.

1. Use thread-local data. In Python, that’s the threading.local object.
2. When each thread starts, create a separate session for it and store it in the thread’s local storage.
3. Inside the thread, only access its own session — don’t touch others’.

In practice, it looks like this: create a global object local = threading.local(). At the start of the thread’s work, check if local has a session attribute. If not, create it by calling make_session with the proxy assigned to that thread. Then, in the thread, use local.session for all requests.

⚠️ Caution: Never pass a single Session object between threads as a shared resource. Even if it seems like requests are happening one after another, the scheduler can switch threads at the worst possible moment, and you’ll end up with mixed cookies. Each thread gets its own object.

Rotation Within the Logic

When an IP rotation happens and you need a new address, do this. End the current logical session: if the server hard-binds to the IP, just create a new Session object with the new proxy and start fresh — log in again. If the server tolerates address changes, you can transfer the cookies, which we’ll cover in the section on storing state.

Check: Run two sessions with different proxies, log in to a test service that shows your IP and cookies. Make sure each session sees its own IP and its own set of cookies. If the data doesn’t mix — isolation is working correctly.

Step 3: The Same Thing in Node.js

Goal of this step: build the equivalent structure in JavaScript using axios, tough-cookie, and a proxy agent.

In the Node.js ecosystem, there’s no ready-made Session-level object, so we’ll build one from three parts. We’ll take the cookie store from tough-cookie. The proxy agent will handle the proxy connection. Axios will make the requests.

Building the Container

1. Import the CookieJar class from the tough-cookie package.
2. Import the proxy agent factory from the https-proxy-agent package.
3. Import axios.
4. Create a function makeClient that takes a proxy address and returns a configured object.

Inside the function, create a new store instance: const jar = new CookieJar(). Create a proxy agent by passing it the address: const agent = new HttpsProxyAgent(proxyUrl). Create an axios instance with settings via axios.create, passing in httpsAgent: agent and httpAgent: agent.

Enabling Automatic Cookie Handling

Bare axios doesn’t know how to put cookies from a response into the store or pull them out for a request. You have two options.

1. The first option: use a ready-made wrapper that connects axios and tough-cookie, installed as a separate package. It automatically reads and writes cookies through the provided jar store.
2. The second option: do it manually with request and response interceptors. Before a request, get the cookie string from the store for the target address and put it in the Cookie header. After a response, take the Set-Cookie header and write each cookie to the store.

Tip: Start with the ready-made wrapper — fewer chances to make mistakes. Save the manual approach for when you need fine-grained control, like logging every cookie.

Isolation Between Concurrent Tasks

Node.js has a different model — not threads, but asynchronous tasks in a single event loop. But the principle is the same: each logical session has its own separate client object with its own jar and its own agent.

1. Call makeClient separately for each concurrent task.
2. Keep the clients in an array or a map, where the key is the task identifier.
3. Never use one jar for multiple clients at the same time.

⚠️ Caution: In asynchronous code, it’s easy to accidentally share one client across multiple promise chains. Then cookies will start mixing between logical sessions. Always check that each chain uses its own client, created by a separate makeClient call.

Rotation in Node.js

The logic is identical to Python. When you need a new IP and the service binds the session to the address, create a new client with a new proxy and a new empty jar, then log in again. When the service is tolerant, transfer the contents of the old jar to a new client with a new agent.

Check: Create two clients with different proxies. Make requests to a test service that echoes the IP and cookies. Verify the first client sees one IP and its own cookies, and the second sees another IP and its own. There should be no overlap.

Step 4: Storing State Between Runs

Goal of this step: learn how to save cookies to disk and restore them the next time your program runs, while accounting for their lifetime.

Often you need to stop a script and run it later without losing authentication. To do that, you need to serialize the cookies — turn them into text and save them to a file or database.

Serialization in Python

The CookieJar object from requests can be saved in several ways. The most portable one is to collect the cookies into a simple dictionary and write them as JSON.

1. Iterate over all cookies in the session object via s.cookies.
2. For each cookie, collect its name, value, domain, path, and expiration date.
3. Put this into a list of dictionaries.
4. Write the list to a file in JSON format.

To restore, do the reverse: read the file, go through the list, and add each cookie to a new session object using the cookie-setting method, specifying the domain and path.

Tip: Store the proxy identifier along with the cookies, or at least a note about which logical session they belong to. That way you won’t restore someone else’s cookies with the wrong IP and break the mapping rule.

Serialization in Node.js

The tough-cookie library has a built-in serialization method. The jar object has an async method that turns the entire store into a JSON object. The reverse method restores the jar from that object.

1. Call the store’s serialization method and get an object.
2. Turn the object into a string and save it to a file.
3. On startup, read the file and parse the string back into an object.
4. Restore the jar using the deserialization method, passing in the object.

This is more convenient than in Python, because tough-cookie stores all the required fields itself, including the expiration date and security flags.

Cookie Lifetime

Every cookie has an expiration. Some cookies are session cookies — they live until the browser closes and don’t have an explicit date. Others are persistent — with a specific expiration date. It only makes sense to save persistent cookies that haven’t expired yet. Session cookies are usually already invalid on the server after a restart.

1. Before saving, check each cookie’s expiration date.
2. Discard any that have already expired.
3. When restoring, check the dates again and don’t load expired ones.

When It’s Easier to Discard the State

It’s not always worth clinging to saved cookies. Sometimes a clean start is faster and more reliable.

• If a lot of time has passed since the last run, the server-side session has probably expired, so there’s nothing to restore.
• If the server returns an auth error on the very first request with restored cookies, throw them away and log in again.
• If you’re not sure the state file is intact, it’s better to start fresh than to debug strange behavior.

⚠️ Caution: Files with cookies and tokens contain access data. Keep them in a secure place, don’t put them in a shared repository, and don’t send them over unsecured channels. Leaking such a file is the same as leaking account access.

Check: Save the state, completely close the program, run it again, restore the state, and make a request that requires authentication. If the server responds as if you’re an authorized user, saving works. If you get logged out, check the expiration dates and whether the domain and path were restored correctly.

Step 5: Common Architectural Mistakes

Goal of this step: examine the three biggest mistakes in detail so you can recognize them in your code and avoid them.

Mistake #1: A Shared CookieJar for All Proxies

This is the root of all evil. A developer creates one cookie store and plugs different proxies into it, thinking they’ll save resources. What happens: cookies from a session on the first IP end up in a request on the second IP. The server sees a cookie created under a different address, and either resets the session or flags the behavior as suspicious.

The solution is simple: each proxy gets its own cookie store. No exceptions. We’ve already built this into the code steps: a separate Session or a separate client with its own jar for each logical session.

Mistake #2: Race Conditions in Parallel Requests

A race condition is when two operations access the same data at the same time and interfere with each other. If two threads write to the same CookieJar, one write can overwrite another. The result: some cookies are lost randomly, and the bug reproduces intermittently, which is painful to debug.

1. Give each thread its own session via thread-local data, as we described.
2. In asynchronous code, don’t share one client between independent task chains.
3. If, for some reason, the object is still shared, use a lock so only one thread works with it at a time.

Tip: The best way to avoid race conditions is to have no shared mutable data at all. Isolating by logical session solves the problem at its root: if data isn’t shared, a race condition is impossible.

Mistake #3: Losing Set-Cookie Headers on Redirects

When a server responds with a redirect, it often sets important cookies in that same response via the Set-Cookie header. Some client configurations lose those cookies during automatic redirects — they never make it into the store.

1. Make sure your client saves cookies at every step of the redirect chain, not just on the final response.
2. In requests, this works by default when using a Session object — cookies are collected along the way. Check that you haven’t disabled redirect following without a reason.
3. In axios, when working with cookies manually, handle Set-Cookie on every intermediate response. If you’re using a wrapper, verify it intercepts redirects.

⚠️ Caution: If authentication succeeds but the next request logs you out, a common cause is a cookie lost during redirect. Enable logging for all Set-Cookie headers and see whether all expected cookies made it to the store.

Check: Find an action on the target service that causes a redirect, like logging in through a form. Trace the chain and compare cookies after each step. Every issued cookie should end up in your store. If one is missing, you’ve found the leak.

Step 6: Putting It All Together Into a Workflow

Goal of this step: combine everything you’ve learned into a single predictable workflow from start to rotation.

Now you have all the pieces. Let’s put them into a repeatable chain of actions.

1. Take a proxy from your pool and create an isolated logical session for it — a Session in Python or a client in Node.js.
2. If there’s saved state for that logical session and it hasn’t expired, restore the cookies. Otherwise, log in again.
3. Make the requests you need through that session object. Cookies accumulate automatically.
4. Periodically save the state to disk so you don’t lose progress on a crash.
5. When it’s time for IP rotation, close the logical session properly.
6. If the service hard-binds to the IP, start a new logical session from scratch on the new address.
7. If the service is tolerant, create a new container with the new proxy and transfer the cookies from the old one into it.

Tip: Keep an event log: when a session was created, with which IP, when rotation happened, and whether a logout occurred. In five minutes, such a log will reveal a pattern you’d otherwise spend hours looking for.

Check: Run the full cycle: create a session, log in, do a few actions, save, rotate, continue. Make sure the state behaves predictably at every step and logout only happens when you expect it.

Verifying the Result: Final Checklist

Go through this list. If all the items are checked, your system is working correctly.

• Every logical session has its own container object with its own cookie store.
• Each container is bound to exactly one proxy for the entire life of the session.
• There’s no place where cookies from one session can end up in another.
• In multithreaded code, each thread uses its own session via thread-local data.
• In asynchronous code, each independent chain has its own client.
• Cookies are correctly collected at every step of redirects.
• State is saved and restored between runs, accounting for expiration dates.
• When the IP changes, the logical session either starts fresh or cookies are transferred deliberately.
• Files with cookies and tokens are stored securely.

How to Test

1. Find a test service that shows your current IP and the cookies you sent.
2. Create two sessions with different proxies and verify complete data isolation.
3. Log in, save the state, restart the program, restore it — and confirm the authentication is still alive.
4. Simulate a rotation and observe how the session behaves.

Success metrics: data from different sessions never mixes, logout only happens when the server hard-binds to the IP, restored state works, and there are no race conditions under parallel load.

Common Mistakes and Solutions

Problem: the user gets logged out after an IP change. Cause: the server hard-binds the session to the address. Solution: don’t change the IP within a single logical session; if you need to change it, start a new session on the new address.

Problem: cookies from different sessions get mixed. Cause: a shared CookieJar across multiple proxies. Solution: give each logical session its own store and never share it.

Problem: the bug appears intermittently under parallel load. Cause: a race condition when multiple threads write to a shared object. Solution: isolate sessions per thread using thread-local data, or use a lock.

Problem: authentication succeeds but immediately drops. Cause: a cookie is lost during redirect. Solution: check cookie collection at every step of the redirect chain and enable Set-Cookie logging.

Problem: restored state doesn’t work. Cause: expired or session cookies were saved, or the domain and path were restored incorrectly. Solution: only save valid persistent cookies and restore them with the correct domain and path.

Problem: the CSRF token is constantly invalid. Cause: the session cookie that the token is bound to was lost. Solution: restore the integrity of the session cookies first; the token will follow automatically.

Problem: JWT stops working after rotation. Cause: a specific service bound the token to the IP on its side. Solution: don’t change the IP during the token’s lifetime, or obtain a new token on the new address.

Additional Features and Optimization

Once the basic scheme works, you can enhance it.

Pool of Ready-Made Sessions

Instead of creating a session every time, keep a pool of pre-prepared, authenticated logical sessions, each with its own proxy. Grab an available session, use it, then return it to the pool. This speeds things up because authentication isn’t repeated unnecessarily.

Automatic Liveness Checks

Add a function that makes a lightweight request to the service and checks whether the session is still alive. If the server responds as if you’re unauthorized, the session is marked for re-authentication. That way, you catch expiration before it ruins an important operation.

Tip: Don’t do liveness checks before every request — do them on a schedule or after long pauses. Too-frequent checks add unnecessary load and provide no benefit.

Central State Storage

For large projects, use a database instead of files as the cookie store. The key is the logical session ID, and the value is the serialized state. This is easier to scale and safer to store.

Metrics and Observability

Track how often logouts happen, how many sessions had to be recreated, and how often restoration succeeds. These numbers show the health of your system and point out where something is configured suboptimally.

FAQ: Frequently Asked Questions

Do I have to create a new session object every time the IP changes? If the service strictly checks the address — yes, because the old session won’t be accepted on the new IP anyway. If the service is tolerant, you can transfer the cookies to a new container with a new proxy and continue.

Can I use one proxy for multiple logical sessions? From a code perspective, yes, but each logical session must still have its own separate cookie store. Only the connection settings can be shared — not the state.

Why can’t I just store all cookies in one place and filter by domain? Because the problem isn’t the domain — it’s the binding to a specific logical session and IP. Cookies from one session on a given domain shouldn’t leak into another session on the same domain.

How do I know whether a service binds the session to the IP? Run an experiment: log in on one IP, change the address, and make a request. If you get logged out, there’s probably a binding. Go back to the old IP: if it restores, the server remembers the first address.

What should I do with session cookies when saving to disk? There’s usually no point in saving them, because the server considers them invalid after the connection breaks. Save persistent cookies with a valid expiration date.

What if the library doesn’t save cookies on redirect by itself? Manually process the Set-Cookie header on every intermediate response in the redirect chain and put the cookies into your store.

Do I need a lock if each thread has its own session? No. If data isn’t shared, a race condition is impossible, and a lock isn’t needed. Locks are only required when you’re forced to share a single object.

How long can I keep restorable state? Exactly as long as the server considers the session alive. The exact duration depends on the service. It’s more practical to check liveness with a request than to guess by time.

What’s more important — saving cookies or saving the token? It depends on the service’s authentication mechanism. Sometimes a token is enough, sometimes you need the full set of cookies. It’s safer to save the entire state, so you won’t miss what you need.

Can I transfer cookies between Python and Node.js? Yes, if you save them in a common neutral format like JSON with name, value, domain, path, and expiration fields. Then either system can read them.

Conclusion

Let’s recap what you’ve gone through. You now understand that getting logged out after an IP change isn’t because of the change itself, but because of server-side checks and mistakes in your architecture. You learned that cookies, CSRF, and JWT aren’t tied to the address by themselves — a specific service adds that binding. You took in the main rule: one logical session equals one set of cookies equals one IP.

Then you wrote working code. In Python, you used a separate Session object with its own CookieJar for each proxy and thread isolation. In Node.js, you used axios, tough-cookie, and a proxy agent to build a separate client for each logical session. You learned to save state between runs, account for cookie expiration, and understand when it’s easier to discard the state.

You dissected three tricky mistakes: the shared CookieJar, race conditions under parallel work, and losing Set-Cookie headers during redirects. And now you have a pre-production checklist that will keep you from shipping a half-baked solution.

What to Do Next

Start small. Take one real scenario, implement an isolated logical session for it, and confirm that state doesn’t get lost. Then add disk persistence. Then scale to multiple sessions. Move one step at a time, checking the result at each stage.

Where to Go Next

Next, it’s worth diving into observability: set up session liveness metrics and event logging. Then learn how to transfer state deliberately when the service tolerates address changes. Finally, build a pool of ready-made sessions to speed up your work. Each of these steps makes your system more robust and predictable. You’ve got this — you already understand the principle, and everything else is a matter of practice.