Count honestly: every page of pagination, every API call a page fires, every asset you fetch.
The window you actually run in, not the calendar day.
Your measured r. No provider can supply this: it is a property of the target's defenses.
What your deadline needs running at once. Leave at 0 if you do not know it yet.
Defended targets often cap this at one or two, independently of request rate.
Share of attempts lost to timeouts, resets and challenge pages. 20 to 33 is a defensible starting range.
Measure it with your real fetch settings. HTML only and everything-loaded differ by an order of magnitude.
Proxies needed
14
That is the floor, not the order. Buy above it: addresses arrive cold, some trip a defense and need resting, and volume grows with the catalog.
Which product fits
Buy addresses: a static pool
14 addresses is a pool you can shard yourself, and the failure allowance is low enough that addresses are being paced rather than burned. You are buying an address count, so per-IP pricing is the cheaper shape.
The working
- Run window
- 28,800 s
- Peak aggregate rate
- 6.9 req/s
- Per-IP rate (r)
- 0.50 req/s
- Rate floor
- 13.9 addresses
- Concurrency floor
- not given
- Binding constraint
- Pace against the per-IP rate limit
- Retry multiplier
- 1.00x
- Requests including retries
- 200,000
- Requests per proxy
- 14,286
- Each proxy busy for
- 7 h 56 min of the window (99%)
- Bandwidth for the run
- 80.0 GB
What this number assumes
- No in-flight figure was given, so only the rate floor was computed. If your target caps simultaneous connections per address, that can set a higher floor on its own.
- With a 0% failure allowance this is the paper number. Real runs lose requests to timeouts, resets and challenge pages; 20% to 33% is a defensible planning range against a defended target until you have measured your own.
- Every address would be working almost the entire window at its tolerated rate, with no slack for a cold start or a rested address. Buying above the floor is normal.
- More addresses only help when the limit is keyed to the address. A limit keyed to an account, an API key, a session cookie or a fingerprint follows your traffic through every exit you own.
How the number is derived
Two independent floors, and you take the larger. The rate floor is your peak aggregate request rate divided by the rate a single address is tolerated at. The concurrency floor is the number of requests you need in flight divided by the simultaneous connections one address is allowed. Then the retry multiplier inflates whichever floor won, because a failed attempt still costs a request.
- Count true request volume, pagination and per-page extras included.
- Convert it to peak requests per second over the window you actually run in.
- Rate floor: peak rate divided by r.
- Concurrency floor: required in-flight divided by the per-address cap.
- Take the larger floor, then apply the retry multiplier.
- Decide the shape: an address count you shard, or bandwidth through a pool.
Measuring r, the input nobody can give you
r is the sustained rate one address holds against your specific target before the 429s and challenge pages start. It is a property of that target's defenses, not of any proxy, so no provider can quote it. Measure it: from one address, request at a deliberately gentle pace, step the rate up while holding at each level, and take half of the last clean rate as your working figure. The headroom is deliberate, because limits are enforced over bursts rather than smooth averages. Re-measure per target and re-measure occasionally, since defenses get retuned without announcement.
When the answer is zero more proxies
A job starts collecting 429s, the operator concludes there are not enough proxies, triples the pool, and collects exactly the same 429s. More addresses raise your ceiling only when the limit is keyed to the address. Limits keyed to an account, an API key, a session cookie or a TLS fingerprint follow your traffic through every exit you own. The diagnostic takes minutes: run the same pattern through two exits at once. If combined throughput roughly doubles, the limit is per-address and procurement helps. If it stays put, the fix is pacing, session handling or header hygiene, and buying addresses just buys a larger invoice.
The full derivation, with worked examples
This calculator implements the arithmetic from How Many Proxies Do I Need: The Actual Math, which walks two jobs at different scales through the same steps, covers why the window and r dominate the result far more than page count does, and explains when a rotating gateway is the better shape than a static pool you shard yourself. If you already know your address count and just need the connection details, the connection string builder takes it from there.