Sticky vs Rotating Proxies: Test Session Continuity Before You Buy

Use a sticky proxy session when a task needs a consistent network exit across several requests; allow rotation between tasks when the requests are independent. Keep the application's cookies and other required state separately. A stable IP cannot restore a lost login cookie, and a cookie jar cannot tell a proxy provider which exit to use.

For a developer testing an authorized multi-step workflow, the buying decision is whether the service can preserve the conditions that the whole task requires. This guide gives you a seven-case acceptance worksheet and a way to locate state failures before committing a workload to a plan. It does not report an IPHTML performance test.

Choose the boundary before choosing the rotation setting

Suppose your own staging application has three steps: open a catalog, select a region and retrieve a permitted report. If later steps depend on earlier responses, treat those steps as one job. Decide which state must survive until that job completes, including its bounded waits and retries.

Rotation is not permission to keep retrying a rejection. Respect the target's access policy and rate limits. If an official API provides the required data and state contract, include it in the comparison.

Four different things are often called a session

1. Proxy session label: a provider-specific selection instruction. Its meaning depends on the product. For example, Oxylabs documents its own session-control parameter; that syntax is not an IPHTML configuration recipe.
2. Exit IP: the address observed by the destination for a particular request. A session label is a control input; the observed address is evidence of what happened.
3. Transport connection: the TCP connection or tunnel used by a client. Reconnecting and selecting another exit are different operations; their relationship depends on the proxy implementation.
4. Application context: cookies, relevant browser storage, tokens and server-side state. These belong to the application workflow.

Requests documents cookie persistence and connection pooling in a Session. That client feature does not configure a provider's exit assignment. Playwright's browser contexts isolate cookies and storage; they are useful for separating test jobs but do not promise different public IPs. These are distinct controls, not interchangeable fixes.

MDN explains how cookies carry application state. The destination may also apply expiry, account or network checks. Test its actual contract instead of assuming every application binds a login to an IP.

A diagnostic trace that avoids blaming the wrong layer

The following is an invented trace for a controlled staging application. Its documented behavior requires the same cookie context and exit within the test job. Symbols A and B are labels, not addresses or credentials. Each probe starts again from the same known baseline; they are not sequential mutations of one job.

case       proxy label   cookie context   exit   application result
baseline   job-A         jar-A            A      report ready
reconnect  job-A         jar-A            A      report ready
new jar    job-A         empty            A      sign-in required
new exit   job-B         jar-A            B      restart required

All rows are illustrative, not measured provider results.

The new-jar case points to lost application state even though the IP is unchanged. The reconnect case shows the intended behavior when only transport changes. The new-exit result follows this fixture's stated rule, not a rule for all websites. A changed provider label may select the same exit again; do not mark that case as “different IP tested” unless the observation confirms it.

On your own service, correlate a non-secret job identifier with destination-side request logs to establish the actual exit and application outcome. If you cannot inspect the destination, record that limitation. An IP-check request to a separate host does not prove which exit the original target request used. Keep passwords, cookie values and authorization headers out of shared diagnostics.

Run the seven-case session acceptance worksheet

Download the English session acceptance CSV. It starts with blank observation fields and NOT_RUN statuses. Before running it, specify your target's expected state, the plan's documented behavior, sample count, region, client version and load. The seven cases are a test design, not seven successful requests.

Use PASS, FAIL, INCONCLUSIVE or NOT_APPLICABLE after execution, with evidence and a reason. Do not convert an expected sign-in prompt in S3 into a provider failure. Do not run purchases or other irreversible actions as retry tests. For a real side effect, use the application's documented idempotency/reconciliation procedure; a proxy label cannot prevent duplicate transactions.

Repeat relevant cases at your intended regions and concurrency, reporting runs and failures rather than a universal pass percentage. For ongoing delivery, use the separate job-level reliability scorecard; a small acceptance run cannot establish long-term uptime.

Budget elapsed time, including the gaps

Here is a hypothetical configured job budget: step A at most 20 seconds, step B 40 seconds, step C 30 seconds, combined waiting/retry allowance 45 seconds and scheduling margin 15 seconds. The total is 150 seconds. These are chosen upper bounds enforced by the job runner, not measured averages or percentiles.

job wall-clock budget = 20 + 40 + 30 + 45 + 15 = 150 seconds
start the timer before the first proxy-backed step
stop or safely restart if the job cannot finish within its budget
verify session expiry, idle timeout and exit-loss behavior separately

Ask when the provider's session clock starts, whether activity extends it, and what happens if an exit becomes unavailable. Include any session age before job start. A nominal duration longer than 150 seconds is only one requirement; it does not prove continuous availability. Do not add step p95 values and call the result an end-to-end p95.

Turn the result into a useful purchasing conversation

Before evaluating IPHTML rotating proxies, prepare the authorized domains and steps, required region, longest job budget, expected concurrency, necessary application state and restart rules. Ask for the current configuration and session behavior for the specific plan. Confirm whether you need temporary continuity or a separately assigned address; do not copy another vendor's parameter into your credentials.

Contact IPHTML with your requirements and redacted worksheet once you can describe a representative job. Advance only when the required cases meet your agreed criteria and commercial terms fit the workload. Unresolved state changes are a reason to investigate before expanding usage, even when every individual request returns HTTP 200.