Sticky Sessions
A sticky session keeps related proxy connections on the same exit IP while the assignment remains active. It is useful when several actions need a consistent network address, but the next independent task can use another one.
Sticky access is often an option within a rotating proxy service: you hold an exit for a task and allow another selection afterward. The broader choice between temporary and lasting IP continuity is covered in Static vs Rotating Proxies.
When keeping the same IP helps
Consider testing a shopping journey: open a product, add it to a cart, select delivery, and review the order. Keeping the exit IP steady removes an unnecessary change between those steps. That matters when the site considers the source IP when checking a session or deciding which regional experience to show.
The same benefit applies to a form completed over several pages, an authenticated browser test, or a sequence of API calls whose access rules expect a consistent source address. You can complete one run through a selected exit, then start the next run separately. The useful boundary is the whole task, including pauses between its steps.
An independent public-page lookup may gain little from that continuity. Sticky access is valuable when an IP change would disturb the work; it does not make every request faster or guarantee acceptance by a website.
How the service recognizes your session
A common method uses a session ID supplied in your proxy settings. You create a label for a task, such as job42, and reuse it on that task's connections. The service associates the label with an exit. Some products instead use a sticky port or an endpoint configured in the dashboard.
The ID must reach the proxy service in the format it supports. It may be part of the proxy username, for example. Adding a session parameter to the destination website's URL does not configure the proxy. There is no universal username pattern or port number for sticky access.
Keep the account, product, gateway and location settings consistent throughout the task. Changing the requested country while retaining the same ID can change the assignment. Some services also scope sessions by the region from which your application connects, so moving a running job between servers can matter too.
Proxy sessions and website sessions
The proxy session selects an exit address. The website's session records things such as your signed-in state or cart, usually using cookies or authentication tokens. Keeping an IP does not store cookies or extend a website login. Your browser or HTTP client still has to retain and send the required state.
This explains two otherwise confusing results. A site can log you out while your IP stays unchanged because its session expired or a cookie was lost. Conversely, a valid website session can survive an IP change if the site's rules allow it. Sticky access controls one part of the connection, not the site's entire decision.
In a script, creating a client object called a “session” may preserve cookies and reuse connections, but it does not automatically enable the proxy provider's sticky mode. Configure the proxy assignment and the client's cookie storage separately. For separate users, use separate browser profiles or isolated client state as well as the intended proxy settings.
Session duration and idle time
The advertised session duration needs a starting point and an expiry rule. A maximum lifetime, often called TTL, can count from the first request or the creation of an assignment. An idle timeout counts a gap without qualifying traffic. A product can enforce both, and its ordinary default may be shorter than its advertised maximum.
For example, suppose a service specifies a 10-minute lifetime and a 1-minute idle timeout. A pause longer than 1 minute can end the assignment before the 10 minutes have elapsed. This is an illustration of two different limits, not a recommended setting. Sending more requests may prevent idle expiry, but it does not necessarily reset the maximum lifetime.
Choose a duration that covers the expected task, slower responses and any human input. Start a fresh assignment before a new run instead of putting it into the last moments of an older session. If a workflow regularly outlasts the available window, a longer advertised timer alone will not resolve interruptions caused by the exit going offline.
An unchanged session ID is not a permanent claim to an address. After the assignment expires, reusing that ID can result in another exit. Nor does a long maximum mean the provider guarantees the original exit will remain online for that entire period.
Running several tasks at once
Assign a separate session ID to each independent task that needs its own continuity. Keep that ID with the task when it moves between processing steps, rather than generating a new value for every request. If a request has to be retried within the same task, unintentionally creating a new ID can defeat the setting you meant to preserve.
For example, two browser tests can each have their own profile and proxy session. All steps of the first test reuse its assignment; the second test manages its own. Opening another ordinary tab in the same profile does not, by itself, create a separate proxy identity or cookie store.
Different session IDs do not guarantee different IPs. Separate assignments can select the same address from the available pool. Stickiness also does not reserve an exit exclusively for you. If your task requires distinct or exclusive addresses, those must be explicit properties of the service you buy.
Several connections can belong to one sticky session where the product supports this. They still share its exit, and account or connection limits still apply. Creating more session labels does not add capacity to your plan.
What happens when the exit disappears
A residential device can disconnect, or a mobile connection can receive another public address. The service may then substitute an exit and continue accepting your requests. Your session label can remain unchanged even though the IP has changed.
Some products offer a stricter option: return an error when the original exit is unavailable instead of silently selecting another. That distinction matters more than the timer when continuing from another IP would invalidate your task. Automatic replacement favours getting the next request through; stopping lets your application decide how to recover.
If continuity is lost, pause the affected workflow and establish which steps succeeded. Resume only if the website accepts the remaining steps from the new connection; otherwise restart from a suitable point. Before repeating an action that submits an order or changes data, check whether the first attempt completed. A missing response does not prove the action failed.
Increasing the TTL cannot bring an unavailable exit back. If you need to return tomorrow through exactly the same address, or keep an address on a server's allowlist, use access with a fixed assignment and suitable replacement terms. A reusable sticky-session name is not enough for that requirement.
Checking your setup
First, send several requests through the configured proxy to a service that reports the source IP. For this check, open new proxy connections while keeping the session ID and routing settings unchanged. Repeating requests over one existing TCP connection can keep the same IP even without sticky mode, so that alone does not prove the assignment works across connections.
Then reproduce the pauses and duration of the real task. Record the exit IP, session label, time and any error. A change after inactivity points you toward an idle limit; a change after a regular elapsed period suggests a lifetime limit. An unexpected change calls for checking availability and whether any request used different proxy settings. These are clues to investigate, not proof of a single cause.
Finally, run the complete browser or application workflow. A successful IP check does not establish that every request in your application uses that configuration or that its cookies survive. The setup is useful when the required steps complete through the intended exit for as long as the task needs, and an interruption leads to a controlled recovery.