What Are Rotating ISP Proxies and Who Should Buy Them

Most people searching for rotating ISP proxies want one of three other products. Start here, and only keep reading if the second row is you.

The honest version: rotating ISP proxies occupy a narrow band. They win when your target's defence stops at the ASN lookup, when your traffic is heavy enough that per-GB billing hurts, and when you need more IP diversity than a handful of static addresses can supply. Outside that band, one of the other three rows is cheaper or more reliable, and a vendor who tells you otherwise is selling, not advising.

An ISP proxy is an IP hosted on datacenter hardware but registered to a consumer internet provider, so a site resolving the address to its Autonomous System Number sees Comcast or Deutsche Telekom instead of a hosting company. The full mechanism is covered in what are ISP proxies, and what is a datacenter ASN explains the exact check it beats.

ISP proxies are static by default. You are assigned specific addresses and you keep them. A rotating ISP product changes only the delivery layer: the provider puts its whole ISP allocation behind a single gateway host and port, then assigns a different IP from that allocation per request, or per sticky window if you pass a session identifier. Your code points at one endpoint forever and never manages an IP list.

Three consequences follow from that design, and vendors rarely spell them out.

The IPs are the same static IPs, shared. A rotating ISP gateway is not generating fresh addresses. It is a scheduler over a fixed allocation, and other customers on the same gateway draw from that allocation at the same time you do. If the vendor also sells those addresses as dedicated static IPs, the rotating tier is usually the shared or leftover slice of the same inventory.

Rotation is per request by default, not per session. Anything with a login, a cart, or a multi-step flow needs a sticky window, which is functionally a sticky session proxy. Buy the rotating tier and then pin every single session, and you have paid for rotation you are not using.

"Rotating" says nothing about pool diversity. A gateway rotating across 5,000 addresses and one rotating across 500,000 get marketed with the identical word. The number that decides your success rate is not on the pricing page, which is why the next two sections exist.

Two comparisons on this site go deeper on the neighbouring decisions: rotating vs static residential proxies for the persistence question, and ISP proxies vs datacenter proxies for the registration question.

This is the part that separates a good purchase from a bad one, and no vendor pricing page will do it for you. Two numbers govern whether a rotating ISP pool survives your workload.

Number one: your revisit rate. Divide daily request volume by the usable pool, and remember the usable pool is not the headline number. It is the slice matching your country filter, minus whatever other customers are drawing concurrently. A pool advertised at 100,000 addresses, filtered to US only, might leave 40,000 usable. Sixty thousand requests an hour against that slice is about 1.5 hits per IP per hour, which reads like a person browsing. Six hundred thousand requests an hour on the same slice is 15 hits per IP per hour, which reads like a script. Same product, same price, opposite outcome. Work this number out before you pay. It predicts success better than any feature list.

Number two: the count of distinct /24 subnets. ISP allocations are leased in contiguous blocks, so a rotating ISP pool of 100,000 addresses might live inside a few hundred adjacent /24s, sometimes far fewer. Residential pools are structurally the opposite: their addresses are scattered across thousands of separate ASNs and non-adjacent ranges, because each one comes from an individual household rather than one leasing agreement.

That difference matters because serious anti-bot systems do not only rate-limit per IP. They bucket by subnet and by ASN, on the reasonable theory that 256 addresses in one contiguous block under one organisation are one actor. Against a target doing that, rotating across 256 IPs inside a single /24 is close to not rotating at all. Rotating across 256 residential IPs drawn from 200 different networks genuinely is 200 actors.

So the question to put to a vendor is not "how many IPs?" It is "how many distinct /24s, and how many distinct ASNs, in the country I need?" A pool of 20,000 addresses across 300 subnets is a better buy for evasion than 60,000 addresses across 90 subnets, and the cheaper listing is often the better one. Almost nobody asks this, which is precisely why asking it works.

You can check the claim yourself on a trial key. Pull a few hundred exit IPs, then count unique addresses, unique /24s, and how concentrated the top blocks are.

import collections, ipaddress, requests

