the product names describe where the exit address lives. they do not tell you which one your target will accept. one question decides that: does the site grade the network a request arrives from? if it does not, buy the cheap option and stop reading. if it does, buy the option whose network scores well and pay for it.
start from what the target inspects
every request carries a source address, and the owner of that address is public. an address belongs to an autonomous system, that system is registered to a hosting company or a consumer isp or a mobile carrier, and the lookup takes a millisecond at the edge. the check runs before your request reaches any application code, which is why server addresses and home addresses are priced differently in the first place.
so the first experiment is not a benchmark. it is finding out whether the target reacts to the network at all.
- fetch the page from a plain server with no proxy. if it answers normally, the target is not grading hosting ranges and datacenter will do.
- fetch it again from a known hosting range and watch for a challenge, a consent wall, or a 403 on the very first request.
- fetch it while signed in, if your job needs an account. account age and history often weigh more than the address does.
- repeat at the rate you actually intend to run. a target that tolerates ten requests can refuse a thousand from one address.
the four types, and what each one buys
| type | the exit lives on | price per gb | reach for it when |
|---|---|---|---|
| datacenter | a hosting rack, on a hosting asn | less than the standard residential and mobile pools | the target does not grade the network |
| isp | a hosting rack, on space registered to a consumer isp | between datacenter and residential | you want one static address that still reads as consumer |
| residential | a real home connection, shared by its owner | more than datacenter and isp | the target challenges or refuses hosting ranges |
| mobile | a phone carrier, behind carrier grade nat | more than datacenter and isp | the target reads a carrier address as a trust signal |
the ordering in that third column is the part worth remembering, and it holds for the standard pools. there is one exception worth knowing before you buy on price alone: the budget residential tier is cheaper per gb than datacenter, so "residential costs more" is a rule about the standard pool rather than about every real-user address. the figures themselves move with volume tiers and with what a provider is paying upstream, so the plan pages carry them and this one does not.
run the test rather than reading the table
a proxy type is a hypothesis about your target, and checking it costs a few minutes. the check is the same request through each candidate with the status code, the response size and the timing printed side by side.
# compare one target across the exits you are considering.
# set each PROXY_* to a full proxy url: http://user:pass@host:port
TARGET="https://target.example/product/1234"
for name in datacenter residential mobile; do
var="PROXY_$(printf '%s' "$name" | tr 'a-z' 'A-Z')"
proxy="${!var}"
[ -n "$proxy" ] || continue
printf '%-12s ' "$name"
curl --proxy "$proxy" --silent --show-error --output /dev/null \
--write-out 'status=%{http_code} bytes=%{size_download} time=%{time_total}s\n' \
"$TARGET"
donerun it a few dozen times rather than once. a single 200 proves very little, because the first request from a fresh address is the one most likely to be served. what you are measuring is how the status changes as an address accumulates history.
ask for the least targeting you need
country, state, city and asn are filters over one pool. each filter you add removes exits, and a narrow filter can leave you rotating across a handful of addresses that then burn together under load. country is nearly always available. city and asn depend on real devices being online in that place at that moment.
- geoblocked content needs country and nothing else.
- local pricing and local search results usually need city.
- a target that behaves differently for one carrier or one isp needs asn.
- everything else should stay unfiltered, so the pool stays wide.
when to buy time instead of bandwidth
metered products bill the bytes you move. flat products bill a line for a period, priced by speed and duration, and the bytes stop mattering. the crossover is a volume rather than a workload: below it the meter is cheaper, above it the line is, and the number that decides it is your monthly gigabytes and not your peak hour.
a flat line is one address, or a small set of them, so it behaves like a sticky session that never rotates. that suits long signed in sessions and continuous polling. it is the wrong shape for spreading a crawl across many source addresses, which is what a pool is for.