Proxy Requirement Calculator

How the number is derived

Two independent floors, and the larger one wins. 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. The retry multiplier then inflates whichever floor won, because a failed attempt still costs a request.

1. Count the full request volume, pagination and per-page extras included.
2. Convert it to peak requests per second over the run window.
3. Rate floor: peak rate divided by r.
4. Concurrency floor: required in-flight divided by the per-address cap.
5. Take the larger floor, then apply the retry multiplier.
6. Decide the shape: an address count you shard, or bandwidth through a pool.

Rates are converted to requests per second and windows to seconds before anything is divided, so 30 per minute and 0.5 per second give the same answer. Bandwidth is attempts including retries times the average transfer, in decimal units (1 GB is 1,000,000 KB). It counts a failed attempt at full size, so treat it as an upper estimate. The calculator suggests a static pool while the answer is 100 addresses or fewer and the failure allowance is under 30%, and a rotating gateway otherwise. Those two cut-offs are planning rules of thumb, shown so you can apply your own. The plan size is the smallest listed size that covers the answer: addresses for a static pool, or GB per run times runs per month for a rotating one.

Failures and the retry multiplier

A failure is any attempt you have to repeat to get the response you need: a timeout, a reset connection, a 403 or 429, or a challenge page in place of content. If a share f of attempts fail and every failure is retried until it succeeds, each success costs 1 / (1 − f) attempts on average, so attempts = requests / (1 − f). At 20% that is 1.25 attempts per success and at 40% about 1.67. At 100% no number of retries finishes the job, which is why the field stops at 95%. The multiplier assumes failures are spread evenly across attempts; a target that blocks an address outright after a few tries costs more than this.

To measure your own rate, send a few hundred requests to your target at the pace you plan to run, through the kind of address you plan to use, and divide the failed attempts by the total. The rate moves with pace, time of day and the target's defenses, so re-check it before a large run. The 5%, 20% and 35% in the example settings are illustrations, not typical values.

Measuring r

r is the sustained rate one address holds against your specific target before the 429s and challenge pages start. It depends on that target's defenses, not on any proxy, so it has to be measured. From one address, request at a 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 change without announcement.

When more proxies will not help

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, so a job that collects 429s can triple its pool and collect the same 429s. The check takes minutes: run the same pattern through two exits at once. If combined throughput roughly doubles, the limit is per-address and more addresses help. If it stays put, the fix is pacing, session handling or header hygiene, and this estimate does not apply.

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.