PROXY = {"https": "http://USER:PASS@gateway.sparkproxy.io:11000"}

seen = []
for _ in range(500):
    r = requests.get("https://api.ipify.org?format=json", proxies=PROXY, timeout=30)
    seen.append(r.json()["ip"])

blocks = [str(ipaddress.ip_network(ip + "/24", strict=False)) for ip in seen]
print("unique IPs :", len(set(seen)))
print("unique /24s:", len(set(blocks)))
print("top blocks :", collections.Counter(blocks).most_common(5))

Read the output honestly. If 500 draws return 40 unique addresses, the gateway is rotating over a much smaller working set than the marketing claims. If they return 480 unique addresses inside 9 subnets, you bought nine identities, not 480. Either result is worth knowing before the annual invoice, not after.

High-volume scrapers of mid-difficulty targets. Retail catalogues, travel inventory, job boards, and marketplace listings that reject hosting ASNs but do not run the heaviest behavioural fingerprinting. Rotating ISP gives you the clean registration on a billing model that does not punish you for heavy HTML pages.

Anyone whose residential bill is dominated by page weight. Per-GB billing charges the same for a 3 MB product page as for 3 MB of anything else. If your monthly transfer is large and your target list is short, moving that job onto unmetered ISP or datacenter IPs usually cuts the bill sharply. Run the arithmetic on last month's actual transfer before you switch, not after.

Teams that need low, predictable latency across many workers. Residential exits ride real home connections, so response times scatter, sometimes badly. ISP exits sit on wired datacenter uplinks. If your pipeline runs tight timeouts and a small retry budget, stable latency converts directly into fewer retries and lower cost.

Buyers who need moderate IP diversity without managing a list. When 20 static addresses is too few but a full residential network is overkill, a rotating ISP gateway is the middle rung: one endpoint, no inventory to maintain, no rotation logic in your code. The general pattern is covered in what is a rotating proxy API.

Anyone managing accounts. Logins, marketplaces, ad platforms, and social accounts expect one consistent IP per identity. Here rotation is the failure mode, not the feature. Buy static ISP addresses and assign one per account.

Anyone hitting the hardest targets. Against systems that combine TLS fingerprinting, behavioural signals, and subnet reputation, ISP registration by itself is not enough. Rotating residential is the honest answer for those, and it costs more for a reason.

Anyone who needs broad geography. ISP inventory exists where a provider negotiated a lease, which in practice means the US plus a handful of Western European markets. If your project needs Brazil, Indonesia, Nigeria, and Vietnam at city level, no ISP pool covers it.

Anyone on a light workload. If you move a few gigabytes a month, per-GB residential billing is cheaper than any per-IP subscription and hands you a vastly better pool. Rotating ISP only pays off once your volume makes the flat fee cheaper per request.

Rotating ISP proxies are sold in one of three shapes, and the shape matters more than the sticker price.

As of September 2026, published list prices for ISP and static residential addresses across the major vendors sit roughly between one and four US dollars per IP per month on longer commitments, while per-GB residential traffic is listed anywhere from about a dollar to well over ten dollars per gigabyte depending on tier and commitment. Those are the vendors' own published rates on their own pricing pages, they change without notice, and negotiated volume quotes routinely land far below list. Check the provider's current pricing page rather than trusting any figure in a blog post, this one included.

Three traps to avoid when you line quotes up side by side:

Compare cost per successful request, not cost per IP or per GB. A pool at 70 percent success for half the price is more expensive than a pool at 95 percent, because every failure still burns bandwidth, a retry, and wall-clock time. Divide monthly cost by successful responses and rank on that single number.

Read the speed ceiling, not just the bandwidth allowance. Unlimited bandwidth behind a low per-connection speed cap is a throughput budget wearing a friendlier label. Ask for the figure in Mbps and whether it applies per connection or per account.

Check whether the rotating tier is shared. If the same allocation also backs a dedicated static product, you share IP reputation with every other customer on the rotating gateway. That is not automatically bad, but it should be priced below dedicated, and it changes how you read a sudden drop in success rate. The billing structures behind these tiers are unpacked in understanding datacenter proxy pricing models.

