Residential proxies

A residential proxy sends your request out through an address that a consumer internet provider assigned to a real household line, so the destination sees what looks like an ordinary subscriber rather than a server. It is for work that needs many different addresses in many places, against a target that has already refused a cheaper category — and for nothing else, because you pay by the byte.

What you are actually renting

The category is defined by registration, not by speed or price. The address sits inside an allocation held by a consumer ISP and is announced by that ISP's network, which is what the ASN lookup reveals. That record is why the traffic is treated as a person rather than as infrastructure.

The line, though, belongs to somebody else. You borrow a slice of a stranger's connection for the length of a request, and every awkward property of the category follows from that. The peer closes the laptop and the address is gone; the household starts a video call and your throughput changes. None of it is under your control, and no provider can make it so.

How the address reached the pool is therefore a practical question, not only an ethical one.

How the address is sourced	What the person on the line agreed to
An SDK bundled into a free application	A term accepted during installation
A paid or rewarded peer client	An explicit exchange, usually clearer
An ISP or hardware partnership	Terms set by the operator
Bought wholesale from another aggregator	Unknown to the seller

The last row decides how stable your supply is: a reseller cannot produce consent wording it never collected. Pools sourced through applications also shift when those applications leave a store or an SDK is stripped out, so the composition you tested in a trial is not a fixed asset.

Why the bill is per gigabyte

Per-gigabyte pricing is not a commercial preference; it is what the supply side looks like. The provider's cost is somebody else's bandwidth, and the lines carrying it turn over constantly. There is no durable address to rent you, so the only unit matching the provider's own cost is transferred data. Datacenter and ISP addresses are billed per address for the mirror-image reason: there, the address is what persists.

Metering counts bytes crossing the proxy, not bytes you found useful, so failures, retries, redirects, headers and challenge pages all reach the invoice; bandwidth billing sets out what is counted. A rendering browser fetches every asset on the page by default, each one metered at residential rates.

The useful estimate is therefore not price per gigabyte but bytes per record you accepted. Run a small job against your own targets, take the reported usage, and divide by the records that passed validation. That figure reflects your parsing and your retries, and turns plan comparison into arithmetic.

Where it earns its cost, and where it does not

The work	Right category?	Why
Many independent fetches across many countries	Yes	Breadth is what the pool provides and nothing else does
Small JSON responses from many markets	Yes	Little data crosses the meter
The target ignores network origin	No	Datacenter costs less and runs faster
An API that authenticates you by key	No	The service already knows who you are
One identity that must persist for weeks	No	An ISP address is exclusive and static
Full page rendering with all assets	Rarely	Per-address billing removes the meter
Refused by a JavaScript challenge	No	The address was never the variable

The comparison guide works the decision in order. The step people skip is the first: prove the target checks network origin before paying to disguise it.

The spread between providers is wider than the spread between categories

Two services sold as residential can differ more from each other than residential differs from ISP, and the difference never shows in the headline. It is in depth in the country you need rather than globally, in how many independent networks sit behind the addresses, in what happens to a sticky session when the peer disconnects, and in whether an unavailable location is refused or quietly widened to a neighbour — geo-targeting covers that last one, which shows itself only when a pool is thin.

None of it appears on a price list, so measure the pool you bought:

# Draw repeatedly from the rotating endpoint and keep the exits you were given
for i in $(seq 1 200); do
  curl -s --max-time 20 -x "http://USER-country-gb:[email protected]:8000" \
       https://echo.example/ip
done | sort -u > exits.txt

wc -l < exits.txt                      # distinct addresses, not the advertised pool

# How many independent networks are behind them?
while read -r ip; do
  whois -h whois.cymru.com " -v $ip" | tail -1
done < exits.txt | awk -F'|' '{print $1}' | sort -u | wc -l

Raise the draw count until the distinct-address total stops climbing. That plateau describes your account, your country and your plan — the only pool that matters to you. The network count is the sharper of the two: addresses on few networks share a fate, because one classification decision removes them together.

What to ask before you buy

• Show me the consent wording the peer saw — the text, not a summary of it.
• Is any of this pool bought from another supplier? Then the answers above are second-hand.
• How many addresses are concurrently available in my country, measured when and how?
• When a location cannot be satisfied, do you refuse or widen? Those are different products.
• What is metered? Get failed requests, headers and retries in writing.
• How does a sticky session end early, and how is that signalled? Silent replacement is the expensive answer.
• What is the rotation unit, and is concurrency capped per account or per port?
• Does unused traffic expire? Ask before the first renewal.

What we do not publish about this category

No pool sizes, no success rates, no prices and no speeds. Nobody outside a provider can audit its pool, and vendors do not define the figure the same way, so repeating one would launder a claim into a fact. A success rate without a named target, a sample size, a date and a definition of success is not a measurement, and here it also depends on the household at the far end.

Measure your own targets instead. Run the sampling loop above, define success by asserting on content rather than status codes — success rate explains why the gap is wide — and use the tools to see what an exit looks like from outside.