Rotating Proxies: Per-Request, Timed & Sticky Sessions
Proxy rotation is the mechanism of automatically changing the exit IP address between requests or on a schedule. There are four distinct rotation models — per-request, timed interval, sticky sessions, and backconnect — each optimized for different use cases. Choosing the wrong model wastes IP resources and triggers detection.
This guide covers the technical mechanics of each rotation type, recommended configurations per use case, provider-specific setup instructions, common mistakes that get proxies banned, and how mobile CGNAT rotation differs from datacenter and residential pools.
What This Guide Covers
Rotation Types Explained
Four distinct rotation models exist, each with different mechanics, trade-offs, and ideal use cases. Understanding the technical differences is essential for choosing the right approach.
Per-Request Rotation
Definition
A new IP address is assigned for every single HTTP request. Each GET/POST uses a different exit IP from the proxy pool.
How It Works
The backconnect gateway selects a new IP from the pool before forwarding each request. No session state is maintained between requests.
Best for:
Web scraping, price monitoring, SERP checking, ad verification
Trade-off:
Maximum anonymity but no session continuity. Cannot maintain login state across requests.
Timed Rotation
Definition
The IP address changes automatically after a fixed time interval (e.g., every 5 minutes, 10 minutes, 30 minutes).
How It Works
A scheduler triggers IP rotation at the configured interval. All requests within the window use the same IP. Once the timer expires, the next request gets a new IP.
Best for:
Balanced scraping, content monitoring, periodic data collection
Trade-off:
Balance between session continuity and IP freshness. Interval must match target site detection windows.
Sticky Sessions
Definition
The same IP address is maintained for a configurable duration (1 minute to 24 hours). All requests within the session window use one consistent IP.
How It Works
Session affinity is maintained via session ID in the proxy authentication (username) or via HTTP headers. The proxy gateway maps the session ID to a specific exit IP.
Best for:
Login sessions, shopping carts, multi-step forms, account management
Trade-off:
Session continuity at the cost of reduced anonymity. Same IP for extended periods increases detection risk on high-security targets.
Backconnect Rotation
Definition
A single gateway endpoint (host:port) automatically routes traffic through different exit IPs. The user connects to one address; the proxy infrastructure handles all rotation behind the scenes.
How It Works
The backconnect server acts as a reverse proxy. Incoming connections are distributed across a pool of exit nodes. Most commercial proxy providers use this model.
Best for:
Simplified integration, large-scale operations, applications that cannot manage multiple proxy endpoints
Trade-off:
Easiest to implement but least control over which IP is used. Rotation logic is provider-controlled.
When to Rotate: Strategies by Use Case
Different tasks require fundamentally different rotation strategies. Using per-request rotation for social media management or sticky sessions for ad verification will cause failures. Match the rotation model to the task.
Web Scraping
Why This Strategy
Each page fetch is independent. Maximum IP diversity minimizes ban risk. No need for session continuity since you are reading public data.
Implementation Tips
- Randomize request delays (3–15s) to avoid pattern detection
- Match User-Agent to proxy type (mobile UA for mobile proxy)
- Monitor success rate per IP — rotate banned IPs out of pool
- Use per-request rotation for catalog pages, sticky for paginated results
Social Media Management
Why This Strategy
Platforms track IP consistency per account. A user switching IPs every request looks like a bot. Real users maintain the same IP for an entire browsing session.
Implementation Tips
- Map each account to a dedicated IP — never share IPs between accounts
- Keep the same IP for 30–60 minutes per session, matching real user behavior
- Use mobile proxies — platforms trust mobile IPs and expect mobile user patterns
- Maintain geo consistency: same country/region for each account
E-commerce / Cart Sessions
Why This Strategy
Shopping cart state is tied to IP + cookies. IP change mid-checkout triggers fraud detection. Rotate between separate shopping sessions, not within them.
Implementation Tips
- Sticky IP for entire browse → add-to-cart → checkout flow
- Rotate IP between separate product research sessions
- Use residential or mobile IPs — datacenter IPs trigger fraud flags on payment pages
- Maintain cookie jar consistency within each sticky session
Ad Verification
Why This Strategy
Each ad check should simulate a different viewer from a different location. No session continuity needed — you are verifying what different users see.
Implementation Tips
- Use geo-targeted rotation to check ads in specific markets
- Per-request rotation with residential or mobile IPs for authentic viewpoints
- Verify ad placement, landing page accuracy, and competitor ad presence
- Log IP geo per request to correlate ad content with viewer location
SEO Monitoring / SERP Tracking
Why This Strategy
Search results vary by IP location. Each query should use a fresh IP from the target country to get unbiased SERP data without triggering CAPTCHA.
Implementation Tips
- Use country-specific proxy pools for localized SERP data
- Rotate IP for each search query to avoid Google CAPTCHA (triggers at ~100 req/IP/hr)
- Add 5–30 second delays between queries from the same IP
- Mobile IPs get 90%+ CAPTCHA-free pass rates on Google
Account Registration
Why This Strategy
Registration flows track IP throughout the process (form fill → email verify → profile setup). IP change mid-registration flags the account as suspicious.
Implementation Tips
- Use a fresh, previously unused IP for each new account
- Complete the entire registration flow on one IP
- Warm up the IP before registration: browse a few pages first
- Never register multiple accounts from the same IP in sequence
Rotation Configuration by Provider
Each proxy provider implements rotation differently. Session IDs in usernames, HTTP headers, API calls, and dashboard schedulers are the four common approaches. Here is how each major provider handles it.
Bright Data
Gateway rotation via session ID in username
Sticky Session Setup
Add -session-{random_id} to username. Example: lum-customer-C123-zone-zone1-session-abc123
Per-Request Rotation
Omit session parameter for per-request rotation. Gateway auto-rotates.
Timed Rotation
Not built-in. Client-side: generate new session ID on timer.
Proxy Format
Note: Session IDs are arbitrary strings. Same session ID = same IP. New session ID = new IP. Sessions expire after 10 minutes of inactivity.
Oxylabs
X-Oxylabs-Session-Id header for sticky sessions
Sticky Session Setup
Set X-Oxylabs-Session-Id: {session_id} HTTP header. Same header value = same exit IP.
Per-Request Rotation
Omit session header for automatic per-request rotation.
Timed Rotation
Client-side: change session ID on timer interval.
Proxy Format
Note: Header-based session control is cleaner than username manipulation. Sessions timeout after provider-defined TTL.
Smartproxy
Session parameter in username
Sticky Session Setup
Username format: user-{username}-session-{random}. Same session string = same IP for up to 10 minutes.
Per-Request Rotation
Omit session parameter for per-request rotation via backconnect gateway.
Timed Rotation
Sessions auto-expire after 10 min. Generate new session ID for forced rotation.
Proxy Format
Note: Maximum sticky session duration is 10 minutes for residential, 30 minutes for mobile.
Coronium
API-based rotation + dashboard controls
Sticky Session Setup
Default behavior: IP persists until manually rotated or timer triggers. Sticky sessions from 1 minute to 24 hours configurable via dashboard.
Per-Request Rotation
Rotate button in dashboard for manual rotation. API endpoint (GET request to rotation URL) for programmatic rotation.
Timed Rotation
Built-in rotation scheduler in dashboard: set interval (5 min, 15 min, 30 min, 1 hr, etc.) and IP auto-rotates on schedule.
Proxy Format
Note: Each proxy is a dedicated physical 4G/5G device. No shared pool — your device, your IPs. CGNAT provides 100K+ unique IPs per modem via carrier rotation.
6 Rotation Mistakes That Get Proxies Banned
These are the most common proxy rotation errors observed in production. Each mistake creates a detectable pattern that anti-bot systems exploit. All are avoidable with proper configuration.
Rotating too fast
Why it fails: Changing IP every 1–2 seconds across hundreds of requests creates a traffic pattern no human produces. Anti-bot systems detect the request velocity and flag the entire subnet.
Fix: Match rotation speed to human browsing patterns. Web scraping: 3–15 second delays between requests. Social media: 30–60 minute sessions. Add random jitter (±50%) to all intervals.
Not maintaining cookies across rotation
Why it fails: When the IP changes but cookies disappear, the target site sees a "new user" on a "new IP" making the exact same requests. This pattern is a strong bot signal — real users carry cookies.
Fix: Persist cookie jars across IP rotations when maintaining a session. Use a cookie manager that survives proxy changes. Only clear cookies when you intentionally want to appear as a new user.
Mixing geographic locations
Why it fails: Request from US IP, then UK IP, then Japan IP — all on the same account in 30 seconds. No human travels that fast. Platforms flag this as account compromise or bot activity.
Fix: Use geo-consistent proxy pools. All rotation IPs for one account/session should be from the same country, ideally the same region. Use provider geo-targeting to lock rotation to a specific country.
Ignoring User-Agent consistency
Why it fails: Sending Chrome 120 User-Agent from IP #1, then Safari 17 User-Agent from IP #2, then Firefox 121 from IP #3. The UA changes with each IP, which no real user does. Fingerprint mismatch is an instant detection signal.
Fix: Lock one User-Agent string per session/account. If rotating IPs for scraping, keep the same UA across all requests in a batch. Match UA to proxy type: mobile UA for mobile proxy, desktop UA for residential.
Using exhausted IP pools
Why it fails: Residential proxy pools degrade over time as IPs get flagged from overuse by multiple customers. A pool that worked 6 months ago may have 30% banned IPs today.
Fix: Monitor success rates per IP and per pool. Remove IPs with >20% failure rate. Mobile proxies avoid this: CGNAT naturally refreshes IPs and carrier rotation provides genuinely fresh IPs that are not shared across customers.
No fallback rotation strategy
Why it fails: When the primary rotation method fails (API timeout, session ID rejected, proxy endpoint down), requests either fail entirely or fall back to a single IP that gets burned immediately.
Fix: Implement a rotation fallback chain: primary rotation method → backup proxy endpoint → different proxy provider → exponential backoff. Log rotation failures separately from target site failures.
Mobile Proxy Rotation: CGNAT vs Forced Rotation
Mobile proxies rotate differently from datacenter and residential proxies. Carrier-Grade NAT (CGNAT) provides a natural rotation mechanism where the carrier itself manages IP assignment, giving mobile IPs inherent trust that no other proxy type can match.
CGNAT Natural Rotation
Mobile carriers use CGNAT (RFC 6598) to share a pool of public IPv4 addresses among thousands of mobile users. When a modem reconnects or the carrier reassigns addresses, you get a genuinely new IP from the carrier's regional pool — typically 100,000+ unique IPs per modem.
Forced Rotation (Datacenter/Residential)
Datacenter and residential rotating proxies use provider-managed IP pools. The provider assigns IPs from their inventory and rotates based on the configured policy. These IPs are shared across all customers using the same pool, which causes pool quality degradation over time.
Mobile Proxy Rotation Methods
Airplane Mode Toggle
Toggling airplane mode on a modem disconnects from the cell tower. Reconnecting triggers DHCP lease renewal, and CGNAT assigns a new public IP from the carrier pool.
Speed
10–30 seconds
IP Diversity
High — accesses full regional CGNAT pool (100K+ IPs)
Use Case
Manual rotation, scheduled rotation via automation
API-Triggered Rotation
The proxy management software sends a command to the modem to cycle the connection. Equivalent to airplane mode toggle but automated and faster.
Speed
1–5 seconds
IP Diversity
High — same pool as airplane mode toggle
Use Case
Programmatic rotation integrated into scraping pipelines
Natural Carrier Rotation
Mobile carriers periodically reassign IPs as part of normal CGNAT operation. Lease durations vary: some carriers rotate every few hours, others hold IPs for 24+ hours.
Speed
Varies (hours)
IP Diversity
Moderate — carrier-controlled frequency
Use Case
Passive rotation for long-running sessions that do not need frequent IP changes
Forced DHCP Renewal
Send a DHCP release/renew command to the modem interface. The carrier may or may not assign a new IP depending on pool availability and lease policy.
Speed
5–15 seconds
IP Diversity
Variable — depends on carrier behavior
Use Case
Soft rotation attempt when airplane mode toggle is too disruptive
Sticky Sessions: When, Why, and How Long
Sticky sessions maintain the same exit IP for a configurable duration. They are critical for any task involving login state, multi-step workflows, or session-dependent data. Coronium supports sticky sessions from 1 minute to 24 hours.
How Sticky Sessions Work
Session ID Mapping
A session ID (either in the username, HTTP header, or managed by the provider) is mapped to a specific exit IP. All requests with the same session ID route through the same IP. Different session IDs get different IPs.
TTL (Time to Live)
Each sticky session has a TTL. When the TTL expires, the session-IP mapping is released. The next request with the same session ID may get a new IP. TTLs vary: Smartproxy maxes at 10 min (residential), Coronium supports up to 24 hours.
Session Renewal
Some providers allow session extension by sending requests before TTL expires. Others require generating a new session ID for a new sticky window. Coronium allows manual extension via dashboard or API without generating new session identifiers.
Multi-Step Form Submission
Form tokens (CSRF) are tied to the IP + session cookie. IP change invalidates the token, causing form submission failure.
Config: Sticky session = form load → fill → submit → confirmation. Rotate after completion.
Login + Authenticated Browsing
Platforms monitor IP consistency during authenticated sessions. IP change post-login triggers re-authentication or security warnings.
Config: Sticky session = login → browse → action → logout. Each login session uses one IP.
Shopping Cart → Checkout
Payment processors flag IP changes during checkout as potential fraud. Cart state may also be tied to server-side sessions keyed by IP.
Config: Sticky session = product browse → add to cart → enter payment → confirm order.
Account Warm-Up
New accounts need to establish a consistent IP history. Frequent IP changes on a fresh account are a strong automation signal.
Config: Use the longest sticky session available. Coronium supports up to 24-hour sticky sessions for account warming.
API Rate Limit Windows
Some APIs track usage per IP with rolling windows (e.g., 100 requests per IP per 15 minutes). Rotating mid-window resets the counter.
Config: Sticky session duration = rate limit window. Rotate when approaching the limit. Use per-request rotation if pool is large enough to stay under limits.
Social Media Session
Platforms expect real users to maintain a consistent IP during a browsing session. Mobile users typically keep the same IP for 30+ minutes.
Config: One sticky session per account per browsing session. Rotate IP between separate sessions (e.g., morning session → new IP → evening session).
Coronium Sticky Sessions: 1 Minute to 24 Hours
Unlike shared-pool providers that cap sticky sessions at 10–30 minutes, Coronium uses dedicated physical 4G/5G devices. The IP persists as long as you need it — from 1 minute for quick form submissions up to 24 hours for account warm-up and long-running authenticated sessions.
1 min
Quick form fills
5–15 min
Shopping carts
30–60 min
Social media sessions
1–24 hours
Account warm-up
IP Pool Freshness and Degradation
The quality of a rotating proxy depends entirely on the freshness of its IP pool. Understanding how pools degrade — and why mobile pools do not — is critical for choosing the right proxy type.
Datacenter Pools
Datacenter IP pools are static. The same IPs are used by multiple customers for months or years. Once an IP gets flagged by one customer's aggressive scraping, it is flagged for all customers. ASN lookup instantly reveals the IP belongs to a hosting provider, not a real user.
Degradation rate: Fast. Pools lose 20–40% effectiveness within weeks on high-security targets. Provider must constantly acquire new IP blocks.
Residential Pools
Residential rotating pools use real ISP-assigned IPs, but they are shared across all provider customers. When pool participants make aggressive requests, those IPs accumulate negative reputation. Pool quality depends on the provider's IP sourcing and pool management.
Degradation rate: Moderate. Top providers maintain pool quality by removing flagged IPs and adding new ones. Budget providers let pools degrade significantly.
Mobile CGNAT Pools
Mobile CGNAT pools are managed by the carrier, not the proxy provider. The carrier continuously rotates IPs across millions of real mobile users. Each IP in the pool carries legitimate mobile traffic. With Coronium's dedicated devices, no other proxy customers share your device.
Degradation rate: Minimal. Carrier continuously refreshes the pool. 100K+ unique IPs per modem. IP trust is maintained by real mobile user traffic on the same pool.
Frequently Asked Questions
Technical answers to common questions about proxy rotation, sticky sessions, backconnect architecture, provider configuration, and mobile CGNAT mechanics.
Mobile Proxy Plans with Built-In Rotation
Dedicated 4G/5G mobile proxies with configurable rotation (per-request via API, timed intervals, or sticky sessions up to 24 hours). Each plan includes a dedicated physical device with unlimited bandwidth.
Configure & Buy Mobile Proxies
Select from 10+ countries with real mobile carrier IPs and flexible billing options
Choose Billing Period
Select the billing cycle that works best for you
SELECT LOCATION
when you order 5+ proxy ports
Carrier & Region
Available regions:
Included Features
🇺🇸USA Configuration
AT&T • Florida • Monthly Plan
Your price:
$129
/month
Unlimited Bandwidth
No commitment • Cancel anytime • Purchase guide
Perfect For
Popular Proxy Locations
Secure payment methods accepted: Credit Card, PayPal, Bitcoin, and more. 2 free modem replacements per 24h.
Start Rotating with Mobile Proxies
Dedicated 4G/5G mobile proxies with 100K+ CGNAT IPs per modem, configurable sticky sessions from 1 minute to 24 hours, API-triggered rotation, and dashboard scheduling. No shared pools — your device, your IPs.
Per-request rotation via API, timed interval scheduling via dashboard, manual rotation with one click. HTTP and SOCKS5 support. Unlimited bandwidth with no per-GB billing.