# IP rotation strategies — per request, on a timer, or on demand
Source: https://proxuno.com/blog/ip-rotation-strategies
Updated: 2022-11-29

> Dashboard v2 ships with scheduled rotation every 5 to 60 minutes. When should you rotate on a timer, when on demand, and when not at all? A practical guide with code for each approach.

With today's release of dashboard v2, every mobile proxy can rotate its IP automatically on a schedule, from every 5 to every 60 minutes. That gives you three ways to change addresses: **on a timer**, **on demand** (button, API or rotation link) and **never** (keep the address for the whole plan). Choosing well between them matters more than any other setting for success rates on difficult targets.

## What a rotation does

On a dedicated mobile proxy, a rotation detaches the modem from the carrier network and attaches it again. The carrier assigns a new internal address, and outgoing connections are mapped to a public address from its CGNAT pool. It takes a few seconds — typically 5 to 15 depending on the carrier — and during that time:

- **Open connections are dropped.** Any request in flight fails with a connection reset.
- **New connections wait or fail** until the modem is attached again.

So every strategy below is really about one question: *when can your workload tolerate a short interruption and a new identity?*

## Strategy 1: rotate on a timer

Scheduled rotation suits workloads made of many short, independent tasks where the identity does not need to persist:

- search result tracking (each query is independent);
- price checks across many product pages;
- availability monitoring.

**Choosing the interval.** Start from your target's tolerance. If you see the first throttling responses (HTTP 429, CAPTCHAs, empty result pages) after roughly N minutes of traffic on one address, set the interval comfortably below N. For most retail and search targets we see customers settle between 10 and 20 minutes.

**Handle the gap.** A scheduled rotation will happen in the middle of something eventually. Your client needs retries with backoff on connection errors:

```python
import time
import requests

PROXY = "http://USER:PASS@fr.mobile.{{gatewayDomain}}:PORT"
session = requests.Session()
session.proxies = {"http": PROXY, "https": PROXY}

def fetch(url, attempts=4):
    for i in range(attempts):
        try:
            r = session.get(url, timeout=30)
            if r.status_code == 429:
                raise requests.RequestException("throttled")
            return r
        except requests.RequestException:
            time.sleep(2 ** i * 3)   # 3 s, 6 s, 12 s, 24 s — covers a rotation
    raise RuntimeError(f"giving up on {url}")
```

The first backoff step of a few seconds is enough to ride over most rotations without logging an error.

## Strategy 2: rotate on demand

On-demand rotation is better when your code knows when an identity is "used up":

- you finished a batch of work for one account or one search;
- the target started returning challenges;
- you are about to start a new browser profile.

You can trigger it three ways. All of them respect a **10-second minimum** between two rotations of the same proxy; calling earlier returns the `rotation_cooldown` error with the number of seconds to wait.

### From the API

```bash
curl -X POST \
  -H "Authorization: Bearer $PXL_KEY" \
  https://{{domain}}/api/v1/proxies/PROXY_ID/rotate
```

The response contains the old and new IP once the modem has a new address, so your code can continue immediately.

### From a rotation link

Each proxy has a secret rotation URL. Calling it with a plain GET rotates the proxy — useful in tools that can call a URL but cannot send authenticated API requests, such as some antidetect browsers and no-code scrapers. Treat the link like a password: anyone who has it can rotate your proxy. You can regenerate it at any time from the proxy page.

### Combining with a timer

You can enable both. If you rotate on demand frequently, a long timer (30–60 minutes) works as a safety net that guarantees the address never stays the same for too long.

## Strategy 3: do not rotate

For **logged-in accounts**, rotation is usually counter-productive. Platforms tie account sessions to cookies and device fingerprints; a session whose IP changes every ten minutes looks like a hijacked account, not like a careful user.

For account work we recommend:

- one proxy per small group of accounts, used consistently over days or weeks;
- scheduled rotation **off**;
- a manual rotation only when you retire an account or if the address itself gets flagged.

Remember that a mobile IP is already shared with many real subscribers through carrier-grade NAT. Keeping one for a while is completely normal behaviour on a mobile network.

## Choosing between them

| Workload | Recommended | Why |
|---|---|---|
| Search tracking, price checks | Timer, 10–20 min | Independent requests, steady throughput |
| Crawls with clear task boundaries | On demand via API | Rotate exactly between tasks |
| Antidetect browser profiles | On demand, per profile | One identity per profile session |
| Social or marketplace accounts | No rotation | Session consistency matters more |
| Mixed workloads | Split proxies by role | Do not mix accounts and crawling on one IP |

## Measuring whether it works

Rotation should be tuned with data, not guesswork. For each proxy, log:

1. **Success rate per address** — the share of 2xx responses with the expected content.
2. **Time to first challenge** — how long after a rotation the first 429 or CAPTCHA appears.
3. **Address reuse** — the rotation history in the dashboard shows the old and new IP of each rotation; if the same addresses recur often, lengthen the interval so each rotation draws from a less busy part of the carrier pool.

If success drops right after rotations rather than before, the issue is more likely your client fingerprint or pacing than the IP — see our notes on [CGNAT and IP reputation](/blog/cgnat-and-mobile-ip-reputation).

The full reference for all three rotation methods, including response formats and errors, is in the [IP rotation documentation](/docs/ip-rotation).