IP rotation strategies — per request, on a timer, or on demand

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:

import time
import requests

PROXY = "http://USER:[email protected]: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

curl -X POST \
  -H "Authorization: Bearer $PXL_KEY" \
  https://proxuno.com/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

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.

The full reference for all three rotation methods, including response formats and errors, is in the IP rotation documentation.