Proxy Pool Size Explained: Why 100 Million IPs Means Little

Every residential proxy homepage carries a number with a lot of zeroes after it. Ten million, fifty million, a hundred and fifty million IPs. The figures are usually not fabricated. They are just answering a question nobody running a crawler has ever needed answered.

What a crawler needs to know is how many distinct exit addresses will actually answer, in the one country it targets, during the window it runs in. That number is smaller by orders of magnitude, it changes hour by hour, and no provider publishes it. You can measure it yourself in about an hour.

What a headline pool number counts

A pool figure is a cumulative census: every unique IP address the provider has routed traffic through, over some unstated window, across every country and every pool type it sells. Three properties of that definition do most of the inflation.

• Dynamic addressing. Consumer ISPs hand out addresses on leases. A household whose router reconnects nightly contributes a fresh unique IP each time while remaining exactly one device on one connection. Over a month of counting, one household can be dozens of entries.
• Carrier-grade NAT works the other way. Hundreds of subscribers can sit behind a single public address, so on some networks the count understates the number of real households and overstates the number of independent identities you get.
• Wholesale and resale. Large pools are frequently resold. Two providers with different branding can be announcing the same upstream supply, which is why their claimed totals sometimes look suspiciously similar and why buying two vendors is not always the diversification it appears to be.

None of that is measurable from outside. The figure is self-reported, the window is unstated, and the methodology is never published. Treat it as a marketing input.

The slice you can actually reach

Between the advertised total and the exits your requests land on sit several filters, each of which removes most of what the previous one left.

Geography is the largest. A global pool distributed roughly by population puts a minority of its addresses in any one country, and a city or ASN filter cuts what remains to a sliver. Then there is the clock. Residential exits are consumer devices, and they are online when their owners are, so the reachable pool in a given country rises through the local evening and collapses overnight. Benchmark at the hour your job runs, because a pool measured at local noon says little about the pool at 4am.

Your own account contributes limits too: concurrent session caps, per-gateway connection limits, and the provider's internal decision about which subset of healthy exits to expose to you. Geotargeting granularity is the part you can control, and the trade-offs are covered in the proxy geotargeting guide.

Why the pool shifts underneath you

An exit exists only while the host device is powered on, connected, and running the provider's client. Phones go into a pocket. Laptops sleep. A residential IP you were using thirty seconds ago can vanish mid-response, which is why sticky sessions come with maximum lifetimes rather than guarantees and why your retry logic has to treat a dropped exit as normal rather than exceptional. Session behaviour is covered in rotating vs sticky proxy sessions.

Supply churns at the business level as well. Providers source most of their bandwidth from SDKs embedded in consumer apps, described in what are residential proxies, and when a large app publisher switches partner or gets removed from an app store, the pool composition changes within days. A measurement you took in March describes March.

Measuring the pool you have access to

Point per-request rotation at an echo endpoint that returns the client IP, and count. Host the endpoint yourself on a CDN edge. Public IP echo services throttle proxy traffic aggressively, which contaminates the sample with failures that have nothing to do with the pool.

PROXY="http://user-country-us:[email protected]:7000"

# 2,000 rotating requests, 20 at a time, one country
seq 2000 | xargs -P 20 -I{} \
  curl -s --max-time 20 -x "$PROXY" https://echo.example.com/ip \
  | sort | uniq -c | sort -rn > exits.txt

wc -l < exits.txt          # distinct exits observed
head -20 exits.txt         # the exits you were handed most often

Run the same command against every provider in a trial, at the same hour, with the same country filter and the same concurrency. Anything else and you are comparing time zones. The wider harness discipline is in how to benchmark proxy providers.

Reading the discovery curve

Plot cumulative distinct exits against request count. Early on the curve rises at close to one new IP per request. It bends when you start meeting addresses you have already seen, and where it flattens is the practical size of the pool exposed to your account under those filters.

A curve that is still climbing near-linearly at 10,000 requests means the accessible pool is much larger than your sample and you should stop worrying about size. A curve that flattens at 900 distinct exits after 5,000 requests means you have roughly 900 identities to work with, whatever the homepage says. Both outcomes are useful. Only one of them is visible on a pricing page.

Estimating the pool with mark and recapture

When the curve refuses to flatten, borrow the estimator field biologists use for fish populations. Take two independent samples and count the overlap: with 5,000 exits in the first run, 5,000 in the second, and 250 addresses appearing in both, the estimate is 5,000 x 5,000 / 250, or about 100,000 reachable exits.

The assumptions behind that formula do not hold cleanly here. Gateways prefer healthy, fast, recently-seen exits rather than sampling uniformly, and the population is open because devices join and leave between your two runs. Read the output as an order of magnitude. Even at that resolution it is more information than the marketing figure carries.

Reuse rate and the throughput ceiling

Distinct exits only matter because targets rate-limit per IP. Convert your measurement into the number you can plan with: how many requests per hour you can send before any single exit draws attention.

If your measured pool is 900 exits and you need 100,000 requests an hour against one hostname, you are asking each address for 111 requests in that hour. Against a tolerant target that is fine. Against a bank or a sneaker site it is a ban list. The lever is usually the tolerance rather than the pool: slowing down, spreading across more hostnames, or caching aggressively moves the ceiling further than buying a bigger network does.

Clean beats large

An exit address arrives at your target carrying a history you did not create. If it has been used for credential stuffing, spam or card testing by anyone else on the same network, it already sits in commercial reputation databases, and your perfectly ordinary request inherits the verdict. Large pools sourced from widely distributed SDKs are shared by every customer of that provider and often by its resellers, so the busiest addresses accumulate the worst records.

This is why a smaller opt-in pool frequently outperforms a network ten times its size on the same target, and why we score fraud score and clean rate separately from unique IP count. The mechanics of those scores are in proxy fraud score explained, and the current ranking sits in the highest clean rate comparison.

How much pool you actually need

Work backwards from the table above rather than forwards from a homepage. Establish your peak hourly request rate against a single hostname, estimate that target's per-IP tolerance by deliberately pushing one exit until it breaks, divide, and add margin for the exits that will be unavailable at your run time. Most teams land somewhere in the low thousands of reachable addresses in one country, which every serious provider can supply.

Above that, size stops being the constraint and geography, reputation and session stability take over. We track unique exits continuously for every provider, from US and EU hosts, over rolling 1, 7 and 30-day windows, and score them relative to each other rather than against an invented threshold. The counting rules are written up in our methodology, current figures sit on the live benchmark table, the history is in the performance graphs, and you can put two networks side by side with the comparison tool. Individual networks such as SOAX have their own page with the same breakdown.