Proxy Rotation Interval: How Often Should Your IP Change

Rotation settings come in five broad shapes. Most providers offer two or three of them, under different names.

Two details decide how a timed mode behaves in practice, and providers do not always state them. First, whether the timer runs per session, per connection or per account: a single timer shared by all your threads means every thread exits through the same IP for the interval. Second, whether the timer starts at first use or on a fixed clock: a clock that ticks over at :00, :05 and :10 can rotate a session that started 20 seconds earlier. The verification script later in this guide answers both questions for your plan.

Every choice sits between a floor and a ceiling.

The floor (minimum interval) is the time a unit of work needs one stable IP. A login followed by eight page views and a logout might take 90 seconds. Rotating faster than that breaks the flow, because the site sees a session cookie arrive from a new address.

The ceiling (maximum interval) is how long one IP can carry your traffic before the target's per-IP counter trips. If a site tolerates about 60 requests per IP in 10 minutes, and a session sends a request every 2 seconds, that IP is spent after 2 minutes.

Write the two numbers down for each target:

That table is the whole method. The rest of this guide is about measuring the two numbers honestly.

The ceiling comes from a simple ratio:

maximum interval = requests tolerated per IP in the target's window / requests per minute you send through that IP

Illustrative example, not a measured limit: a retail site returns 429s once one IP passes about 60 requests in any 10-minute window.

Two things make the real ceiling lower than the table suggests.

Shared exits multiply the rate. If ten threads share one sticky IP during an interval, the per-IP rate is ten times the per-thread rate. A 5-minute timer that is safe for one thread can be spent in 30 seconds by ten.

Windows are often layered. Sites commonly count per minute, per hour and per day at once. A 3-minute interval can respect a per-minute limit and still exhaust a per-hour one if the pool keeps handing you the same IPs. The next-but-one section covers that.

You rarely know a target's limit in advance. Estimate it by holding one IP and sending requests at a steady pace until status codes change, then take the count just before the change as your budget. Our guide to managing per-IP request limits covers that measurement in detail.

The floor comes from your workflow, not the target. List every sequence of requests that must share an IP, and time the longest one end to end, including waits.

Common flows and what drives their length:

• Paginated listings with a session cookie. Pages times delay per page. Twenty pages at 3 seconds each is a one-minute floor.
• Search, filter, then detail pages. Many sites bind filter state to the session, so the whole chain needs one IP.
• Cart and checkout checks. Price and shipping checks that add an item, set a postcode and read the total often run 30 to 90 seconds.
• Logged-in reads. Login, a handful of pages, logout. Sites that fingerprint sessions may flag an IP change even hours later, so the floor may be the entire session. See scraping websites behind a login.
• JavaScript-heavy pages. A single rendered page can make dozens of background requests. They need one IP for the page to hydrate correctly, which is covered in session-aware proxy rotation for JavaScript sites.

Add a margin of at least 50% to the measured flow time, because slow responses stretch flows unpredictably. A 60-second flow needs an interval of at least 90 seconds, and more if the timer runs on a fixed clock rather than from first use.

If the flow is longer than the ceiling allows, shorten the flow before reaching for a different proxy: skip pages you do not need, request a larger page size, or split one long crawl into several shorter sessions that each fit.

Use these as starting points to test, not as rules. Every target differs, and the figures assume one session per IP.

The API row is worth a pause. If a target counts requests per API key or per account, changing IPs does not raise your budget and can look suspicious. Rotation solves per-IP limits only.

A short interval does not help if the next IP you get is one the target saw a minute ago. What matters over longer windows is how often each IP comes back.

For per-request rotation over a pool you effectively draw from, the average requests each IP receives inside a target window is roughly:

requests per IP per window = total requests per minute x window in minutes / effective pool size

Rearranged, the pool you need for a given per-IP budget is:

effective pool size needed = total requests per minute x window in minutes / tolerated requests per IP

Illustrative example: 3,000 requests per minute in total, a 10-minute window and a tolerance of 60 requests per IP means you need exits from at least 500 IPs in that window. With only 200 distinct exits for your target country, each IP averages 150 requests per window no matter how often rotation happens, and the interval setting cannot fix it.

"Effective pool" is the key word. A provider may have a very large network while the slice available for one country, or the IPs a target has not already flagged, is much smaller. Estimate it by sampling: send a few hundred requests through the rotating port and count distinct exits. Related capacity maths for thread counts is in understanding concurrent connections in proxies.

Before you tune anything, measure how rotation behaves on your plan. This script checks the exit IP every 15 seconds from several parallel workers, so you can see when IPs change and whether workers share one.

# verify_rotation.py: observe timed rotation behaviour on a sticky or timed port.
import threading, time, datetime as dt
import requests

