Where residential IP addresses actually come from

Every proxy provider’s landing page shows the same map: thousands of little dots scattered across the world, each one supposedly a real home internet connection you can route traffic through. Nobody explains how those dots got there. Run enough proxy infrastructure and you start asking that question for practical reasons, not curiosity. Where an IP comes from determines how stable it is, how it behaves under load, and whether the network you’re buying into is one you want your business tied to.

What actually makes an IP residential

An IP address is “residential” because of who it’s registered to, not because of any technical property of the address itself. Internet Service Providers get allocated address blocks from a regional registry (ARIN, RIPE, APNIC, and so on), and they assign those addresses to subscribers, home routers, cable modems, fiber ONTs. When a website checks whether a connecting IP is residential, it’s usually looking up the IP’s ASN (autonomous system number) and WHOIS record and matching it against known ISP allocations, not datacenter blocks like AWS, OVH, or Hetzner.

That’s the whole distinction. A residential IP is one that traces back to a consumer ISP. It carries no special trust on its own, it’s just harder to mass-flag than a datacenter range because a website can’t block “all of Comcast” without blocking millions of real visitors along with it. That asymmetry is the entire reason residential proxies exist as a product category.

The SDK and bandwidth-sharing model

Almost no residential proxy network owns the home connections it routes through. What most of them do is pay for access to bandwidth on devices that already sit on real ISP connections, using an SDK embedded in a free app, or a standalone “proxy network” app that a user installs directly.

The SDK model works like this: an app developer, often making a free VPN, a game mod, or a utility app, integrates a proxy network’s SDK in exchange for revenue share instead of ad money. When the app is running, the user’s device becomes an exit node for other people’s traffic, in exchange for the app being free. The proxy company aggregates these devices, keeps a pool of which ones are currently online, and routes customer traffic through whichever one is available and matches the requested location.

Some networks skip the SDK and ask people to install a dedicated app in exchange for a small cash payout or free VPN service, explicitly framed as “share your unused bandwidth, get paid.” This is a cleaner consent path in principle, because the person installed something whose entire purpose is stated on the tin.

Consent is the part that varies the most

This is where residential networks differ from each other in ways that actually matter, not just in marketing copy. The core question is whether the person whose connection is being used for someone else’s scraping traffic actually knew that’s what they agreed to.

At one end, a provider discloses clearly, in the app itself and in a standalone terms of service, that installing the app turns the device into a proxy exit node, states what kind of traffic might pass through it, and gives an easy way to opt out or uninstall. At the other end, the disclosure exists only buried in paragraph 40 of a EULA nobody reads, written in language that never uses the word “proxy,” and the user has no idea their phone or laptop is relaying somebody else’s web requests.

Both of these produce IPs that look identical from your side, an address, a city, an ASN. But they are not the same product. A network built on genuine informed consent tends to have a more stable and more cooperative pool, because the people supplying bandwidth know what they signed up for and keep the app installed. A network built on buried consent tends to have higher churn, because users uninstall the moment they notice unexpected background data usage, and it invites exactly the kind of legal and reputational risk that gets a provider’s supply cut off overnight.

If you’re picking a residential proxy provider, the sourcing and consent model is the single most useful thing to dig into before price or pool size, because it predicts both how the network will behave under load and how long it’s likely to exist.

Mobile IPs source differently

Mobile residential proxies, the ones tied to carrier networks like a 4G or 5G connection, come from a related but distinct pipeline. Some are sourced the same way as fixed-line residential IPs, through an SDK on a phone. Others come from proxy operators who run physical device farms: racks of real phones or modems, each with an active SIM card, connected to a mobile carrier’s network directly.

Carrier-grade NAT changes the picture here. Mobile carriers put huge numbers of subscribers behind a small number of public IPs and rotate which subscriber holds which address constantly, sometimes every few minutes. That means a single mobile IP is, at any given moment, shared by many real subscribers doing their own normal browsing. This is part of why mobile IPs are harder for a site to block outright: blocking one address risks blocking a large slice of a carrier’s real customer base, not one bad actor.

Static residential and “ISP proxies” are a different category

You’ll also see providers sell “static residential” or “ISP proxies.” These are not sourced from consumer devices at all. They’re datacenter-hosted IPs that a provider has arranged, through relationships with ISPs, to have registered under residential or business ISP ASNs rather than datacenter ASNs. The IP sits on a server in a data center, but its WHOIS and ASN metadata reads as belonging to a consumer ISP.

This matters because it means “looks residential in a lookup” and “actually sourced from a residential connection” are two different claims, and providers don’t always make clear which one they’re selling. Neither is inherently better, they behave differently, and a scraper choosing between them should know which one they’re actually buying rather than assuming the label tells the whole story.

What sourcing means for the person running the scraper

None of this is about whether a proxy will get you past a particular site’s defenses. Detection systems look at far more than IP classification: request timing, header consistency, TLS fingerprints, behavioral patterns across a session. A residential IP with sloppy request behavior behind it gets flagged just as fast as a datacenter one. Sourcing affects a different set of things: how stable the pool is over a scraping run, how much of the pool is shared concurrently with other customers, how likely an IP is to already be flagged before you touch it, and what legal and ethical exposure the provider is carrying that could shut off your supply with no warning.

Practically, that means treating sourcing as a diligence question, not a footnote. Ask a provider directly how they source their pool. A provider that answers clearly, names the model, points to where consent is disclosed to end users, is telling you something real about how the business is run. A provider that answers with only marketing language about pool size and countries covered is telling you something too.

Building this into how you evaluate providers

The practical habit worth building is treating “where does your pool come from” as a standard question in any proxy provider evaluation, right alongside price per GB and geographic coverage. Read the provider’s own disclosures about sourcing before signing a contract. Check whether the underlying consent app or SDK, if named, has its own public terms describing what it does. None of this guarantees a network is well run, but a provider unwilling or unable to explain its own sourcing is telling you something worth weighing before you build a production scraper on top of it.

If you want more breakdowns like this, we cover proxy sourcing, rotation, and provider comparisons on the Proxy Scraping site.

Get new guides and videos first — join the Telegram channel.