“Rotating residential proxies” is a phrase everyone in this space uses, but the mechanics behind it are rarely spelled out. Where do the IPs come from? Why does your exit IP sometimes change when you did not ask it to? What does “rotating” actually control, and why is a “sticky” IP never quite permanent? Understanding the plumbing answers all of those, and it is the difference between fighting your proxy’s behavior and using it on purpose.
This is the mechanism beneath the sticky vs rotating choice and the anatomy of a residential IP. Here is what is really happening.
You connect to a gateway, not to IPs
The first thing to understand is that you never connect to individual residential IPs, and you never manage a list of them. You connect to a single gateway endpoint, p.shifter.io:443, and the gateway routes your request out through one of the millions of residential IPs in the pool. Everything about which IP you get is expressed in the username you authenticate with:
customer-USERNAME-country-us-sid-abc123-ttl-600The gateway reads that username, filters the pool to IPs that match your targeting (here, United States), picks one, and sends your request out through it. You talk to one address; the pool sits behind it. This is why rotation feels effortless: the gateway does the assigning, and you just describe what you want.
The pool is alive, so rotation is the default
A residential pool is not a fixed list. It is made of real home connections that come and go as devices go online and offline throughout the day, so the set of usable exit IPs is constantly changing. When you open a connection without asking for a specific session, the gateway simply assigns a fresh exit IP from whatever is currently available. That is what “rotating” means at its most basic: a new connection gets a new IP.
So rotation is not a special mode you switch on. It is the natural behavior of a live pool when you do not tell the gateway to hold an IP for you. Omit the session controls and every new connection rotates.
You control rotation with a session token and a TTL
Two knobs in the username decide whether you rotate or stay put, and they are the whole story:
- A session id (
sid) tells the gateway “keep sending me out through the same exit IP whenever I present this token.” That is a sticky session. - A TTL (
ttl) says how long to hold that IP, for example 600 seconds.
Set both and you get a stable IP for the window. Omit them and you rotate on every connection. Crucially, this is a choice you make per request by changing the username, not a different product or endpoint, the same gateway does both. That is why sticky vs rotating is a decision you make per unit of work, not a plan you buy.
Why a sticky IP is never truly permanent: CGNAT and device churn
Here is the honest part that datacenter proxies do not have to reckon with. A residential exit IP belongs to a real home connection you do not control, and home connections are not stable the way a rented server is. Two forces in particular keep them moving.
Most home connections now sit behind CGNAT, carrier-grade NAT, where the ISP shares one public IPv4 address among many subscribers and can reassign it. A subscriber’s public IP can change on a lease renewal or a NAT reassignment, with nothing you or the gateway did. And the device itself can simply go offline, someone closes a laptop, a phone drops off Wi-Fi, and that exit path is gone.
This is why a sticky session is best-effort, not a guarantee. The gateway holds your IP for as long as it can within the TTL, but if the underlying home connection changes or drops, you get a new IP before the TTL is up. Rotation, in other words, is partly a feature and partly a reflection of network reality: residential IPs move because real homes move, and any system built on them has to expect it.
Why your IP changed when you did not ask
Put those pieces together and the mysterious mid-run IP change stops being mysterious. It is almost always one of these:
- No session token, so every connection rotates by design. This is the most common surprise for people who assumed one IP per run.
- A sticky session whose TTL expired, so the gateway released the IP and assigned a new one.
- A sticky session whose underlying home IP dropped (device offline or CGNAT reassignment) before the TTL, forcing an early change.
- A new connection your client opened instead of reusing a kept-alive one. If your HTTP client does not reuse its connection, each request can look like a fresh rotation event unless the
sidpins it, which is one more reason the language guides stress reusing the client.
What this means for how you scrape
The practical takeaways follow directly from the mechanics.
Match rotation to the task. Rotate, by omitting the session, when you want anonymity and to spread load across many IPs. Go sticky, with a sid and ttl, for anything that must look like one coherent visitor: a multi-page paginated sequence, a logged-in session, or any multi-step flow. Mapping work to identities this way is the load-balancing pattern.
Design for a sticky IP that might still change. Because sticky is best-effort, a long session should be able to survive its exit IP changing mid-way, re-establishing cookies or state if it happens, rather than assuming the IP is fixed for the whole run.
Geo targeting rotates within a subset. When you target a country, city, or ASN, the gateway filters the pool to that subset and rotates within it. “Rotating US residential” means a fresh US IP per connection; ASN or city-level targeting just narrows the subset it rotates through.
Pool quality decides what rotation gives you. Rotation is only as good as the pool behind it. A large, clean pool means each fresh IP is a good one; a small or dirty pool means rotation just cycles you through flagged addresses, and your success rate reflects it. This is why IP reputation and pool size matter more than the rotation mechanism itself.
The bottom line
Residential proxy rotation is not magic and it is not a mystery. A gateway assigns your exit IP from a live pool of real home connections, you control whether it rotates or stays sticky with a session token and a TTL in the username, and the whole thing is bounded by the reality that home IPs come and go because of CGNAT and device churn. Rotate by omitting the session; stay sticky by setting a sid and ttl, but treat sticky as best-effort and build for the IP potentially changing. Match the choice to the task, and everything downstream, sessions, logins, pagination, geo, gets easier.
The thing that makes rotation actually useful is the pool underneath it. Our residential proxies run on a large, clean pool so that every exit IP the gateway hands you, rotating or sticky, is one worth using, and the per-GB pricing means you pay for the requests you make, not the number of IPs you cycle through.