How Many Proxy IPs Do You Need? Sizing Your Rotation

"How many proxy IPs do I need" is the wrong question asked in the right direction. The number of IPs in a provider's pool is not what determines whether your operation works — what matters is how many requests each IP carries against each target before you rotate away from it. Pool size only matters insofar as it lets you keep that number low. This guide shows how to size rotation from the variables that actually drive it.

The Variable That Actually Matters

Every target has an implicit tolerance: how many requests it will accept from a single IP within a time window before it rate-limits, challenges, or blocks. Call it the per-IP request budget.

Your job is to stay under it. The formula follows directly:

IPs needed = (requests per window) / (per-IP request budget)

If you need 100,000 requests per hour against a target whose tolerance is roughly 50 requests per IP per hour, you need about 2,000 distinct IPs in rotation for that target, per hour. If the tolerance is 500, you need 200.

Everything else in this guide is about estimating those two numbers for your situation.

Estimating Per-IP Budget by Target Tier

Target tolerance varies by orders of magnitude. Classify before you size.

Permissive targets — open data sources, public APIs, small commercial sites with no bot management. Tolerance is high: often hundreds to thousands of requests per IP per hour. Datacenter proxies work. You need relatively few IPs.

Moderate targets — mid-size ecommerce, regional platforms, sites with basic rate limiting and IP-type filtering. Tolerance in the range of tens to low hundreds per IP per hour. Residential proxies needed.

Strict targets — major search engines, large marketplaces, platforms with serious anti-bot investment. Tolerance can be very low — sometimes single-digit requests per IP before scrutiny increases. These targets drive most of your IP requirement.

Account-bound workflows — not a volume problem at all. Each account needs a stable, consistent IP. The requirement is one dedicated IP per account (or per small account group), not a rotation pool.

You cannot look these numbers up; they are target-specific and they change. Measure them.

Measuring Tolerance Empirically

Run a deliberate ramp against each significant target before sizing:

1. Take a single IP and send requests at a steady, modest rate.
2. Count successful responses until the first block signal — a 403, a 429, a captcha, or a content anomaly.
3. Repeat across 10–20 different IPs and take the median, not the best case.
4. Apply a safety margin. Size to roughly 50–60% of observed tolerance, not 95% — tolerance varies by IP reputation, time of day, and target-side configuration changes.

This measurement is the most valuable half hour you will spend on a new target. Sizing without it is guesswork, and the usual outcome is either an operation that blocks constantly or one that over-provisions bandwidth for no reason.

Worked Examples

Large-scale price scraping

200,000 product pages daily across five retailers. Four are moderate tier, one is strict. Collection concentrated into two six-hour windows.

For the moderate retailers: 160,000 requests over 12 hours of collection, measured tolerance around 80 requests per IP per hour. That is roughly 13,300 requests/hour, needing about 165 IPs concurrently in rotation — call it 250 with margin.

For the strict retailer: 40,000 requests, measured tolerance around 8 requests per IP per hour. That is 3,300 requests/hour needing roughly 420 IPs concurrently, call it 600 with margin. The strict target needs more than twice the IPs for a quarter of the volume.

Total working rotation: around 850 distinct IPs in flight, drawn from a much larger pool so IPs get rest between uses.

Local SERP tracking

500 queries across 20 cities, three times daily, three repetitions. 90,000 SERP loads daily. Search engines are strict — assume 5–10 requests per IP per hour conservatively.

At 10 per IP/hour and collection spread over 9 hours, that is 10,000 requests/hour needing about 1,000 concurrent IPs — but with the hard constraint that each must geolocate to one of 20 specific cities. So you need roughly 50 usable IPs per city at any moment, and the city subset depth becomes the binding constraint rather than total pool size.

This is the case where "millions of IPs" in a provider's marketing tells you nothing. What matters is depth in Munich.

Ad verification

5,000 placements, 8 markets, 4 checks daily, 10 requests per verification. 1.6 million requests daily, concentrated into four windows. Publisher pages are typically moderate tier, around 100 requests per IP per hour.

400,000 requests per window over roughly 2 hours is 200,000/hour, needing about 2,000 concurrent IPs — distributed across 8 markets, so 250 per market minimum.

Account management

40 managed accounts across 6 markets. Not a rotation problem. The requirement is 40 stable IPs — dedicated ISP proxies, one per account, geographically matched to each account's registration market. Rotating these would trigger security reviews.

What Drives the Number Up

Narrow geographic targeting. City-level requirements multiply your need, because the usable pool for each session is the city subset, not the country pool. Twenty cities means twenty separate depth requirements.

Strict targets. Low per-IP tolerance is the single biggest multiplier. One strict target can require more IPs than a dozen permissive ones.

Short collection windows. Compressing the same volume into less time raises concurrent IP demand proportionally. A job that needs 200 IPs over 12 hours needs 1,200 over 2.

Sticky session requirements. An IP held for a 30-minute session is unavailable for other work during it, so sticky workflows consume IP-time faster than per-request rotation.

High concurrency. Each concurrent thread needs its own IP at any instant. 500 threads means at least 500 IPs in flight.

What Drives the Number Down

IP rest periods. An IP that sits idle for several hours partially recovers its budget against a target. Drawing from a large pool with long rest intervals means each IP carries far less history.

Right-sizing proxy type. Routing permissive targets to datacenter proxies removes them from your residential IP demand entirely.

Reducing requests per unit of work. Not every verification needs 15 requests. Trimming unnecessary asset loads and avoiding full browser rendering where plain HTTP suffices cuts your total request count, and therefore your IP requirement, directly.

Spreading collection windows. Longer windows at lower concurrency need fewer concurrent IPs for the same daily volume — when the data's freshness requirements permit it.

Why Pool Size Marketing Is Misleading

"80 million IPs" tells you about ceiling, not about what you can use right now. The questions that matter:

Active versus registered. A pool of 100 million registered addresses with 20 million active behaves like a 20-million pool.

Depth in your specific geographies. Total pool size is irrelevant if you need Munich and the provider's German coverage is concentrated in Berlin and Frankfurt.

ASN diversity. IPs clustered in a few autonomous systems behave like fewer IPs against targets doing ASN-level analysis.

Concurrency allowance. This is the one people miss. A vast pool behind a 100-thread cap gives you 100 IPs in flight, no matter how many exist. The concurrency cap, not the pool size, sets your real rotation width — and therefore your achievable request rate.

That last point reverses the usual framing. If a provider limits concurrent sessions, their pool size is almost irrelevant to your sizing math, because you can never have more IPs in flight than your thread allowance.

Practical Sizing Procedure

1. List targets and classify each by tier.
2. Measure per-IP tolerance empirically for each significant target.
3. Calculate requests per collection window per target.
4. Divide by tolerance to get concurrent IP need per target.
5. For geo-targeted work, divide further by market to get per-market depth requirements.
6. Sum concurrent needs across targets running simultaneously.
7. Apply a 1.5–2× margin for tolerance variance and IP rest.
8. Confirm your provider's concurrency allowance exceeds the result — otherwise it is your binding constraint, not the pool.

FlameProxies provides 80M+ residential IPs across 180+ countries with city-level targeting and, critically, no cap on concurrent sessions and no request-rate limits — so your rotation width is set by your sizing math rather than by a thread allowance. Measuring per-IP tolerance against your own targets during the trial is the step that turns pool-size marketing into a number you can actually plan around.