Send all six in one message. The quality of the replies tells you more than any review site.

1. How many distinct /24 subnets and distinct ASNs does the pool contain in the country I need?
2. Is the rotating pool shared with other customers, or is my allocation exclusive?
3. Does rotation happen per request, per timed window, or both, and which sticky durations are supported?
4. Is bandwidth metered, and what is the speed ceiling in Mbps, per connection or per account?
5. What is the replacement policy when an address gets flagged, how fast, and is there a monthly cap?
6. What is the refund or trial window, and is it usage-capped?

A vendor who answers one and five with specific numbers is running a real network. A vendor who deflects to "millions of IPs" is reselling someone else's gateway, and you are two or three layers away from the addresses you think you are buying.

Never sign an annual plan off a five-minute trial. Run this against your real targets and your real code path, then decide.

1. Baseline your current setup. Log success rate, median latency, and bytes per successful response for one full day on whatever you use now. Without this, nothing you measure next means anything.
2. Run the subnet audit. Use the script above on the trial credentials, at the exact country filter you intend to buy. Record unique addresses, unique /24s, and unique ASNs.
3. Replay the same job. Same URLs, same concurrency, same headers, same retry policy. Change the proxy endpoint and nothing else.
4. Watch a full day cycle. Pool contention and target defences both move with the clock. A pool that looks flawless at 03:00 UTC can degrade at regional peak.
5. Compute cost per successful request for both setups, and compare those two numbers rather than the two plan prices.
6. Test the failure path. Push a few addresses hard enough to get blocked, then confirm the replacement and rotation behaviour matches what the vendor promised in question five.

Two days of this saves a year of paying for the wrong tier.

SparkProxy sells rotating datacenter proxies with unlimited bandwidth on a thread-based model, and reaches residential exits through the Scraping API's premium pool. The network runs over 1 million datacenter IPs across more than 80 countries, including over 50,000 US datacenter IPs.

Published proxy plans are priced by concurrent threads rather than traffic. All include unlimited bandwidth and 30 days validity.

Higher Pro and Pro+ tiers exist in the Fair Usage Policy at 1500 and 2000 threads, with 200 and 250 Mbps ceilings, and custom plans go up to 1 Gbps. Those tiers are quoted rather than publicly listed. Treat every speed figure as a fair-usage ceiling, not a guaranteed sustained rate.

The gateway is gateway.sparkproxy.io. Port 11000 carries HTTP and HTTPS with rotation, port 11002 gives sticky sessions, and port 13000 is SOCKS5.

import requests

rotating = {
    "http":  "http://USER:PASS@gateway.sparkproxy.io:11000",
    "https": "http://USER:PASS@gateway.sparkproxy.io:11000",
}
sticky = {
    "http":  "http://USER:PASS@gateway.sparkproxy.io:11002",
    "https": "http://USER:PASS@gateway.sparkproxy.io:11002",
}

r = requests.get("https://api.ipify.org?format=json", proxies=rotating, timeout=30)
print("rotating exit:", r.json()["ip"])

If you would rather not run proxy logic at all, the Scraping API takes a URL and returns the page, handling the proxy layer, browser rendering, and retries. Pass premium_proxy=true for residential premium exits, and a session_id to label the job in your logs.

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://example.com/product/1234" \
  --data-urlencode "premium_proxy=true" \
  --data-urlencode "country_code=US" \
  --data-urlencode "render_js=true"

The Scraping API starts with 1,000 free credits and no card. Paid tiers are Starter at $49 for 250,000 credits a month with 50 concurrent requests, Growth at $99 for 1,000,000 credits with 100 concurrent, Pro at $249 for 3,000,000 credits with 200 concurrent, and Scale at $599 for 8,000,000 credits with 400 concurrent. A plain fetch costs 1 credit, a JavaScript render costs 5, and a screenshot or PDF costs 10. The full parameter list is in the Scraping API docs.

Use those free credits to run the 48-hour test above against your own targets before committing to any plan, here or anywhere else.