Mixed-Subnet Datacenter Proxies: Why IP Spread Matters

There is no standard definition. In practice, providers use "mixed" for any of these, and a single plan may mean only the first:

"C-class" deserves a note. The old class-based addressing system was retired in 1993, but proxy sellers still say "different C-class" to mean different /24 networks. It is a useful shorthand as long as you remember it only speaks to the smallest layer.

Ask which of these the vendor means in writing. A clear answer such as "no two IPs in your order share a /24, and no more than a set share come from one ASN" is something you can test. "Highly diverse" is not.

Anti-bot systems and firewall rules do not all block at the same granularity. Spread only protects you at the layers where it exists.

The third row is the one buyers overlook. A block of addresses you think of as "many /24s" may be announced to the internet as a single /20 or /19 by one operator. A reputation system that works from routing data sees one object, not sixteen. The mechanics of how prefixes are announced, and how to look them up, are covered in our guide to BGP and RIR IP allocations.

The fourth row sets the ceiling. If a target blocks hosting ASNs as a category, no amount of datacenter spread helps. Every datacenter IP, however mixed, belongs to a hosting network, as explained in what is a datacenter ASN. Mixed subnets protect you against targeted range blocks, not against a policy that rejects datacenter traffic outright.

Vendors that do share spread figures usually give a count: "IPs from 150 subnets". A count hides concentration. A better number is the effective subnet count, borrowed from how economists measure market concentration:

