Sticky Session

A sticky session is a proxy gateway binding that holds one exit IP for a fixed time to live, or until you stop sending the session token, instead of drawing a fresh address on every request. You request it, the gateway assigns a peer, and every request carrying that session identifier leaves from the same address until the TTL expires or the peer disappears.

The identifier is almost always packed into the proxy username rather than passed as a separate field, alongside the country, city and duration parameters. Ceilings vary far more than the common ten minute default suggests. Decodo's residential quick start documentation, read on 2026-07-27, states that sessions of up to 24 hours can be selected, and IPRoyal's residential proxies page on the same date advertises keeping the same proxy for up to 7 days. Short ceilings measured in single minutes are still common elsewhere, so read the vendor's own docs rather than assuming. What no vendor can promise is that the peer stays online. Residential exits are real devices on real connections and they drop. When one does, the gateway either fails the request or quietly substitutes a different address, and you often find out which by watching the target reject a session cookie mid flow.

Stickiness is genuinely required wherever the target tracks a continuous identity: multi step checkout, anything behind a login, paginated results held open by a server side cursor, any form carrying a CSRF token. Everywhere else it is a liability. Holding one address concentrates your request volume on it, which is exactly the pattern per IP rate limiting exists to catch. Thirty minutes of steady requests from one exit earns a block faster than the same requests spread across thirty exits.

Set the TTL to cover your longest single request chain and nothing beyond it. Measure that chain instead of guessing: time the slowest complete flow in production, add margin for retries, and use that number. Then handle the failure case explicitly, because a mid session IP swap is normal rather than exceptional. Detect it by tracking session cookie rejections and restart the chain from the top rather than continuing with a half valid state. If a chain honestly needs hours of the same address, the answer is usually to shorten the chain or move to a static ISP address rather than to raise the TTL.