PROXY = "http://USER:PASS@gateway.sparkproxy.io:11002"   # sticky sessions port
WORKERS, CHECK_EVERY, DURATION = 4, 15, 12 * 60           # seconds

def worker(n):
    s = requests.Session()                                 # keeps its own connection
    s.proxies = {"http": PROXY, "https": PROXY}
    last, since = None, time.time()
    end = time.time() + DURATION
    while time.time() < end:
        try:
            ip = s.get("https://api.ipify.org", timeout=20).text.strip()
        except requests.RequestException as exc:
            ip = f"error:{type(exc).__name__}"
        now = time.time()
        if ip != last:
            held = f"held {now - since:5.0f}s" if last else "first"
            print(f"{dt.datetime.now():%H:%M:%S} worker {n}: {ip} ({held})")
            last, since = ip, now
        time.sleep(CHECK_EVERY)

threads = [threading.Thread(target=worker, args=(i,)) for i in range(WORKERS)]
for t in threads: t.start()
for t in threads: t.join()

Read the output for three answers:

1. Actual lifetime. The "held" figures show how long each IP lasted. Expect them to cluster around the advertised interval, give or take the 15-second sampling step.
2. Shared or separate. If all four workers print the same IP at the same moments, the timer is shared and your per-IP rate is multiplied by your worker count.
3. Clock or first use. If changes happen at the same wall-clock times regardless of when workers started, rotation runs on a clock. Plan your floor margin accordingly.

Run it again with a fresh session and with a different worker count. Behaviour can differ between a reused connection and a new one, which matters if your HTTP client opens new connections per request. For checks that confirm authentication and exit country too, see how to test if your proxy is working.

The most reliable interval comes from your own traffic. Log every request with a timestamp, the exit IP and the status, then look at error rate against IP age: how long that IP had been in use when the request went out.

# ip_age_errors.py: error rate by how long an exit IP had been in use.
import csv
from collections import defaultdict

BUCKET = 30   # seconds
first_seen, stats = {}, defaultdict(lambda: [0, 0])   # bucket -> [requests, failures]

with open("requests_log.csv") as fh:   # columns: epoch_seconds, exit_ip, status, body_bytes
    for ts, ip, status, size in csv.reader(fh):
        ts, status, size = float(ts), int(status), int(size)
        age = ts - first_seen.setdefault(ip, ts)
        failed = status in (403, 429, 503) or (status == 200 and size < 2000)  # soft blocks
        b = int(age // BUCKET) * BUCKET
        stats[b][0] += 1
        stats[b][1] += failed

print("ip_age_s  requests  error_rate")
for b in sorted(stats):
    n, f = stats[b]
    print(f"{b:>8}  {n:>8}  {f / n:>9.1%}")

Adjust the soft-block rule to your target: a 200 response with a tiny body or a captcha marker is a failure even though the status says otherwise. If the IP can return to your run later, reset first_seen for it after a gap longer than the target's window, or its age will be overstated.

A healthy result is a flat error rate across all ages. A worn-out pattern looks like this: low and steady for the first few buckets, then a clear upturn at some age, the knee. Set your interval just before the knee, and re-check monthly, because targets tune their limits. How to detect when your scraper is blocked lists the signals worth logging beyond status codes.

If the error rate is high from the very first bucket, the interval is not your problem. The IPs are being judged on arrival, by reputation, ASN or fingerprint, and a different rotation setting will not change that.

Cookie handling is the usual hidden partner in these problems. If your client keeps a cookie jar across rotations, the site sees one session hopping between IPs. Handling cookies and sessions in web scraping shows how to scope the jar to the IP lifetime.

SparkProxy datacenter plans offer two rotation modes: random rotation per request, and automatic rotation every 5 minutes, with USA and worldwide rotating options. The gateway is gateway.sparkproxy.io, with port 11000 for rotating HTTP/HTTPS, 11002 for sticky sessions and 13000 for SOCKS5. Run the verification script against the port you plan to use so you know exactly how the interval behaves with your client and worker count.

In practice that gives two starting points. Per-request rotation fits independent page fetches at volume. The 5-minute mode fits flows that finish well within 5 minutes and sessions that stay under the target's per-IP budget for that long. If your measured ceiling is shorter than 5 minutes, move the work that does not need a stable IP to per-request rotation, and lower the request rate per session for the flows that do, until 5 minutes of traffic fits inside one IP's budget.

Plans are priced by concurrent threads with unlimited bandwidth, so interval choice does not change your bill: Starter $75 for 100 threads, Core $140 for 250, Boost $240 for 500 and Plus $440 for 1,000, across 1M+ datacenter IPs in 80+ countries. If your workflow needs one IP held for hours or days, such as long-lived logged-in accounts, a static dedicated IP is a better fit than any rotation interval; see rotating vs static datacenter proxies and what is a sticky session proxy.