Where Do Residential Proxy IPs Come From

Residential proxy IPs come from consumer internet connections whose owners agreed, at some point and with varying clarity, to let third-party traffic exit through their device. The provider's asset is not an address block. It is a contract with an app publisher, a bandwidth-sharing product, or an ISP, plus the traffic capacity that contract produces.

Four consequences fall straight out of that, and each one is a line item in your buying decision.

You are renting borrowed capacity, so it leaves. A phone goes on aeroplane mode, an app is uninstalled, a router reboots onto a new CGNAT address. That is why almost no vendor will sell you a specific residential IP with an uptime commitment attached.

Price is per gigabyte because the provider's cost is per gigabyte. Whoever supplies the bandwidth gets paid in proportion to traffic, so the meter has to run on traffic too.

Legal exposure sits entirely on consent quality. The IP is not the risk. The disclosure text a stranger scrolled past three years ago is the risk.

Advertised pool size is a union, not a concurrency figure. Most vendors define pool size as distinct IPs observed across a measurement window, often a month, not the number online at once. Ask which definition the number uses, over what window, and how many of those exits sat in your target country during business hours. A vendor that will not answer has told you something.

If you want the ground-level definition first, see what is a residential proxy, then come back here for the supply chain.

1. App SDK monetization

This is the volume driver behind most large residential networks. A mobile or desktop app publisher embeds a proxy SDK and gets paid per gigabyte routed. The end user sees a line in the terms, sometimes a consent dialog, sometimes an ad-free tier offered in exchange, and their device becomes an exit node while it is idle and on Wi-Fi.

Quality varies enormously here, and the variable is the publisher, not the network. One network can hold an SDK partner with a full-screen opt-in and another whose disclosure is clause 14 of an EULA. When you ask a vendor about sourcing, this is the layer to interrogate.

2. Paid bandwidth-sharing applications

Standalone apps that pay a user directly for shared bandwidth, usually in cents per gigabyte or in gift-card credit. Consent here is the cleanest available, because the entire product proposition is the transaction. The catch is scale: people who deliberately install a bandwidth-sharing app are a small population, so these pools skew toward a handful of countries and toward unmetered connections.

3. Free VPNs, free tools and rewarded tiers

A free product funded by resold exit traffic instead of advertising. The consent is real in a contractual sense and thin in a practical one, since almost nobody reads why a VPN is free. Regulators have taken an interest in this pattern, and buyers operating in the EU should assume it draws more scrutiny than an explicit paid-bandwidth arrangement.

4. ISP partnerships and leased ranges

Here the provider deals with the network operator, not the household, leasing or buying address space registered to a consumer ISP but hosted in a datacenter. These are ISP proxies: residential ASN registration with datacenter stability, static rather than rotating, sold per IP rather than per gigabyte. No end-user device is involved, which is why procurement teams find this the easiest category to approve. The trade-off is a smaller and more visible address footprint. See ISP proxies vs residential proxies for where each one breaks.

5. Wholesale resale and white label

A large share of the vendors on any comparison page do not operate a network. They buy capacity wholesale from one or two upstream operators and resell it under their own dashboard. Plenty of resellers add real value in tooling and support, so this is not automatically bad, but your diligence has to travel one hop further than the company you are paying. Ask directly: do you operate your own supply, and if not, who is upstream?

The one to rule out: undisclosed installs

Traffic sold from devices infected by malware, bundled into cracked software, or routed through a library the app developer did not know was proxying. Networks built this way exist and they are cheap. The exits look identical to the legitimate kind on the wire, so price and evasiveness are your only signals. The relay mechanics match any P2P proxy network; the difference is entirely in the consent record behind it.

Almost nobody explains this, so buyers keep comparing two prices that are not comparable.

A residential provider's cost of goods is a revenue share paid to whoever supplied the bandwidth, denominated in traffic. Every gigabyte you pull costs the provider money in real time, so its meter has to run on gigabytes too.

A datacenter provider owns or leases the subnet outright. The rack, the transit commit and the address block are fixed monthly costs, and your thousandth request that hour costs effectively nothing more than your first. The sane unit becomes concurrency: how many simultaneous connections you occupy, not how many bytes pass through them. That is why SparkProxy's datacenter plans meter threads and leave bandwidth unlimited:

All four run unlimited bandwidth on 30-day validity. The speed figures are ceilings under the fair usage policy, not guaranteed throughput, and higher tiers (Pro at 1500 threads, Pro+ at 2000, custom builds up to 1 Gbps) are quoted rather than listed publicly.

The practical consequence: a job that moves a lot of bytes but does not need consumer IP identity is dramatically cheaper on a flat thread-priced plan than on any metered residential network, whoever's per-GB rate you compare. Residential list prices are published by each network on its own pricing page and change often, with entry-tier per-GB rates typically falling as you commit to larger monthly volume, so pull the current figure from the vendor before you model anything and treat any per-GB number quoted in an article as stale. For the flat-rate side, see datacenter proxy pricing models.

