Scrapeless Wiki

How Do Residential Proxies Work?

Informational P1 how do residential proxies work
Overlaps a live page. A published page already targets this keyword: https://www.scrapeless.com/en/glossary/residential-proxies. Publishing both risks cannibalisation — decide before this goes live.

Follow a request through a residential proxy network: peer devices, the gateway, session control, geographic targeting, and why latency is unavoidable.

A residential proxy network is a pool of consumer devices that agree to relay traffic, fronted by a gateway you connect to. Understanding the path explains both why it defeats IP-based detection and why it is slow.

1. The Architecture

Three parts:

  1. Peer devices. Phones and computers on home connections, running software that lets them relay requests.
  2. The gateway. A single endpoint you connect to, which selects a peer and routes through it.
  3. Your client, which only ever talks to the gateway.

You never address a peer directly. You send everything to one hostname and port, and the routing happens behind it.

2. A Request, Step by Step

  1. Your client connects to gateway.provider.com:8080 with credentials.
  2. The gateway parses those credentials — they encode country, session and other options.
  3. It picks an available peer matching the criteria.
  4. It forwards your request to that peer.
  5. The peer makes the request to the destination from its home IP.
  6. The response travels back: destination → peer → gateway → you.

The destination sees the peer's residential address, and nothing about the gateway or you.

That is four network hops rather than one, which is the whole latency story.

3. Control Through the Username

Providers encode routing in the username field, because it is the one string that passes through every HTTP client unchanged:

customer-USER-cc-de-city-berlin-sessid-a1b2c3:[email protected]:8080
Segment Effect
cc-de Exit from Germany
city-berlin Narrow to a city
sessid-a1b2c3 Pin one IP to this session
sesstime-10 Hold it for ten minutes

Change the session identifier and you get a different exit. Keep it and you keep the address. This is why a single connection string can drive an entire geographic strategy without any code change.

4. Rotation vs. Sticky

Per-request rotation is the default: every request selects a new peer, so a thousand requests arrive from a thousand addresses.

Correct for independent fetches. Fatal for anything stateful — a login on one IP and the next page from another country reads as session hijacking, and most sites will invalidate it.

Sticky sessions hold one peer for a bounded period, typically up to ten or thirty minutes. Required for authentication, pagination, carts and multi-step flows.

The bound is not arbitrary: the peer is a consumer device that may sleep, disconnect or change networks. No provider can promise an address indefinitely, so sticky sessions expire and your code must survive that.

5. Geographic Targeting

Because peers are real households, country targeting is genuine presence rather than a header claim. A request through a Berlin peer originates in Berlin — same routing, same ISP class, same geolocation databases.

Two caveats:

  • Granularity depends on pool density. Country targeting is reliable everywhere; city targeting works well in dense markets and poorly in thin ones, where it may silently widen to the country.
  • Geolocation databases disagree. The address may resolve differently across providers, so the site's view of where you are is not guaranteed to match the label you selected.

6. Why It Is Slow

Latency is structural, not a quality problem:

  • Four hops instead of one.
  • Consumer upstream bandwidth, typically a fraction of downstream, and the peer must upload the whole response to the gateway.
  • Peer contention — the device is also being used by its owner.
  • New connections on rotation. A different exit means a new TCP connection and a new TLS handshake, so per-request rotation forfeits connection reuse entirely.

Expect hundreds of milliseconds added per request, and design for concurrency rather than speed.

7. What It Does Not Change

The proxy changes the source address. It changes nothing else.

Your TLS handshake passes through the tunnel untouched, so the destination sees your client's real fingerprint. Your headers arrive as you sent them. Your browser fingerprint, if you are driving one, is whatever your environment produces.

This is why "we moved to residential and the blocking continued" is such a common report. The IP was never the signal — and rotating addresses under an unchanged, recognisable client just distributes the same identity across a larger surface.

8. Summary

A residential proxy network routes your request through a consumer device via a gateway you address by hostname, with country, city and session pinning encoded in the username. The destination sees the peer's home IP and nothing else.

Per-request rotation suits independent fetches; sticky sessions are mandatory for stateful flows and expire because the underlying devices are real and unreliable. Geographic targeting is genuine, with accuracy that depends on pool density in the target market.

The latency — four hops, consumer upstream, no connection reuse under rotation — is inherent to the design. And the network only ever changes where a request appears to come from: TLS fingerprint, headers and browser environment travel through unchanged, which is where blocking usually persists.