Where Residential Proxy IPs Come From

How bandwidth-sharing SDKs work

A residential proxy network does not own the home connections it sells. To send your request out through someone's broadband line, it needs software running on a device behind that line. The economics of getting that software installed explain most of what follows.

The common route is a software development kit offered to app developers as a way to earn money. The developer adds the SDK to an app, often a no-cost game, utility or streaming app, and the SDK lets the proxy network route traffic through the device while the app is installed. The developer is paid by the network. Bright Data's SDK site, for example, markets the SDK to developers as a way to monetize users, describes a configurable consent screen so users "willingly opt-in", says it runs only when there is enough CPU, memory and battery, and says it pays developers a fixed daily rate (Bright SDK).

Not every network works that way. Google's threat intelligence group reported in January 2026 that it had disrupted IPIDEA, a network it called one of the largest of its kind in the world. Google said IPIDEA's operators marketed SDKs to developers for Android, Windows, iOS and WebOS, paid developers usually per download, and that many of the apps it analyzed did not disclose that they enrolled devices into the network (Google Threat Intelligence Group, January 2026). Google also observed no-cost VPN apps that joined devices to the network without clear disclosure, and noted that some users opted in knowingly for payment while others did not know.

Malware is the third route. The US Justice Department said in May 2024 that the 911 S5 residential proxy service was built on a botnet of more than 19 million infected IP addresses, spread through malicious VPN applications with proxy backdoor capabilities (US Department of Justice).

What the research found

Two peer-reviewed studies from the same research group give the clearest independent picture.

The first, presented at the IEEE Symposium on Security and Privacy in 2019, infiltrated several residential proxy services and collected about 6 million residential proxy IPs. The authors reported that many of the hosts appeared to be compromised devices, including IoT devices, even where providers claimed hosts joined willingly, and linked some proxy traffic to illicit activity such as phishing and malware hosting (Mi et al., "Resident Evil", IEEE S&P 2019).

The second, at NDSS 2021, looked at mobile proxy SDKs specifically. It found four providers offering proxy SDKs to Android developers as a monetization channel, 1,701 APKs from 963 apps that had integrated them, and one SDK that relayed traffic without showing any notification to the user (Mi et al., "Your Phone is My Proxy", NDSS 2021).

Neither study says that every residential network is abusive. They show that the model allows abuse to hide inside it, and that a provider's own description of its sourcing is not evidence on its own.

What app stores now say

Platform policy has tightened in response. Google Play's Device and Network Abuse policy states that apps facilitating proxy services to third parties may only do so where that is the app's primary, user-facing purpose, and that neither an app nor any third-party SDK inside it may access or interfere with devices or networks without authorization (Google Play Device and Network Abuse policy).

Enforcement follows. In its July 2026 update, Google said Google Play Protect warned users about and disabled apps known to include NetNut SDKs, and that it disabled Google accounts and services NetNut used for malware command and control, in coordination with the FBI and others (Google Threat Intelligence Group, July 2026). Google also said that many residential proxy brands were whitelabeling that network, which means a buyer may not know whose devices sit behind the brand they pay.

For a buyer, the policy shift matters in two ways. Apps that hide proxy behavior are now removed from the largest app store when found. And networks built on those apps can lose large parts of their capacity overnight.

What informed consent looks like

"Ethically sourced" appears on many pricing pages and is rarely defined. A workable definition has four parts, and each is something a provider can show you.

Even a clear opt-in leaves one gap: the user agrees to share bandwidth, not to have specific traffic sent through their home. If a buyer uses the exit for abuse, the household's address takes the reputation damage. That is a structural limit of the model, not a fault of any one provider.

Risks for buyers

Sourcing sounds like an ethics question, and it is, but it also lands on your own operations.

Reputation you did not earn. A shared residential exit has a history made by other buyers. If someone ran password spraying or ad fraud through it an hour ago, your session starts from that address's record. Our guide to IP reputation checks explains what the main lists actually measure.

Legal and compliance exposure. If a network is built on infected devices, your traffic passes through computers whose owners did not agree to carry it. Companies with compliance teams increasingly ask vendors to document sourcing, and a provider that cannot answer becomes a finding in your own audit.

Capacity that disappears. Google said its January action cut the device pool available to IPIDEA's operators by millions, and its July action caused significant degradation to NetNut's network. If your provider resells one of those networks, your success rate can fall with no warning and no explanation on the status page.

Instability you cannot debug. Enrolled devices come and go as people close apps, move between networks or switch off. Sticky sessions end early, and you cannot see why.

Questions to ask a provider

Before buying residential traffic for anything that matters, ask for written answers.

1. How do devices join your network: your own app, an SDK in third-party apps, partner networks, or hardware you operate?
2. If an SDK, what does the user see before sharing starts, and can they use the app without sharing?
3. Do you resell or whitelabel another provider's network? Which one?
4. How do you detect and stop abusive traffic from your customers?
5. What happened to your capacity after the January and July 2026 takedowns?

Vague answers to the first three are an answer in themselves.

Then test what you can verify yourself. Route a handful of requests through the network and look up each exit's ASN and connection type; a residential product should not return hosting ranges. Check a sample of exits against a public abuse list. And note how often sessions drop before their set time: frequent early drops suggest devices that come and go with app use rather than infrastructure the provider controls. None of this proves good sourcing, but it catches the worst cases before you build on them.

Hardware lines as the alternative

The other way to get a consumer-network exit is to operate the hardware yourself, or rent it from someone who does. A dedicated mobile line is a physical modem or phone with a SIM from the local carrier. Nobody's personal device is involved, and no app needs to persuade anyone to share a connection.

That changes the sourcing question into a simple one: who owns the device and the SIM, and who else uses it. On Coronium, each line is one physical device with its own SIM, rented to one customer, so no other buyer's traffic runs through it during your rental. The public address comes from the carrier's range and, through carrier-grade NAT, is also used by the carrier's own customers. That is how mobile networks are built, not a sourcing choice.

Hardware lines cost more per IP than a large residential network and give you one address at a time, so they do not replace residential traffic for every job. For logins, app traffic and work where an inherited history would hurt, they remove a risk you otherwise cannot measure. Compare the two models in mobile vs residential proxies, or see live countries and carriers on the mobile proxies overview.

How we checked

Claims about specific networks are attributed to the organization that made them: Google's threat intelligence team, the US Justice Department and peer-reviewed research. Coronium did not investigate any network's infrastructure. The SDK description quotes the vendor's own site. Sources were read on 30 October 2026.

Frequently asked questions