The Cheapest Proxy Per Request Is Not a Price

Which proxy is cheapest per request depends on volume, payload and block rate, not the headline rate. The arithmetic, and where each model stops winning.

No proxy is cheapest per request in general. The answer is decided by three numbers you already have, or can measure in an afternoon: how many requests you send in a month, how many kilobytes come back on an average one, and what share of them come back blocked. No advertised rate survives contact with those three.

Two answers up front. If you send a modest number of requests against ordinary pages and do not want to run any infrastructure, a per-request scraping API is usually cheaper and always simpler, and we do not sell one. Node4 is building one; until it opens, that is a real reason to buy from someone else. If your volume is sustained or your responses are large, a fixed or metered proxy plan costs less per request, and that is what we sell.

This article is the arithmetic. If you are still choosing between paying per address, per gigabyte or per connection, proxy pricing models is the reference for what each unit punishes, and this one will not repeat it.

What "per request" actually bills

Per-request providers, usually scraping APIs rather than proxy services, charge for each call rather than for capacity or traffic. You send a URL, you get HTML back, and the pool, the rotation and the retry logic stay invisible.

The headline rate is rarely the rate you pay, because most of these plans price in credits and a request can cost more than one. Rendering a page in a headless browser costs more than fetching its HTML. A target with serious bot defense costs more than an ordinary page. Search results and social platforms cost more again. None of that is dishonest, it is priced by difficulty, but it means the advertised per-request figure describes your easiest request rather than your average one.

So the first correction to make when comparing is to work out your blended credit cost: the mix of easy and hard targets you actually hit, weighted by how often you hit them. A rate that looks like a fraction of a cent can land several times higher once the mix is real.

The second correction is failures. Some providers bill only successful fetches, some bill every attempt, and the difference moves your true cost per usable page more than most rate differences do. If you retry a blocked page three times before it succeeds, one policy charges you once and the other charges you four times for the same row of data.

What a proxy plan bills instead

Capacity or traffic, never the call. Dedicated datacenter rents an address per month with no bandwidth meter, so requests through it are free at the margin. Shared datacenter is billed per proxy too, but with a bandwidth allowance pooled across the order rather than no meter at all, a distinction that matters further down. Residential and Rotating Datacenter bill by the gigabyte. Rotating Unmetered bills by concurrent connections and does not count bytes.

That is all the model description this article needs. What each unit rewards and punishes, and how to read a quote in one against a quote in another, is the reference linked above.

The arithmetic

Cost per request is the only number that compares these models, and it is easy to compute for each.

Per gigabyte:

cost per request = price per GB x average response size in GB

A 50 KB response is 0.00005 GB, so at any per-GB rate the per-request cost is that rate divided by twenty thousand. This is why payload size dominates the comparison: a page that returns 500 KB costs ten times as much to fetch as one that returns 50 KB, on exactly the same plan.

Per proxy with no meter:

cost per request = monthly cost of the proxy / requests sent through it that month

There is no floor here, which is the whole point. Push more requests through the same address and the per-request cost keeps falling until the target's tolerance, not your bill, becomes the limit. How many proxies a workload actually needs is the constraint that replaces cost.

Per concurrent connection:

cost per request = monthly cost of your connection tier / total requests that month

Same shape as per-proxy: fixed numerator, and your throughput decides the denominator. What you are sizing is the burst, not the total, and how concurrency is actually sold covers what enforces that number and what changes it mid-month.

Per request, for comparison:

cost per request = blended credit cost x price per credit

Note what is missing from that last one: response size appears nowhere. Under a per-request plan a 5 KB response and a 5 MB response cost the same, which is a genuine advantage on heavy pages and a genuine waste on light ones.

If you would rather not do the multiplication by hand, the proxy calculator takes request volume, failure share and average transfer per request and returns the proxy count and the gigabytes a run will consume, which are the two denominators above.

Where the crossover falls

There is no universal number. The crossover moves with your payload, your target mix and your retry rate, and those vary by more than an order of magnitude between workloads.

What you can do is compute it in about five minutes. Take your monthly request count and your average response size from a sample of a few hundred real fetches against your real targets. Multiply out the per-request cost under each model using the formulas above, using your blended credit cost rather than the headline rate. Whichever is lower is your answer, and it will not be the same answer next quarter if either input moves.

Three things push the crossover down, meaning fixed billing wins sooner than you would expect:

Large responses. Full pages with images and script bundles rather than a JSON endpoint or a price field.

