How Many Proxies Do I Need? The Actual Math

By Nicholas St. Germain — July 23, 2026

"How many proxies do I need" is the most asked and worst answered question in this business. The standard reply is "it depends," which is true in the way every sizing question depends on inputs, and useless because nobody names the inputs.

This post names them: four formulas for the four workloads that generate the question, each with a worked example, stated assumptions, and a monthly cost at flat per-IP pricing. Our static ISP proxies start at $2.50 per IP per month with unlimited bandwidth, so the cost math here is just pool size times $2.50. There's no meter to estimate.

One scope note up front. Stat sells US-only static ISP proxies on Tier-1 US carrier IP space, with username:password auth over HTTP/HTTPS. We don't do rotating pools, SOCKS5, or non-US locations. Where that makes us the wrong tool, this post says so directly.

How many proxies for web scraping: throughput formula

The formula:

proxies_needed = target_requests_per_hour / safe_requests_per_hour_per_ip

You know target_requests_per_hour from your job. You don't know safe_requests_per_hour_per_ip, and anyone quoting you a universal number is guessing. It's a per-target tuning parameter you discover by starting slow on one IP and raising the rate until you see 429s or silently degraded responses, then backing off.

A few published anchors show how wide the range runs. GitHub documents 60 unauthenticated requests per hour, throttled per originating IP. OpenStreetMap's Nominatim policy sets an absolute maximum of one request per second. Wikimedia's etiquette page asks that you make requests in series rather than in parallel. Google publishes no number at all for search; its unusual-traffic page just says automated traffic gets your network flagged, so every "X per minute is safe for Google" figure you have read is folklore. Even the crawl-delay convention is inconsistent: Bing honors it as a 1 to 30 second window, while Google ignores the field entirely.

Worked example. Say you need 100,000 requests per day and run 20 hours a day. That's 5,000 requests per hour. Every rate in this table is an assumption, not a promise:

In practice, add headroom so a few banned IPs don't stall the job. We use 1.3x as a default; that multiplier is our habit, not a sourced constant.

import math

target_per_hour = 5_000        # requests/hour while the job runs
safe_per_ip_per_hour = 600     # measured against YOUR target, not a constant
headroom = 1.3                 # spare for bans and retries (our default)

pool = math.ceil((target_per_hour / safe_per_ip_per_hour) * headroom)
print(f"{pool} IPs, about ${pool * 2.50:.2f}/month at flat per-IP pricing")

That prints 11 IPs, $27.50 a month.

Static ISP proxies lose some scraping fights, and you should know which. Targets running aggressive anti-bot systems fingerprint TLS and JavaScript execution, and no proxy of any kind fixes that; you need a real browser stack and often a rotating residential pool on top. If the data lives on non-US sites that geo-gate content, our US-only IPs will never see it. For the large middle of web scraping work, a modest pool of static IPs at a polite rate is the cheap, boring answer.

Multi-account management: accounts times one

Simplest math in the post: one sticky IP per account, full stop. Proxies equals accounts times one. The antidetect browser vendors tell their own users the same thing. Multilogin's FAQ says to use a different proxy for each browser profile where you manage a separate account, and GoLogin's says to assign a different proxy to each profile because sharing one raises the risk that sites link the accounts.

Stickiness matters as much as count. An account that appears from a new IP every session looks compromised; the same carrier-space IP every day looks like a person at home. Twenty accounts is 20 IPs, $50 a month. A hundred is $250. Don't get clever and split 20 accounts across 10 IPs; you've built ten pairs of linked accounts and saved $25.

Checkout and drop automation: one IP per concurrent session

Session binding is the reason. When your task hits a store, the backend issues a session (cookies, sometimes an anti-bot token) and associates it with the IP that created it. If a later request in that session arrives from a different IP, the sane server-side interpretation is session theft, and you get challenged or dumped. Each concurrent task therefore holds one IP from add-to-cart through payment.

Proxies equals concurrent tasks times one, plus spares, because an IP that eats a ban mid-drop is gone for the event. Running 15 tasks with roughly 30 percent spare capacity, which is our assumption sized to expected ban attrition, means 20 IPs at $50 a month.

