Residential vs datacenter vs ISP vs mobile: which to use

Choosing a proxy type is usually presented as a quality ladder, with datacenter at the bottom and mobile at the top. That framing sells expensive products and produces bad decisions. The useful question is not which type is hardest to block, but which is the cheapest type your target does not object to.

#What actually separates the types

All four move your traffic the same way. The difference is who owns the exit address. Every public address belongs to an autonomous system identified by an ASN, and that ownership is published. Filtering systems look it up.

#The decision procedure

Run this in order. Stop at the first step that works.

#Step 1 — test whether the target checks at all

A large proportion of sites do not inspect network origin. Find out before spending:

# Same request, no proxy and then through a datacenter proxy
curl -sS -o /dev/null -w "direct:     %{http_code}\n" https://target.example/page
curl -sS -o /dev/null -w "datacenter: %{http_code}\n" \
     -x http://user:[email protected]:8000 https://target.example/page

If both return the same usable response, you are finished. Datacenter is faster and cheaper, and nothing further is required.

#Step 2 — decide whether you need a stable identity

If the work involves logging in, holding a basket, or any multi-step flow, you need one address for the duration. That means ISP, or residential with a sticky session. Rotating mid-flow is itself suspicious, as covered in rotating vs sticky sessions.

#Step 3 — if blocked, diagnose before upgrading

This is where money is most often wasted. Before concluding you need a better pool, establish that the address is what failed. Ask an echo service through the same proxy: if that succeeds while your target refuses you, the proxy is healthy and something about your client is the problem.

Check, in this order:

1. TLS fingerprint — does your client handshake like a browser?
2. Header order and completeness.
3. Whether the page needs JavaScript to issue a token.
4. Request rate — a 429 is not a proxy problem.

Only if all four are clean is the address itself the likely cause.

#Step 4 — escalate one step, not three

Datacenter to ISP is often enough, and preserves speed and per-address billing. Go to residential when you need volume and geographic spread. Go to mobile only when residential has demonstrably failed, because the cost difference is large.

#Cost behaves differently per type

Per-address and per-gigabyte plans are not directly comparable, and which is cheaper depends entirely on your traffic shape.

• High bandwidth, few identities — rendering pages, downloading assets. Per-address billing (datacenter or ISP) usually wins, because traffic is unmetered.
• Low bandwidth, many identities — small API responses from many regions. Per-gigabyte residential usually wins, because you pay for very little data.

A headless browser on a per-gigabyte residential plan is the classic expensive mistake: it fetches every image, font and script by default, and each one is billable. Blocking non-essential resources typically removes most of that bill.

#What to verify before committing

• Concurrency limit. Frequently the real throughput constraint, and easy to miss while comparing price per gigabyte.
• Depth in the countries you need. A large global pool concentrated elsewhere is not useful to you.
• Trial terms. Test against your actual target, not against an echo service, because those behave completely differently.
• Minimum spend and expiry. Unused traffic frequently expires monthly.

#The summary worth remembering

Buy the cheapest type that survives your target, size the plan by your traffic shape rather than the headline rate, and diagnose the client stack before assuming the pool is at fault. Most “we need better proxies” conclusions are, on inspection, fingerprinting problems that a more expensive address will not touch.

#Working an example end to end

Abstract advice is easy to agree with and hard to apply, so consider a concrete case: collecting product listings from a large retailer, a few thousand pages daily, from three countries.

#Step 1: does it check?

