Static vs Rotating Proxies

Definitions that hold up

"Static" and "rotating" describe how often the exit address changes, not the network behind it. Datacenter, residential, ISP and mobile proxies can each be sold either way, so check both properties when you compare offers.

A static proxy gives you one public address for the life of the plan or session. ISP proxies are the common example: you get an address and keep it for the month.

A rotating proxy changes the exit for you. On a pooled product, the gateway may pick a new address for every request or every few minutes. On a dedicated mobile line, rotation means the device reconnects to the carrier and receives a new address from the carrier's range.

A sticky session is a pooled product's way of holding one exit for a while. You add a session identifier to the username, and the gateway keeps routing that session through the same device until a time limit passes or the device drops. Decodo, for example, documents a default of 10 minutes and a maximum of 1,440 minutes (24 hours) for mobile sticky sessions, and warns that longer sessions are more likely to end early because the device at the other end goes offline (Decodo sticky sessions). DataImpulse describes its mobile sticky sessions as lasting up to two hours, with rotating mode changing the IP on each request (DataImpulse mobile proxies).

For more on how gateways choose exits, see how rotating proxies work.

Jobs that need a fixed IP

A site that keeps state about you also keeps state about where you connect from. Changing the address in the middle of that state is what triggers "verify it's you" prompts, logouts and holds.

Account sessions. Social, marketplace, advertising and email accounts record sign-in locations. A login from one address followed by activity from a different address minutes later looks like a stolen session. Keep each account on one stable exit for the whole session, and ideally across sessions.

Carts and checkouts. Payment and fraud checks compare the address that started a checkout with the one that finishes it. A change mid-flow is a common reason for a declined or held order.

Allowlists. If a partner API or admin panel only accepts requests from approved addresses, rotation breaks access. Our guide to proxy IP allowlisting covers which address the other side actually needs.

Long-lived connections. WebSocket feeds, streaming sessions and SSH tunnels tie the connection to the address. A rotation closes them.

Cookies are the mechanism behind most of this. The HTTP cookie standard lets a server store state on the client and read it back on later requests (RFC 6265). A site can link that cookie to the address it first saw, so a fixed exit keeps the two consistent.

Jobs that need rotation

Rotation earns its place when requests are independent and the volume from one address would be noticed.

Public page collection. Product listings, search results and public profiles do not need you to be anyone in particular. Spreading requests over several addresses keeps any one address under the target's per-IP threshold.

Geographic sampling. If you want to see how a page renders for many different users in one country, each new address is a new sample.

Recovering from a soft block. If an address starts returning challenge pages, moving to a new one is often faster than waiting. Do it deliberately and slow down too; rotating while keeping the same pace usually brings the same result on the next address.

Rotation has a price on a dedicated mobile line too. Each change takes a few seconds while the modem reconnects, and requests in flight fail. Batch your work so rotations happen between tasks, not during them.

Sticky sessions in between

Sticky sessions exist because many jobs are a short sequence of related requests: load a search page, open three results, read a review page. That sequence should come from one address, but the next sequence can come from another.

On a pool, you get this by setting a session ID and a duration. The catch is that you do not control the device. If it goes offline, your session moves to a different exit before its time is up, as Decodo's documentation notes. Build your client to detect an address change, by checking the exit IP between steps, and restart the sequence rather than continuing on a new address.

How long should a sticky session be? Long enough to finish one unit of work and no longer. Time a typical sequence on your target, add a margin, and set the session to that. A ten-minute default suits short browse-and-read sequences; a checkout or form flow may need thirty. Very long sessions on a pool raise the chance that the device drops partway, and you lose the session anyway.

On a dedicated line, a sticky session is simply the time between your own rotations. If you rotate every ten minutes, each ten-minute window is one session. The device does not belong to anyone else, so it does not vanish to serve another customer.

One line, both modes

A dedicated mobile line is static until you rotate it, which makes it unusual: one product covers both columns of this comparison. You rent the device, so no other customer's traffic moves the address, and you decide when it changes.

That turns the static or rotating question into a scheduling question. For an account session, leave rotation alone and the line behaves like a static proxy on a carrier network. For collection, set a timer or call rotation from your script between tasks, and the same line behaves like a rotating proxy that only you use. The next section lists the four controls.

Four ways to change the IP on one line

Two cautions. The rotation link rotates on every GET request, including the preview a chat app or email client fetches when you paste the link, so keep it out of messages. And Brazil lines rotate on request only, with no timer.

A practical layout is one line per account group with the timer off, plus a separate line with a timer for collection. That keeps logged-in identities stable while the collector changes address on its own schedule. Compare countries and carriers for both roles on the mobile proxies overview.

Rotate and verify in a script

Here is the shape of a rotate-and-verify step in Python. It reads the exit address, calls the rotation link you copied from the dashboard, waits for the reconnect, and reads the address again:

import time
import requests

PROXY = "http://USER:PASS@HOST:PORT"        # from the line's credentials
ROTATION_LINK = "PASTE_FROM_DASHBOARD"       # private: every GET rotates the line
proxies = {"http": PROXY, "https": PROXY}

def exit_ip():
    return requests.get("https://api.ipify.org", proxies=proxies, timeout=20).text

before = exit_ip()
requests.get(ROTATION_LINK, timeout=60)
time.sleep(20)                               # give the modem time to reconnect
after = exit_ip()
print("before", before, "after", after, "same" if before == after else "changed")

If the address did not change, wait and check again before calling the link a second time. The timer and rotations share the same 60-second minimum.

Rate limits and what rotation does not reset

A new address only resets limits that are keyed to the address. Many are not.

The HTTP standard defines status 429 Too Many Requests for rate limiting and lets the server say how long to wait with a Retry-After header (RFC 6585; RFC 9110, Retry-After). The standard does not require the limit to be per IP. A site can count requests per account, per API key, per cookie or per browser fingerprint, and those counters follow you to the next address.

It also helps to know what a limit looks like before you meet one. Some sites answer with a clean 429 and a Retry-After value. Others return a 200 with a challenge page, a 403, or an empty result set that looks like real data. Log status codes and response sizes, so a quiet block shows up as a pattern instead of as missing rows in a report.

What a new IP resets, and what it does not

If you see 429 responses, read the Retry-After value and honor it. Rotating through addresses to keep hitting an account-level limit usually turns a temporary throttle into a longer block. Our IP ban check and fix guide walks through reading these responses.

How we checked

Session lengths for pooled products come from each provider's own documentation, read on 30 October 2026. Coronium rotation methods and limits come from the published product facts. The Python example shows the sequence of calls; it does not include a real token or line, and we did not measure reconnect times across carriers.

Frequently asked questions