The same honesty applies here as in scraping. The hardest drops profile your browser fingerprint and behavior well past the IP layer, and a clean IP feeding a detectable automation stack still fails.

How many proxies for monitoring: vantage points plus one

Monitoring is where people over-buy the most. The formula is vantage points times one, and frequency only matters if it pushes a single IP past the target's tolerance. A check every 30 seconds is 120 requests per hour per target, which is nothing for most endpoints. It bites only against hard documented caps: poll an unauthenticated GitHub endpoint once a minute and you're sitting exactly at their 60 requests per hour per-IP limit.

Three vantage IPs plus one spare covers most price-tracking and uptime setups. That's $10 a month. If you need eyes from Frankfurt or São Paulo, we can't help; US-only is US-only, and you should buy those specific vantage points from a provider that has them rather than a bigger pool anywhere.

Oversized vs. undersized: common sizing mistakes and how to avoid them

Too few proxies fails loudly. Each IP runs hotter than the target tolerates, 429s trigger retries, retries add load, and the target escalates from rate limiting to blocking. Worse, because every IP in a small pool exhibits identical high-intensity behavior, bans tend to arrive as a wave that takes out the entire pool at once rather than one IP at a time. This is what the headroom multiplier is for.

Too many proxies fails silently, and where the waste hides depends on the pricing model. At flat per-IP pricing, an idle IP is a visible $2.50 line item; buy 100, use 30, and your invoice says so, and you resize next month. With per-GB residential pricing the waste moves into the meter, where it's much harder to see. The most recent Web Almanac, built on July 2025 HTTP Archive crawl data, puts the median desktop page at about 2.8 MB, so full-page scraping burns bandwidth quickly, and retries and bot-check interstitials bill the same as real data. Neither model forgives not measuring, but one of them at least shows you the number.

Decision shortcuts

Scrapers: start with 5 to 10 IPs, spend a day measuring the safe rate on your actual target, then apply the formula with 1.3x headroom. Resizing isn't a commitment; our API for programmatic proxy pool scaling and IP management handles order changes and replacements, so the pool grows or shrinks as the measurement dictates.

Multi-account operators: buy exactly as many IPs as accounts. If the budget hurts, run fewer accounts rather than shared IPs. A linked pair of accounts usually costs you both.

Checkout automation: count the tasks you'll actually run concurrently, not the tasks you own, add roughly a third for spares, and stop there. During the event, spares you can hot-swap matter more than raw pool size.

Monitoring: buy three or four and feel strange about how small the order is. Put the savings toward non-US vantage points from another provider if your checks need geography we don't cover.

Whichever bucket you're in, run the pricing-model comparison before the pool-size math if you're still choosing between flat per-IP and metered residential. We worked through the crossover point in our flat-rate versus per-GB breakeven math. Pool sizing tells you how many; that post tells you which kind.

FAQ

How many proxies do I need for web scraping?

Divide your target requests per hour by the per-IP rate your target tolerates, then add 20 to 30 percent headroom. The tolerated rate is not a universal constant; measure it by ramping up slowly on one IP until you see rate limiting, then back off. For a 5,000 request-per-hour job at one request per six seconds per IP, that works out to about 11 proxies.

How many proxies do I need to manage multiple accounts?

One dedicated static IP per account. Antidetect browser vendors including Multilogin and GoLogin recommend a different proxy for every browser profile, because profiles sharing an IP risk being linked together. Twenty accounts means twenty proxies.

How many extra proxies should I buy for failover capacity?

Roughly a third more than the base number your formula gives. With flat per-IP unlimited-bandwidth pricing, an idle proxy costs a couple of dollars a month, while an undersized pool causes rate-limit cascades and bans that can take out everything at once. Watch real usage after launch, then trim.

How do I expand my proxy pool after purchase?

Start with a small pool, measure how your target actually behaves, and resize from there. Stat's management API supports programmatic order management and IP replacement, so changing pool size doesn't require a support ticket.

If you'd rather sanity-check the math against your workload before buying anything, our trial is contact-gated and business-only. Tell us your target volumes and we'll size it with you.