How Many Proxies Do I Need? 2026 Sizing Formula

"How many proxies do I need?" is the most-asked pre-purchase question in this industry, and the answer most providers give — "it depends" — is the truth, but it is also useless. This guide gives you a real working formula, the per-use-case numbers behind it, and the math you can run on the back of a napkin before you spend a dollar.

By the end you will know exactly how many proxies, of which type, and at what budget your specific workload needs — without over-buying or running out at 3am during a critical scrape.

The three variables that determine proxy count

Before any formula, you need to know your three inputs. Get these wrong and the math is wrong.

1. Concurrent threads (C). How many requests are in flight at the same time. A scraper running 50 worker threads has C = 50. A single-threaded sneaker bot has C = 1.
2. Requests per hour per IP the target tolerates (R). The rate limit your IP can sustain on the target site before triggering a 429, soft block, or CAPTCHA. This is what people call "site tolerance."
3. Total requests per hour you need (T). Your throughput goal — pages per hour, accounts checked per hour, ads verified per hour.

The two formulas you actually use:

For sticky-session work (one IP per task):

IPs needed = C  ×  safety_margin (1.2–1.5)

For rotating-pool scraping:

IPs needed = T ÷ R  ×  safety_margin (1.2–1.5)

The safety margin matters. Real-world workloads have request bursts, retries, slow target sites, and occasional dead IPs. 20–50% headroom keeps you from burning out the pool the moment something hiccups.

Worked example 1: scraping at scale

You are scraping product listings from an e-commerce site. You want to pull 100,000 pages per hour. Testing shows the target tolerates about 200 requests per hour per IP before throttling.

T = 100,000 pages / hour
R = 200 requests / hour / IP
IPs = 100,000 ÷ 200 = 500
With 30% safety margin: 500 × 1.3 = 650 IPs

This does NOT mean you need to buy 650 separate proxy subscriptions. With a rotating residential pool, your gateway gives you access to millions of IPs and rotates them automatically. What you actually buy is bandwidth, not IPs. At 30KB per page average:

Bandwidth = 100,000 × 30KB = 3GB / hour
Cost on SpyderProxy Premium ($2.75/GB): $8.25 / hour

Most users are surprised by how cheap rotating residential is for raw scraping. The pool size you have access to matters; the number of IPs you actively use is irrelevant to billing.

Worked example 2: account management

You manage 30 Amazon Seller Central accounts and Amazon flags any account that switches IPs. You need each account to log in from the same IP every time.

C = 30 accounts (one IP each, locked to that account)
IPs = 30 × 1.0 (no margin needed since accounts are 1:1)
       = 30 static residential IPs

This is the use case for static residential (ISP) proxies, not rotating. Each account gets a dedicated IP that does not change. SpyderProxy static residential at $3.90/day per IP × 30 IPs = $117/day.

Could you do this with rotating residential? Technically yes — with sticky sessions of 24 hours. Practically no — sessions reset on disconnect, the underlying device might leave the network mid-session, and you have no guarantee tomorrow's IP for account #14 is the same as today's. Don't cut corners on multi-accounting.

Worked example 3: sneaker botting

You are running 10 tasks for a Nike SNKRS drop. Each task needs a fresh IP that has never touched Nike before, and the IP needs to stay sticky through queue + checkout (~30 minutes).

C = 10 concurrent tasks
Sticky session length needed = 30 minutes
IPs = 10 × 1.5 (margin for IP burnout / queue retries)
    = 15 IPs minimum

For a single drop you can use rotating residential with sticky sessions. For repeated drops where you want each task to have a permanent identity, switch to static residential. Cost on SpyderProxy: 15 sticky-session GB usage at $2.75/GB ($5–15 per drop) OR 15 static residential IPs at $3.90/day each.

Worked example 4: SERP / SEO tracking

You track 5,000 keywords daily across 10 countries. Each keyword check is one request. Google tolerates roughly 10 requests per IP per hour before showing a CAPTCHA.

T = 5,000 keywords × 10 countries = 50,000 / day = ~2,100 / hour
R = 10 / hour / IP
IPs = 2,100 ÷ 10 = 210
With safety: 210 × 1.5 = 315 IPs in rotation

Again, you do not buy 315 IPs — you use a rotating gateway with that many IPs available simultaneously across the geos you need. SpyderProxy Premium has 130M+ IPs in 195+ countries, so the pool size is not the constraint. Bandwidth is: ~50KB per Google SERP × 50,000 = 2.5GB/day = $7/day on Premium.

Worked example 5: ad verification

Brand-safety team needs to load 1,000 unique ad slots from 25 different cities every hour to verify creatives. Each load is ~3MB (a real browser session with the page rendered).