The phrase sits on every residential vendor's homepage, it is unregulated, and it means whatever the marketing team decided. Treat it as a claim to be tested, and ask for these seven artefacts before you sign. A network with real sourcing produces all of them in a day.

1. The actual disclosure text shown to end users, in the languages it is shown in. Not a summary. The screen.
2. Where in the install flow it appears. Before install, at first run, or buried in an EULA.
3. Whether users are compensated, and in what form.
4. Category exclusions. Confirmation in writing that no traffic is sourced from apps aimed at children, or from medical, financial or enterprise-managed devices.
5. Revocation latency. After a user opts out or uninstalls, how long until that device stops carrying traffic.
6. KYC on the buying side. A network that will not verify its own customers is not protecting its supply, and the pool reputation eventually shows it.
7. Upstream disclosure. If they resell, the name of the operator whose supply you are running on.

Point 4 most often produces silence. Point 7 most often produces a different answer than the marketing site implies.

Documents tell you what a vendor promises. A trial tells you what the network is. Spend the trial on measurement rather than on a single happy-path request: pull a few hundred exits and record what comes back.

import requests
from collections import Counter

PROXY = "http://USER:PASS@gateway.sparkproxy.io:11000"
seen = Counter()

for _ in range(300):
    r = requests.get(
        "https://api.ipify.org?format=json",
        proxies={"http": PROXY, "https": PROXY},
        timeout=15,
    )
    seen[r.json()["ip"]] += 1

print(f"{len(seen)} unique IPs across 300 requests")
print("most reused:", seen.most_common(5))

Then resolve what those addresses actually are. Registry data is the ground truth, not the vendor's label:

curl -s https://rdap.arin.net/registry/ip/203.0.113.10 \
  | jq -r '.name, .type, (.entities[0].handle // "no-handle")'

What you are looking for:

• Hosting ASNs inside a residential pool. If a meaningful share of "residential" exits resolve to well-known cloud or hosting networks, you are paying residential rates for datacenter addresses. Registration and routing can also disagree with each other, a separate trap covered in BGP and RIR IP allocations.
• Country accuracy against two independent sources, never the vendor's own geo API alone. A pool sold as UK that answers from Frankfurt is a routing artefact, and you want to know before you build a report on it.
• Reuse rate. If 300 requests return 40 unique IPs, your real pool depth in that geo is 40, whatever the homepage says.
• Session persistence. For sticky work, hold a session and confirm the exit survives the full flow you actually run. SparkProxy exposes sticky sessions on port 11002 and SOCKS5 on 13000, alongside HTTP and HTTPS on 11000.
• Reputation, not just reachability. An exit that connects but sits on a blocklist is worthless, and a connectivity test will not show it. IP reputation is the metric that predicts your success rate.

Run the same script against every vendor on your shortlist and the marketing differences collapse into four numbers you can put in a spreadsheet.

Sourcing diligence is also continuity diligence. This industry carries more concentration and more regulatory attention than its pricing pages suggest, and a supplier disappearing is not hypothetical. As of September 2026, netnut.io resolves to the nameservers ns1.fbi.seized.gov and ns2.fbi.seized.gov, which is what a US law enforcement domain seizure looks like from the outside. Run the DNS lookup yourself rather than taking anyone's word for it, this article included, and put that check in your annual vendor review.

Two practices follow.

Do not hard-code one gateway. Keep endpoints and credentials in configuration, not in source, so a supplier change is a deploy rather than a rewrite.

Keep a second supplier warm. A small paid plan on an alternative network, exercised weekly by your monitoring, turns an outage into a config change for less than one engineer-day of emergency migration.

A large share of residential spend goes to targets that never needed it. The honest test is not "is my target big", it is "does my target key on IP type".

Buy residential when the target scores IP reputation aggressively, when you need city-level consumer geo, or when the workflow is bound to a real consumer account. Buy ISP proxies when you need one stable identity across a login session. Buy datacenter when your target serves you fine from a clean commercial subnet, which covers far more of the web than residential marketing implies.

The cheapest architecture most teams miss is the split: run everything on datacenter, detect the failures, retry only those on residential. Residential stops being a fixed line item and becomes an exception cost. If you are still choosing between categories, residential vs datacenter proxies lays out the decision target by target, and what to evaluate when selecting a proxy service covers the rest of the checklist.

Residential IPs come from other people's homes, by way of an app SDK, a paid bandwidth app, a free product, an ISP lease, or a wholesale contract you cannot see from the dashboard. The price model follows the supply model. The legal exposure follows the consent record. The pool depth you get follows neither number on the homepage.

Before you pay anyone: ask for the seven consent artefacts above, run 300 requests through a trial and count unique IPs and ASNs, and check whether your target scores IP type at all. Plenty of buyers who reach that third step find they were about to overpay for a problem they do not have.

SparkProxy runs 1M+ datacenter IPs across 80+ countries, including more than 50,000 US addresses, on flat unlimited-bandwidth plans with no per-GB meter. To test whether datacenter clears your targets before committing to a metered network, the Scraping API gives you 1,000 free credits with no card: a plain fetch costs 1 credit, a JavaScript render 5, a screenshot or PDF 10.