Rotation defines how often your exit IP changes. This guide explains request-based and time-based rotation, how they behave in real tasks, and how to choose sensible settings. If you’re new to rotation in general, start with the static vs rotating proxies guide.
What is request-based rotation?
Request-based rotation assigns a fresh exit IP for every new request or connection. It maximizes distribution across an IP pool but prevents long-lived, IP-sticky sessions.
With request-based rotation, your client hits a gateway that returns a different egress IP each time. Depending on the provider, “request” may mean HTTP request, new TCP connection, or a configurable trigger (for example, a query flag like ?refresh=true). This mode is common when you want wide spread across many targets or need to fan out traffic patterns quickly without maintaining state per session.
Typical use cases
- Fan-out scraping where each item can be fetched independently.
- Broad coverage tasks that benefit from many unique IPs per minute.
- Short tasks that do not require cart persistence, login, or streaming.
Configuration tips
- Prefer stateless clients and idempotent requests.
- Avoid cookie or cart flows that expect the same IP between steps.
- Monitor duplication rate: large pools reduce accidental IP reuse.
Trade-offs
- Pros: maximal IP diversity, simple client logic, fast churn.
- Cons: breaks flows that rely on IP continuity; harder debugging.
What is time-based rotation (by interval)?
Time-based rotation (by interval) assigns one exit IP for a fixed window (for example, 1, 10, or 30 minutes), then swaps to a new IP automatically. It balances continuity for multi-step flows with periodic churn to refresh reputation.
Providers usually implement interval stickiness per port or per session token. You keep one IP throughout the window for all connections tagged to that port/session, then receive a new one when the timer elapses. Many services let you choose the interval in the dashboard, in the endpoint path, or via a session parameter.
Typical use cases
- Logged-in flows, checkouts, carts, and form wizards.
- API polling where stable IPs reduce risk flags.
- Data capture that benefits from fewer cookies and CAPTCHA resets.
Configuration tips
- Map each logical user or bot to a dedicated session/port.
- Choose an interval that covers the whole flow plus a buffer.
- Reset the session only when the flow is complete (or when blocked).
Trade-offs
- Pros: session continuity, fewer risk challenges, simpler cookies.
- Cons: lower IP churn; if an IP gets flagged, it persists until the window ends.
Comparing request vs interval rotation
Request-based rotation changes IP on every request; interval rotation holds one IP for a set time, then rotates. Choose request-based for breadth and speed, interval for stateful flows.
| Aspect | Request-based (per request/connection) | Time-based (per interval) |
| IP change trigger | Every request or connection | Timer window (for example, 1–30 min) |
| Best for | Broad coverage, parallel fan-out | Multi-step flows, carts, dashboards |
| Session continuity | None (unless app is fully stateless) | Stable within the window |
| Pool pressure | High churn uses more unique IPs | Lower churn, fewer IPs per unit time |
| Block recovery | Immediate via next request | Wait until window ends or reset session |
| Client complexity | Stateless patterns shine | Requires session/port management |
| Debugging | Harder to trace a single user path | Easier to reproduce within a session |
How network type influences rotation choices
Different proxy networks favor different rotation windows due to how IPs are sourced and routed. As a rule of thumb, datacenter or ISP networks tolerate longer windows, while residential or mobile peers often work better with shorter windows.
This is tied to the underlying proxy network types you use; DC and ISP gateways usually offer stable capacity and allow longer per-session stickiness, while residential and mobile peers may be behind CGNAT and have variable availability, so shorter windows reduce stale peers and mitigate transient issues. For a primer, see our proxy network type overview.
Choosing a sensible interval
Pick the shortest window that safely covers your whole user flow, with a margin for retries. Short flows (single form + confirmation) often work with 1–5 minutes; long dashboards or batch jobs may need 10–30 minutes.
Quick method
- Time the flow end to end under good conditions.
- Add 30–100 percent buffer for captchas, queues, or retries.
- Set that as your rotation window for the session or port.
- If you’re consistently finishing early, reduce the interval to increase churn; if you’re overrunning, increase it.
Signals to adjust
- Too short: session invalidations, forced re-login, broken carts.
- Too long: higher block rates over time, stale cookies, reputation decay.
When request-based rotation wins
Request-based rotation is best when each unit of work is independent and benefits from maximum IP diversity. It also suits mass-parallel workloads where backpressure and retry logic live in the client scheduler.
Patterns that work well
- Distributed fetching where every URL can be retried with a new IP.
- Rate-limited APIs where many distinct IPs improve throughput.
- Collecting public assets that don’t share state.
Practical notes
- Implement exponential backoff and jitter to avoid herd effects.
- Track pool hit-rate and duplicate IP frequency to verify spread.
- Keep cookies off unless explicitly required by the target.
When time-based rotation wins
Time-based rotation fits tasks that require continuity: logged sessions, carts, dashboards, and anything that ties cookies, tokens, or anti-abuse scoring to an IP. It’s also useful when you want fewer moving parts in debugging.
Patterns that work well
- Account actions over several steps with a predictable duration.
- Periodic polling that benefits from a stable source address.
- A/B tests where you keep one IP per test subject during the window.
Practical notes
- Use one session/port per logical user or thread to avoid cross-talk.
- Rotate proactively after critical milestones to shed reputation.
- Log the assigned IP and window start time for incident review.
How geo targeting interacts with rotation
Rotation and geo are separate knobs: rotation changes IP identity, while geo targeting picks location. Keep the geo fixed during a stateful session; changing both geo and IP mid-flow increases risk. For geo depth options and trade-offs, see the proxy geo targeting guide.
Configuration examples (conceptual)
Note
Always test via real HTTP/HTTPS requests or your target app, not ICMP ping.
Request-based gateway
http://gw.example:8000/?refresh=true
- Each new request (or refresh=true) yields a new IP.
- Use stateless clients; do not rely on cookies across calls.
Time-based stickiness (per session token)
http://gw.example:8000/session=shopperA?interval=10m
- All requests with session=shopperA stay on one IP for ~10 minutes.
- Start a new session token after checkout to refresh the IP.
Time-based stickiness (per port)
http://gw.example:9001 # Port bound to 15-minute window
- Route each logical user to a dedicated port to avoid collisions.
- When the window expires, the gateway assigns a fresh IP automatically.
Quick decision guide
- Stateless, fan-out workload? Use request-based rotation.
- Multi-step, cookie/token flow? Use time-based rotation with the shortest safe window.
- DC/ISP networks? Longer windows often fine; reduce if blocks rise.
- Residential/Mobile networks? Prefer shorter windows to avoid stale peers and CGNAT quirks.
FAQs
How do I know if my provider uses request or interval rotation?
Check the gateway docs for “session,” “sticky,” “interval,” or per-port settings. If every request yields a new IP and there is no session control, it’s likely request-based.
Can I force a rotation before the interval ends?
Usually yes. Many gateways let you end a session token or call a refresh parameter to trigger a new IP.
What interval should I start with for carts and checkouts?
Time your flow, add a safety buffer, and try 5–10 minutes. If blocks grow over time, shorten; if sessions cut off mid-flow, lengthen.
Does rotation affect my geo targeting?
Rotation changes the IP identity, not the region setting. Keep the same geo during a session to reduce risk; change geo between sessions.
Why do some sessions “stick” longer than configured?
Providers may align rotations to internal timers or wait for idle; also, clock skew and connection reuse can extend practical stickiness slightly.