for label in direct datacenter; do
  case $label in
    direct)     args="" ;;
    datacenter) args="-x http://user:[email protected]:8000" ;;
  esac
  code=$(curl -sS -o /tmp/b -w '%{http_code}' $args https://retailer.example/product/123)
  printf '%-12s %s  %s bytes\n' "$label" "$code" "$(wc -c < /tmp/b)"
done

Note that the byte count is printed alongside the status. A 200 that returns a fraction of the expected size is a block, and comparing sizes catches it immediately.

#Step 2: interpreting the result

• Both full-size 200s — use datacenter. You are done, at the lowest cost available.
• Direct works, datacenter blocked — the network origin is being checked. Move up one step to ISP.
• Both blocked — the address is not the variable. Investigate your client before buying anything.

#Step 3: sizing the plan

This is where the billing model decides the answer. Suppose each page transfers roughly a megabyte with assets, and you fetch a few thousand daily across three countries. That is a per-gigabyte figure you can compute from your own measurements — and it is worth actually measuring rather than estimating, because headless browser traffic routinely exceeds expectations by an order of magnitude.

# Measure real transfer for one page, through the proxy you intend to buy
curl -x "$PROXY" -sS -o /dev/null \
  -w 'downloaded: %{size_download} bytes  total: %{time_total}s\n' \
  https://retailer.example/product/123

Multiply by your real page count, add a margin for retries and failures, and compare that against a per-address plan sized by concurrency instead. Whichever is cheaper at your traffic shape is the correct answer, and it differs between projects.

#Reducing what you transfer

Before upgrading a plan, reduce demand. On per-gigabyte billing these are the highest-value changes:

We deliberately do not publish percentages here, because the real figure depends entirely on the page and only your own measurement is meaningful.

#Questions worth asking before you buy

• How many addresses are concurrently available in the specific countries I need — not the global pool figure?
• Is the advertised pool number measured now, or accumulated over a period?
• What is the concurrency limit on the tier I am actually buying?
• What happens when I exceed it: queue, refuse, or error?
• Does unused traffic roll over, or expire monthly?
• Is session control available on this tier, and what is the maximum window?
• Can I target by ASN, or only by country?
• What does the trial allow, and can I test against my real target during it?

The last one matters more than the rest combined. A trial that only works against an echo service tells you nothing, because echo services do not run anti-bot systems.

#Signals that you are solving the wrong problem

Stop and re-diagnose if any of these are true:

• An echo service succeeds through the same proxy while your target refuses you.
• You are getting connection resets with no HTTP status, which points at TLS rejection.
• Failures are 429s, which is pacing rather than address quality.
• Upgrading from datacenter to residential produced no measurable change.

Each of these indicates the constraint lives in your client stack or your request pattern. More expensive addresses will not move any of them, and the money spent finding that out is entirely avoidable.

#Where to go next

To get a working configuration, see using a proxy with curl or proxies in Python. If you are already being blocked, reading proxy and block errors identifies which system is refusing you before you spend anything.

#How the categories behave over time

One thing rarely mentioned in comparisons is that these categories are not stable properties. They are judgements made by third parties, and judgements change.

A datacenter range that works against a target today may be added to a hosting-range list next month, at which point every address in it degrades at once. Residential addresses churn constantly as real connections come and go, so the pool you tested is not literally the pool you use tomorrow. ISP allocations are more stable precisely because they are static — which is also why burning one through careless use is costly.

Two practical consequences follow. First, a benchmark has a shelf life; a result from six months ago describes a situation that no longer exists. Second, build monitoring that tells you when success rates move, rather than discovering it when a dataset turns out to be empty.

#Running your own comparison

Vendor claims are a starting point, not evidence. If you are choosing between options, test them against your actual target during the trial:

#!/bin/bash
# Same URL, same moment, through each candidate.
URL="https://target.example/product/123"
for name in a b c; do
  case $name in
    a) P="http://user:[email protected]:8000" ;;
    b) P="http://user:[email protected]:8000" ;;
    c) P="http://user:[email protected]:8000" ;;
  esac
  ok=0
  for i in $(seq 1 25); do
    code=$(curl -sS -o /tmp/b -w '%{http_code}' --max-time 20 -x "$P" "$URL")
    size=$(wc -c < /tmp/b)
    [ "$code" = "200" ] && [ "$size" -gt 1500 ] && ok=$((ok+1))
  done
  printf '%-4s %2d/25 usable\n' "$name" "$ok"
done

Note what is being counted: a 200 and a plausible response size. Counting status alone would score block pages as successes, which is how vendor-favourable comparisons get produced by accident.

Twenty-five requests is a small sample and will not separate close candidates. It is enough to eliminate the obviously unsuitable, which is the decision most people actually need to make during a trial.

#The summary, once more

Buy the cheapest category your target tolerates. Size the plan by measuring your own traffic rather than trusting a headline rate. Reduce what you transfer before upgrading what you pay for. And when something fails, establish which layer refused you before assuming it was the address — because the layer that refuses you most often is the one you are not looking at.