effective subnets = 1 / (sum of each subnet's share squared)

If every subnet holds the same number of your IPs, the effective count equals the raw count. The more lopsided the distribution, the further the effective count falls.

The third row is the trap. It honestly contains 53 subnets and would pass a vendor's "50+ subnets" claim, yet it behaves like a list of about five, because three blocks hold three quarters of it. Ask for the distribution, or compute it yourself from the list, rather than accepting a count.

Run the same calculation at the prefix and ASN layers. A list can have an effective /24 count of 200, an effective prefix count of 6 and an effective ASN count of 1.3. That list is well protected against simple firewall rules and barely protected against anything smarter.

Bans are the obvious reason to care about spread. Rate limits are the less obvious one, and for high-volume collection they often matter more.

Many rate limiters count requests per IP. Some count per /24 or per prefix instead, precisely because they have seen scrapers rotate through neighbouring addresses. Against that kind of limiter, rotating across 500 IPs does nothing if those IPs share a handful of ranges: the counter sees a few very busy blocks, not 500 quiet addresses.

That turns the effective subnet count into a capacity figure. Illustrative assumption: a target tolerates about 300 requests per minute from any one /24 before it starts returning 429s.

Two lists of the same size, bought at the same per-IP price, differ by a factor of fifty in how fast they can work against that target. Adding threads to the first list does not help; it only makes the busy blocks hit their limit sooner, and the 429s that follow can escalate into a full range block.

This has a practical consequence for how you schedule work. If your audit shows concentration, spread requests across blocks deliberately: track requests per /24 in your scheduler and pause a block that nears its limit, rather than letting random rotation pile traffic into the largest one. The general per-IP version of this arithmetic is in our guide to managing per-IP request limits. The same idea applies one layer up.

Sessions add a second wrinkle. On a well-spread pool, a sticky session that expires and re-rotates will usually land in a different block, often in a different city. For stateless page fetches that is harmless. For a multi-step flow that stores a location in a cookie, it can change currency or shipping results between step two and step three, so pin the session for the whole flow or set the country explicitly.

Wide spread is not always the right product. Contiguous or same-subnet IPs win in several situations.

• You allowlist the IPs on your own systems. A partner API, a staging firewall or a corporate VPN that must trust your proxy exits is far easier to configure with one or two ranges than with 300 scattered /32 entries. Our explainer on IP whitelisting for proxies covers the operational side.
• You need consistent geolocation. IPs from one block in one datacenter tend to geolocate identically. Mixed lists often span cities, which can change local search results, currency or content between requests.
• Your target does not block by range. If failures are per IP and per rate, spread across subnets adds nothing you will notice.
• Your volume per IP is low. A small monitoring job that sends a few requests an hour per IP rarely triggers range-level rules.
• You run a small, stable set of dedicated IPs for accounts. Here the relationship between each IP and each account matters more than blast radius. The dedicated versus shared decision is covered in shared vs dedicated datacenter proxies.

Mixed spread matters most for the opposite profile: large lists or rotating pools, high request volume per target, and targets known to block ranges after abuse.

If you bought a static list, you can measure its spread before you rely on it. The script below groups IPs by /24, then looks up each IP's announced prefix and origin ASN using Team Cymru's public IP-to-ASN bulk whois service, and prints raw and effective counts for each layer.

# audit_spread.py: measure IP spread of a static proxy list (IPv4, one IP per line).
import ipaddress, socket
from collections import Counter

def effective(counter):
    total = sum(counter.values())
    return 1 / sum((n / total) ** 2 for n in counter.values())

def cymru_bulk(ips):
    """Bulk lookup via whois.cymru.com:43. Returns {ip: (asn, prefix, as_name)}."""
    query = "begin\nverbose\n" + "\n".join(ips) + "\nend\n"
    with socket.create_connection(("whois.cymru.com", 43), timeout=60) as s:
        s.sendall(query.encode())
        raw = b""
        while chunk := s.recv(65536):
            raw += chunk
    out = {}
    for line in raw.decode(errors="replace").splitlines():
        parts = [p.strip() for p in line.split("|")]
        if len(parts) >= 7 and parts[0].isdigit():
            asn, ip, prefix, as_name = parts[0], parts[1], parts[2], parts[6]
            out[ip] = (asn, prefix, as_name)
    return out

ips = [l.strip().split(":")[0] for l in open("proxies.txt") if l.strip()]
slash24 = Counter(str(ipaddress.ip_network(f"{ip}/24", strict=False)) for ip in ips)
meta = cymru_bulk(ips)
prefixes = Counter(meta[ip][1] for ip in ips if ip in meta)
asns = Counter(f"AS{meta[ip][0]} {meta[ip][2]}" for ip in ips if ip in meta)

for name, c in [("/24", slash24), ("announced prefix", prefixes), ("ASN", asns)]:
    top, n = c.most_common(1)[0]
    print(f"{name:17} raw={len(c):5}  effective={effective(c):7.1f}  largest={n/len(ips):.1%} ({top})")

Strip the port or credentials from each line first; the script keeps only what comes before the first colon. Team Cymru's service is free for reasonable bulk use; batch large lists rather than hammering it.

Read the output from the bottom up. If the ASN line shows one network holding most of the list, that is your real exposure, whatever the /24 line says. If the announced prefix line collapses to a handful, a routing-aware block will hit most of your IPs together. The IP reputation side of the audit, whether those ranges are already on blocklists, is covered in what is IP reputation.

With a rotating gateway you never receive a list. You can still estimate spread by sampling exit IPs and feeding them into the same analysis.

# sample_exits.py: collect exit IPs from a rotating gateway, then run audit_spread.py on them.
import concurrent.futures as cf
import requests

PROXY = "http://USER:PASS@gateway.sparkproxy.io:11000"   # random exit per request

def exit_ip(_):
    try:
        r = requests.get("https://api.ipify.org",
                         proxies={"http": PROXY, "https": PROXY}, timeout=20)
        return r.text.strip()
    except requests.RequestException:
        return None

with cf.ThreadPoolExecutor(max_workers=20) as pool:
    seen = [ip for ip in pool.map(exit_ip, range(1000)) if ip]

unique = sorted(set(seen))
print(f"{len(seen)} samples, {len(unique)} unique exits")
open("proxies.txt", "w").write("\n".join(unique))

Three caveats keep the sample honest. It is a lower bound: 1,000 requests cannot show you a pool of hundreds of thousands, so treat the numbers as "at least this spread". Sample from the country you will actually use, since spread can differ sharply by location. And repeat the sample on another day, because gateways may draw from different parts of the pool over time.

The shape of the results still tells you plenty. If 1,000 samples produce 990 unique IPs across hundreds of /24s and dozens of prefixes, the pool is broad in the region you tested. If they produce 300 unique IPs in 12 /24s, you have learned something no sales page would say.

For static lists bought for range-sensitive work, agree acceptance criteria before payment or during the refund window. The figures below are our suggested starting points, not an industry standard. Tune them to your targets.

Share the audit output with the vendor if a list fails. A reputable provider can usually replace concentrated IPs. Also check how replacements are handled later: IPs added months after purchase are a common source of creeping concentration.

Spread costs something, and the costs are easy to miss until they show up in production.

• Price per IP. Vendors that sell by the IP often charge more for guaranteed unique /24s, because every order consumes more of their address space.
• Geolocation drift. Wider spread usually means more datacenters and more cities. If your task is location-sensitive, set the country explicitly and confirm city-level results where they matter.
• Latency variance. IPs in different facilities route differently. Average latency may be fine while the slowest tenth of requests gets noticeably slower.
• Harder allowlisting. Discussed above, and a real operational cost for teams that have to register exits with partners.
• Mixed reputation. Spreading across many ranges spreads you across many histories. Some blocks will be cleaner than others, which is why the audit includes a blocklist check. Our guide to clean datacenter subnets covers that side.

The right amount of spread is the least you need to survive the blocks your targets actually use. More is not free.

SparkProxy sells access to a rotating datacenter pool rather than fixed IP lists. The network is 1M+ datacenter IPs across 80+ countries, including 50,000+ US addresses, reached through gateway.sparkproxy.io: port 11000 for rotating HTTP/HTTPS, 11002 for sticky sessions and 13000 for SOCKS5. Rotation on proxy plans is random per request or automatic every 5 minutes, with USA and worldwide rotating options.

That model changes the audit. You are not checking a list you own; you are checking the breadth of the exits you draw from, which is what the sampling script above does. Run it on your target country before you commit traffic, and rerun it if your success rate shifts.

Plans are priced by concurrent threads with unlimited bandwidth and 30-day validity: Starter $75 for 100 threads, Core $140 for 250, Boost $240 for 500 and Plus $440 for 1,000. If you need a fixed, same-subnet set of IPs to allowlist on a partner system, a rotating pool is the wrong shape and a dedicated static list from another provider will serve you better. For the broader choice, see rotating vs static datacenter proxies.