How Many Proxies Do I Need? Formulas and Ready Tables

For anything with a login, the count is not about request volume. Platforms link accounts that share an IP, so the safe ratio is one dedicated address per account, kept stable for the account's lifetime. Ten accounts mean ten proxies.

• Add 10-20% spare IPs if you scale quickly, so a replacement is ready when an address does not suit a platform.
• Use private addresses, not shared ones; see private vs shared proxies.
• Keep the country of each proxy the same as the account's country.
• Some operators put two or three low-risk accounts on one mobile IP, relying on carrier NAT. It saves money and adds risk; the one-to-one rule is the safe default.

Which type to buy per account is covered in proxies for Instagram and TikTok multi-accounting and mobile proxies explained.

Every site tolerates a certain number of requests per IP per minute before it slows you down. That number is the key input. Everything else is arithmetic.

requests per minute (RPM) = pages to fetch / minutes available
IPs needed               = RPM / safe requests per IP per minute
IPs to buy               = IPs needed x 1.2   (20% reserve)

1. 01

   Measure the safe rate

   Take one proxy and request pages from your target, slowly increasing the rate. Note when you start getting 429 Too Many Requests, CAPTCHAs or empty pages.

2. 02

   Halve it

   Use about half of the rate where problems started. Sites change thresholds, and you want headroom.

3. 03

   Compute RPM

   Divide the number of pages by the time window you have, in minutes.

4. 04

   Divide and add reserve

   Divide RPM by the safe rate and add 15-25% for addresses that get throttled or replaced.

5. 05

   Test on a small batch

   Run 5-10% of the job, check the success rate, adjust the rate or pool, then scale.

The last row shows when a static list stops being practical. Hundreds of IPs for a strict site is the point where a rotating residential pool, billed by traffic, usually becomes simpler and cheaper than buying addresses one by one. The trade-offs are in rotating vs static proxies.

Rank trackers think in queries per day rather than per minute. Search engines are sensitive to automated queries, so the safe rate per IP is low and varies with the engine, country and query type.

queries per day = keywords x locations x checks per day
IPs needed      = queries per day / safe queries per IP per day
IPs to buy      = IPs needed x 1.2

Example:
  2,000 keywords x 3 countries x 1 check = 6,000 queries per day
  safe rate measured: 300 queries per IP per day
  6,000 / 300 = 20 IPs, x 1.2 = 24 IPs (8 per country)

Buy the IPs in the countries you track: a US ranking checked from a German IP is not a US ranking. More on proxies for SEO.

Residential pools are usually billed by traffic, so the question becomes how many gigabytes the job needs. Everything your client downloads counts: HTML, scripts, styles, images, fonts and API responses.

GB = pages x average transfer per page (MB) / 1024

Example A, plain HTTP client fetching HTML only:
  100,000 pages x 0.15 MB = ~15 GB

Example B, full headless browser with all resources:
  100,000 pages x 2.5 MB = ~244 GB

Full page weight on the modern web is often more than 2 MB according to HTTP Archive data, while the HTML document alone is usually a small fraction of that. The difference between examples A and B is the main cost lever.

1. 01

   Measure one page

   Load a typical page through your real client and sum the transferred bytes, for example in the browser's network panel.

2. 02

   Block what you do not need

   In Playwright or Puppeteer, abort requests for images, fonts and media. This often cuts traffic several times.

3. 03

   Prefer APIs and HTML

   If the data is in the HTML or a JSON endpoint, fetch only that instead of rendering the full page.

4. 04

   Add retries to the estimate

   Failed and retried requests also consume traffic. Add 10-20% on top.

BLOCK = {'image', 'media', 'font'}

page.route('**/*', lambda route: route.abort()
           if route.request.resource_type in BLOCK else route.continue_())

Real projects mix tasks, so it helps to size each part separately and then add them up. Imagine a small agency that manages social media for clients, monitors competitor prices and tracks search rankings.

Two things stand out. First, the account part is sized by headcount, not by traffic, and it needs the most trusted IP types. Second, the data part is sized by rate and can use the cheapest addresses that the targets accept. Keeping the lists separate means a problem on the scraping side never touches an account.

Review the numbers monthly. Accounts get added, targets tighten their limits, and a scraper that ran fine at 8 requests per minute may need 5 next quarter. Re-measuring the safe rate takes ten minutes and prevents both overpaying and sudden waves of blocks.

Many teams mix both: static datacenter IPv4 or IPv6 for easy targets and a residential budget for the strict ones. See best proxies for web scraping for a target-by-target breakdown.

1. 1Buying IPs instead of fixing the pattern. If one IP gets blocked after ten fast requests, a hundred IPs get blocked after a thousand. Slow down and fix headers first.
2. 2Many IPs from one subnet. Sites often limit whole ranges, and for IPv6 they usually count the /64 as one user. See IPv4 vs IPv6 proxies.
3. 3No reserve. Without spare addresses, one throttled IP stalls a worker.
4. 4Sharing account IPs with scrapers. Keep account proxies and scraping proxies in separate lists.
5. 5Skipping the test run. Validate the list in the free proxy checker, test a few addresses on the target, then scale.