Choose rotation for independent requests when a changing exit is acceptable. Choose a sticky session when several steps need the same public exit, and verify what the provider does if that exit disappears. Neither option guarantees that an individual network connection will survive.
Request, connection and proxy session are separate
A library may reuse a connection or an HTTPS CONNECT tunnel for multiple requests. HTTP CONNECT establishes a tunnel that forwards bytes until it closes; changing a session name for later connections does not migrate a running tunnel to a new exit. A client expecting a new address for every application request must check the provider's rotation rule and its own connection reuse. HTTP CONNECT semantics: www.rfc-editor.org/rfc/rfc9110.html#section-9.3.6.
Keep four limits distinct: the client's request timeout, the lifetime of its connection, the provider's sticky-session and idle limits, and the paid product's validity. Raising a request timeout cannot restore a disconnected peer or expired traffic allowance.
Read the actual sticky-session contract
Oxylabs' residential documentation gives a concrete example: ordinary sessions default to 10 minutes and can end after 60 seconds idle. A configured duration can reach 24 hours, but the peer can leave earlier. The ordinary session identifier may then select a different IP. Its separate sessid_oneip mode returns HTTP 502 when that exit disappears, so a workflow can detect the loss instead of accepting a replacement. These are Oxylabs-specific rules, not defaults for every provider. Session control and one-IP mode: developers.oxylabs.io/products/proxies/residential-proxie….
A saved proxy-session name is not a browser cookie, login or server-side application session. Keep those separate and decide whether the application can safely resume after an address change.
Recovery decision
- Independent read: retry within a bounded attempt/time budget if the operation is safe to repeat; record whether the exit changed.
- Multi-step workflow that requires one exit: stop after losing that exit. Re-establish the required identity and restart from a safe checkpoint; do not silently replay later steps against a replacement peer.
- Operation that may have changed remote state: check its outcome or use the application's supported idempotency mechanism before retrying. A broken connection does not establish that the operation failed before being applied. HTTP retry and idempotency rules: www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2.
Questions to answer before buying
- Does rotation occur for every request, new connection, timed interval or explicitly requested session?
- What is the maximum duration, idle timeout and behavior when the peer leaves?
- Can the service fail instead of switching when the exact same IP is required?
- Does the chosen plan charge for failed requests, reconnections or extra targeting?
- When do unused GB or the rented IP allocation expire, and does the purchase renew?
Use the provider buying-conditions directory and price calculator to shortlist documented terms. Confirm the plan-specific answers with its sources before payment. The decision path above is documentation-based; no provider connection or live recovery test was performed for this guide.
Sources reviewed 2026-09-28. When raising a session problem with a provider, include the product, session mode, idle interval and observed error; keep credentials out of the message.