Hard targets. Anything that triggers a rendering or difficulty multiplier on a per-request plan is charged at that multiple every single time, while a metered plan charges the same for a hard page as an easy one of the same size.

High retry rates. Under per-gigabyte billing a refused connection transfers no bytes and therefore bills nothing. Under dedicated per-proxy billing, with no meter, a retry is free outright. Under per-request billing it depends entirely on the provider's success policy.

And one thing pushes it up, meaning per-request stays cheaper longer: low, spiky volume. A fixed plan bills for capacity whether you use it or not, so a job that runs for one hour a week is paying for the other hundred and sixty-seven.

Block rate: the number that reorders the ranking

Every formula above divides by requests. Divide by delivered pages instead and the ranking can change, because the cheapest request is the one that comes back usable, and a plan whose cost per request is a third of another's is not cheaper if two thirds of its fetches come back blocked. Block rate does not appear on any rate card.

Failures are not one thing, and each billing unit prices them differently:

A refused connection transfers no bytes. It is free under per-gigabyte billing, free under dedicated per-proxy billing, and billed or not under per-request billing depending on the provider's policy. It costs you time and a retry, never money, on the metered tiers here.

A block page is the expensive one. A challenge page served with a success status, or a refusal that carries a full HTML body, transfers real bytes. Under per-gigabyte billing that page bills as a page, and a target that serves a heavy challenge to every classified address can consume an allowance while delivering nothing. Under dedicated per-proxy billing it is still free at the margin, while on shared datacenter it counts against the pooled allowance. Under per-request billing it is usually charged, because the fetch completed.

A slow success is free everywhere and still costs you, because it occupies a connection or a thread that could have carried another request. On a connection-priced tier that is the only cost there is.

What drives block rate is the classification of the exit, not the protocol and not the provider's copy. Datacenter addresses are cheap because they are issued to hosting facilities, and a target that cares can classify hosting ranges as a class, so a datacenter request against that target has a high block rate at any price. Residential addresses are not classified as hosting and cost more per byte. The two pull against each other, which is why cost per delivered page, not cost per request, is the number worth optimizing, and why the better procedure is to route each target to the cheapest tier it tolerates rather than to buy one tier for everything.

Measure rather than guess. Run a bounded, representative slice of the workload through the tier you are considering, count the pages you can actually use, and divide the bill by that. When a target blocks, replaying the blocked request shows whether the address or the client is what tripped it, and why an IP gets blocked covers the signals a target reads before it decides.

Which proxy here costs least per request

Assuming your volume has already put you on this side of the crossover:

Dedicated datacenter costs the least per request of anything we sell for a workload that can concentrate traffic through a few addresses. No meter, so the denominator grows and the numerator does not. It is the right answer for API integrations, internal tooling and anything against targets that accept hosting ranges, and the dedicated datacenter tier is where that pricing lives.

Shared datacenter costs less per proxy and carries a pooled allowance rather than no meter, so its per-request cost is lowest for light responses and rises as payloads grow. It is the tier to start on when the target accepts hosting ranges and the responses are small.

Rotating Datacenter costs more per request than a static address for the same bytes, and buys you address breadth in exchange. If your target rate-limits per IP, that breadth is what makes the requests possible at all, which is a different question from what it costs.

Rotating Unmetered wins whenever your bytes per request are high and your concurrency is predictable, because there is no byte meter and you are sizing connections instead; network safety limits still apply.

Residential is the most expensive per request and is not competing on price. You buy it when a target refuses hosting ranges outright, and the trade in full is worth reading before you assume you need it.

The general shape: the cheaper the address, the cheaper the request, and the narrower the set of targets that will accept it. Rates for every tier are on the pricing page, and if you are comparing against a provider you already use, the Proxy-Cheap comparison is written in these units rather than headline rates.

If per-request is genuinely what you want

Then buy it from a scraping API provider; Node4 has no per-request product. One is in development, and it is not on sale yet. Per-request pricing buys managed complexity, and that is worth paying for when your volume is small enough that convenience dominates the bill.

Node4 sells the infrastructure underneath. If you already have scraping logic, or the engineering time to write it, fixed billing costs less per request at volume and the gap widens as you grow.

If you are not sure which side of the line you are on, the free tier exists to find out without committing anything. It is static shared datacenter over HTTP(S), so it measures datacenter block rate and average payload against your real targets, which is exactly the input the formulas above need for the datacenter tiers; it cannot tell you what residential or a rotating gateway would do. Choosing the right proxy type for a target covers the half of this decision that is not about money.