T = 1,000 × 25 = 25,000 sessions / hour
R = irrelevant (one session per IP, then rotate)
IPs in rotation = 25 (one per city, sticky for the session length)
Bandwidth = 25,000 × 3MB = 75GB / hour

Note the bandwidth wall: at 75GB/hour, residential rotating residential costs ~$200/hour. This is a use case where the bandwidth is the cost driver, not the IP count. Some teams switch to static datacenter proxies (unlimited bandwidth) for ad verification once volume scales past a few hundred GB/day, accepting the lower trust score in exchange for predictable costs.

Quick reference table

If you don't want to do the math, this is the rough starting point for common workloads.

Use case	Proxy type	IPs needed	Why
Single-target scraping (under 10K req/day)	Rotating datacenter	1 gateway	Pool handles diversity
Hostile-target scraping (Cloudflare, Akamai)	Rotating residential	1 gateway	Trust score is the constraint
Multi-accounting (per-account IP)	Static residential	1 per account	Account-IP binding
Sneaker drop (small)	Rotating residential w/ sticky	1.5 × tasks	Burnout margin
Sneaker drop (frequent / serious)	Static residential	1 per task	Permanent identity
SERP tracking (1K–100K keywords)	Rotating residential	1 gateway	Google tolerates ~10/h/IP
Ad verification (per-geo)	Rotating residential	1 gateway, sticky	One sticky session per geo
Internal load testing	Rotating datacenter	1 gateway	Cheapest, fastest
Geofenced content access (per-country)	Static residential or rotating	1 per country	Geo precision

Bandwidth vs IPs vs sessions: pricing models compared

Different proxy types are priced on different units, and this trips people up.

• Rotating residential — priced per GB. You pay for traffic, the IP pool is "included." SpyderProxy: $1.75/GB Budget, $2.75/GB Premium.
• Static residential (ISP) — priced per IP per day or per month. You pay for the dedicated IP, bandwidth is unlimited. SpyderProxy: $3.90/day per IP.
• Static datacenter — priced per IP per month, unlimited bandwidth. SpyderProxy: $1.50/proxy/month.
• LTE mobile — priced per IP per month with bandwidth caps. SpyderProxy: $2/IP.

The mental model: traffic-heavy and short-session work is GB-priced. Identity-heavy and long-session work is IP-priced. Match the pricing model to the workload, not the other way around.

Common mistakes

The five over-buying / under-buying patterns we see most often.

Buying too many static IPs for scraping

If your goal is scraping diversity, do not buy 200 static residential IPs. Buy a small balance of rotating residential and let the gateway handle the rotation. Static IPs are for identity continuity, not request volume.

Under-buying bandwidth for ad verification or rendered scraping

People budget for "HTML scraping" bandwidth and forget that loading a real page in a headless browser pulls 3–10MB of JS, CSS, fonts, and images. Multiply your HTML estimate by 50 for browser-rendered work.

Choosing residential when datacenter would have worked

If you tested your target with a $1 datacenter trial and got clean responses, residential is overkill. Save the 6× markup for the targets that actually need it.

Ignoring concurrent connection limits

Most providers cap concurrent connections per account (SpyderProxy: 1,000 by default, raised on request). If your scraper runs 5,000 threads, you will hit the cap before you hit your bandwidth budget.

Not testing the target's actual rate limit

Every guess at "requests per hour per IP" should be replaced with a 30-minute test against your real target. Some sites tolerate 1,000/hr, some tolerate 5/hr, and you do not know which until you measure.

How to size your first purchase

If you have never bought proxies before, the conservative starting plan:

1. Buy $10–20 of pre-paid rotating residential on a Budget tier ($1.75/GB → ~6–11GB).
2. Run your real workload for 2–3 hours. Measure success rate, bandwidth used, and average requests per IP before throttling.
3. Extrapolate from real data: (observed bandwidth × hours of operation needed) + 30% safety margin.
4. If multi-accounting, add 1 static residential IP per account separately.
5. Re-test monthly — target sites change their anti-bot stacks and your numbers will drift.

Bottom line

For rotating-pool scraping, IP count is irrelevant — you buy bandwidth and the gateway handles rotation. For sticky-session work (multi-accounting, sneakers, ad verification), buy 1 IP per concurrent task plus a 20–50% safety margin.

The fastest way to get the answer for your specific workload: spin up $10 of rotating residential, run your real code for two hours, measure bandwidth and per-IP throughput, then size the production order from real numbers. Guessing from the marketing page is how teams either run out at 3am or burn $500/month on capacity they don't use.