A proxy gateway offers three rotation modes, static, rotating, and session-based, and the right mode is decided by the workload: static keeps one egress path for persistence, rotating changes the path per request for freshness, and session-based changes per session for a balance of both. The mode is a pool setting, so one gateway serves teams with different needs at the same time.
This guide explains the modes, how to match mode to workload, and what to check on the gateway before choosing.
The Modes
| Mode | IP behavior | Best for |
|---|---|---|
| Static | Same egress path per session | Stable sessions, owned accounts |
| Rotating | New path per request | Freshness-sensitive workloads |
| Session-based | New path per session | Mixed workloads, QA runs |
Static mode keeps the same egress path for a session, which suits workloads that need persistence: an account session that must not hop mid-task, or a test that requires one identity for its duration. The stability is the value, and the trade-off is less address variety.
Rotating mode changes the egress path per request, which suits workloads that need freshness: data collection that must not be recognized by a repeated address, or tasks that benefit from cycling through the pool. The variety is the value, and the trade-off is no persistence.
Session-based mode sits between: the path is stable within a session and changes between sessions, which suits mixed workloads where each task wants persistence but the fleet wants variety across tasks.
The mode names vary by vendor: some platforms call session-based rotation sticky sessions, and others call static mode sticky IPs, so the buyer should map the terminology to the behavior, not the label. The behavior test is the reliable way to compare products.
The mode also interacts with the carrier's addressing: a static mode can only keep the path stable if the carrier keeps the address for the session, so the carrier behavior sets the mode's ceiling. The verification per market is part of the mode choice.
The cost difference between modes is mostly indirect: static pools may need more SIMs to cover the workloads, rotating pools cycle the same fleet, and the real cost is capacity planning, not the mode label. The capacity plan should be sized for the mode's behavior.
The mode choice should also consider the target's behavior: a workload whose target treats repeated addresses or frequent changes differently benefits from the mode that matches the target's tolerance. The target context is part of the workload description.
Matching Mode to Workload
The matching rule is simple: ask what the workload needs, persistence or freshness, and choose the mode accordingly. A workload that needs both gets session-based, and a workload with several tasks gets several pools, each with its own mode.
Account and operations workloads lean static: a management session, an owned-account login, or a stable test wants one path for its duration, and static mode delivers it. The persistence is the property the workload depends on.
Collection and monitoring workloads lean rotating: frequent requests across many pages benefit from changing paths, and rotating mode spreads the request identity across the pool. The freshness is the property the workload depends on.
The mode can be changed per pool without new hardware, which is the gateway's flexibility: a team that shifts from one workload to another changes the setting, not the purchase. The flexibility is what makes the mode decision low-risk.
The workload should be described before the mode is chosen: the session length, the request frequency, and whether a changing address matters, because the description is what the mode decision answers. A workload that was never described produces a mode that was never justified.
The mixed-team case is where the per-pool design pays: account operations on a static pool, data collection on a rotating pool, and QA on a session-based pool, all on one gateway with no conflict. The pool design is the interface that makes the mix work.
The mode review belongs in the operations routine: when a workload changes, the mode should be re-checked, because a workload that shifted from persistence to freshness keeps a static mode only out of habit. The review keeps the configuration matched to the work.
The decision can be validated with a pilot: run the workload on the candidate mode for a week, compare the success metrics, and adjust before the full rollout. The pilot is the evidence for the mode choice, and it is cheap at pool scale.
The written pool plan should state the mode and the reason for each pool, because the reason is what the next review, the next operator, and the next audit read. The plan turns the mode from a setting into a decision.
What to Check on the Gateway
The first check is per-pool mode configuration: can each pool have its own rotation mode, and can a user or application be assigned to a pool with the mode it needs? The per-pool design is what serves multiple teams on one gateway.
The second check is the mode behavior in practice: how quickly rotation changes paths, whether a session keeps its path under static or session mode, and what the gateway reports per connection. The behavior is verified with a test, because the datasheet's mode names are only the start.
The third check is the reporting: the connection logs should show the egress path per session and the rotation behavior, because the records are what confirm the mode is working and support the operations review. The proxy gateway reporting is the evidence for the mode decision.
The fourth check is the rotation control surface: whether rotation happens per request, per session, or per time interval, and whether the operator can tune the behavior. The control surface is what makes the mode a management choice rather than a fixed behavior.
The fifth check is the failover interaction: what happens to a session when its path fails under static mode, and how rotating mode selects the next path. The failover behavior is part of the mode's reliability, and it is tested, not assumed.
The documentation should include the mode behavior: what each mode does, how it was verified, and which pools use it, because the record is what a new operator reads and a review relies on. The documentation is part of the gateway's operations.
Telarvo Expert Views
The mode question is the workload question: persistence or freshness. We advise buyers to define the workload's need first, then assign pools with the matching mode, because one gateway with per-pool modes serves the whole team and the setting can change as the workload does.
— Network Infrastructure Engineer, Telarvo Store
Validation note: rotation and persistence behavior depend on the carrier's addressing; verify per market with a session test.
Conclusion
The rotation choice is workload-driven: static for persistence, rotating for freshness, session-based for both, configured per pool so one gateway serves every team and changes as the workload does.
Key Takeaways for B2B Buyers
Define the workload's need first, assign pools with the matching mode, verify the behavior with a session test, and use the connection records to confirm the mode is working.
Questions to Ask Before Committing
Ask whether each pool can have its own mode, how rotation behaves in practice, what the gateway reports per connection, and how the mode is changed later.
Ask Telarvo Store which proxy gateway supports your per-pool rotation plan before you deploy.
FAQs
What is the difference between rotating and static proxies?
Static keeps one egress path per session for persistence; rotating changes the path per request for freshness, and session-based balances the two.
Which mode is best for account management?
Static or session-based, so each session keeps its path; the workload's need for persistence decides.
Can I change the mode later?
Yes; the mode is a pool setting, so it changes in configuration without new hardware.
Does rotation improve speed?
No; rotation changes the egress identity, not the path speed, so choose it for freshness, not performance.
What is a sticky session?
A mode where a session keeps the same egress path for its duration, which is the behavior many platforms call sticky; it is the session-based option.
Can different users use different modes on one gateway?
Yes, when the gateway assigns pools per user or application; the per-pool mode is the design that makes the mix possible.
Why is my session dropping mid-task?
Under static or session mode, a dropped session is usually a carrier or SIM issue; check the path health and the mode's failover behavior.
Does the mode affect the number of IPs?
Rotation cycles the addresses the carrier provides, so the mode changes which addresses appear over time, while the pool's unique address count is still carrier-set.