A sticky session is not a permanent-IP guarantee. It is a provider-defined mapping from a session key and routing scope to an available exit. The mapping may have wall-clock or idle limits, and a dynamic residential or mobile peer can disappear before either limit. First prove that the session identity and request path stayed fixed.
The same visible token is only one part of the same session.
Record the full session identity
Treat these fields as one tuple. A change to any field can create a different routing context even when the session label looks unchanged.
| Field | Record | Why it matters |
|---|---|---|
| Provider and product | Residential, mobile, ISP, or another exact proxy type | Session rules can differ inside one provider |
| Gateway and protocol | Endpoint alias, port, HTTP CONNECT or SOCKS mode | A different entry path can create a different mapping |
| Client region | Coarse source region or worker location | Some networks scope sessions by where the client enters |
| Route tuple | Country, state, city, ASN, carrier, or other active filters | Changing a routing parameter can reset context |
| Session key | A masked label or local hash | A regenerated key asks for a new session |
| Worker and path | Worker alias and whether proxy bypass was possible | Mixed traffic can look like one session changing exits |
- Field
- Provider and product
- Record
- Residential, mobile, ISP, or another exact proxy type
- Why it matters
- Session rules can differ inside one provider
- Field
- Gateway and protocol
- Record
- Endpoint alias, port, HTTP CONNECT or SOCKS mode
- Why it matters
- A different entry path can create a different mapping
- Field
- Client region
- Record
- Coarse source region or worker location
- Why it matters
- Some networks scope sessions by where the client enters
- Field
- Route tuple
- Record
- Country, state, city, ASN, carrier, or other active filters
- Why it matters
- Changing a routing parameter can reset context
- Field
- Session key
- Record
- A masked label or local hash
- Why it matters
- A regenerated key asks for a new session
- Field
- Worker and path
- Record
- Worker alias and whether proxy bypass was possible
- Why it matters
- Mixed traffic can look like one session changing exits
Do not paste a full proxy username or Proxy-Authorization value into a log. Create a masked label or local hash before the client builds its authentication header, then use that same non-secret label in every evidence row.
Change one variable. Record what moved.
Use local aliases only. Never enter a password, full username, full provider session key, real IP address, or customer identifier. Nothing in this recorder leaves the page.
Record two complete observations.
A comparison needs the session, worker, timing, route, and exit aliases for at least two rows.
- Unexplained by the recorded evidenceNo supported cause is visible yet. Add another controlled observation or change one variable at a time.
Four controlled lanes
Each lane asks a question. It does not promise how a provider will behave.
| Lane | Hold constant | Question |
|---|---|---|
| Continuity | Same session label, worker, and route scope; short idle gaps | Does the exit alias remain stable across consecutive observations? |
| Idle boundary | Same session, worker, and route; gaps on either side of a documented threshold | Does the exit alias change only after the documented idle threshold? |
| Worker handoff | Same session and route scope; change only the local worker alias | Does session continuity follow the session label across authorized workers? |
| Direct-path control | A separate direct fingerprint alias, then an otherwise unchanged proxied run | Does any proxied observation match the direct-path alias? |
Five causes that fit the evidence
1. The session key is absent or regenerated
A harness can accidentally create a random token inside the request function rather than once per workflow. Three requests then look like one sticky test in the application log while the provider sees three session keys. Compare your masked session label before each request. If it changes, fix that control before judging the network.
Bright Data documents (opens in a new tab) a client-controlled session value. Oxylabs documents a session identifier (opens in a new tab), while Decodo documents sticky-session setup and duration (opens in a new tab). The syntax is provider-specific. The test principle is not: hold the documented key constant.
2. The documented lease expired
There is no universal sticky duration. Products can use a maximum lifetime, an inactivity limit, or both. The applicable values may vary by network and plan, so put the exact documentation next to the row rather than relying on memory.
| Product documentation | Published session behavior | How to use it |
|---|---|---|
| Oxylabs Residential | Standard ten-minute session and up to sixty seconds of inactivity | Test against the rule for the exact entry mode you use |
| Decodo Residential | Ten-minute default with configurable durations for custom sticky sessions | Record both session and duration configuration |
| Bright Data Residential | Five-minute idle example in its residential guidance | Treat this as a product example, not an industry default |
- Product documentation
- Oxylabs Residential
- Published session behavior
- Standard ten-minute session and up to sixty seconds of inactivity
- How to use it
- Test against the rule for the exact entry mode you use
- Product documentation
- Decodo Residential
- Published session behavior
- Ten-minute default with configurable durations for custom sticky sessions
- How to use it
- Record both session and duration configuration
- Product documentation
- Bright Data Residential
- Published session behavior
- Five-minute idle example in its residential guidance
- How to use it
- Treat this as a product example, not an industry default
Check the current Oxylabs residential quick start (opens in a new tab), Decodo session guidance (opens in a new tab), and Bright Data residential FAQ (opens in a new tab) before testing. Vendor rules can change.
3. The assigned exit disappeared
Residential and mobile exits can go offline. The provider may return an error, end the session, or assign a replacement according to that product's rules. Bright Data, for example, documents an unavailable-peer sequence that can return 502 before a later request receives a replacement peer under the same session ID. Do not generalize that exact sequence to every network.
A provider error immediately before an exit change is useful sequence evidence. It is not enough by itself to label the cause peer loss. Keep the exact provider code or permitted correlation header and ask support to match the event.
4. A session-scope field changed
A country, city, gateway, product, protocol, client region, or worker change can alter the mapping. Bright Data explicitly warns that changing location or other routing parameters loses session context. Other providers define scope differently, so compare the complete documented tuple rather than assuming the token controls everything.
5. The observations used different paths
Playwright supports a proxy bypass list (opens in a new tab). cURL honors NO_PROXY and --noproxy (opens in a new tab). A direct request, a second worker with another key, or rows combined from different products can look like one sticky session changing IP. Record a direct-path fingerprint once, keep worker lanes separate, and verify proxy use for the exact echo host.
Run the controls in four lanes
| Lane | Hold fixed | Question |
|---|---|---|
| A. Stability control | One key, route, worker, and gaps below the documented idle limit | Does the exit remain stable inside the stated conditions? |
| B. Expiry control | Same key and route, with one intentional gap beyond the documented limit | What does documented expiry look like for this product? |
| C. New-key control | Route and worker fixed, with an intentionally new key | Does the product assign a new mapping, acknowledging that the same exit can recur by chance? |
| D. Worker control | Two workers with separate fixed keys and separate logs | Does each lane remain internally consistent without log mixing? |
- Lane
- A. Stability control
- Hold fixed
- One key, route, worker, and gaps below the documented idle limit
- Question
- Does the exit remain stable inside the stated conditions?
- Lane
- B. Expiry control
- Hold fixed
- Same key and route, with one intentional gap beyond the documented limit
- Question
- What does documented expiry look like for this product?
- Lane
- C. New-key control
- Hold fixed
- Route and worker fixed, with an intentionally new key
- Question
- Does the product assign a new mapping, acknowledging that the same exit can recur by chance?
- Lane
- D. Worker control
- Hold fixed
- Two workers with separate fixed keys and separate logs
- Question
- Does each lane remain internally consistent without log mixing?
Use at least three observations per lane, but do not turn three rows into a provider-wide stability rate. Keep retries and keep-alive traffic out of the first comparison. A periodic keep-alive is provider-specific, consumes traffic, and changes the workload you are trying to observe.
Build a support packet without secrets
- coarse timestamps, elapsed time, idle gaps, and worker aliases;
- provider and product, gateway alias, protocol, client region, and full non-secret route tuple;
- masked session labels, never full usernames, passwords, or authorization headers;
- CONNECT and response status, provider error or correlation code, and redirect count;
- exit aliases in sequence, plus a separately recorded direct-path fingerprint; and
- the first change marker, its supported suspects, and any row that remains unexplained.
Use the status hub for 407, 429, timeout, or provider-error rows. Use the four-cell diagnostic when cURL and the browser appear to take different paths, and the timing worksheet when an idle or deadline boundary is unclear. Publish broader claims only under the methodology and responsible-use policy.