Research note 006
Proxies, Explained: Why Residential Ones Are So Hard to Stop — and Where They Come From
Proxies are how one actor becomes a thousand. A tour of datacenter, residential, and mobile proxies, why the residential kind defeats IP-based defense by design, and the uncomfortable supply chain that produces them — often from the phones of people who have no idea.
Most abuse on the internet runs into the same wall almost immediately: volume is visible. A thousand requests from one address in a minute is obvious, and blocking that address is trivial. So the single most important tool in an abuser’s kit isn’t a clever exploit — it’s a way to not look like one actor. That tool is the proxy, and understanding it explains an enormous amount about why bot defense is as hard as it is.
A proxy is simply an intermediary: instead of your traffic going straight to a website, it routes through some other machine first, and the website sees that machine’s address instead of yours. One request through one proxy is unremarkable. But a pool of thousands of proxies turns a single operator into what looks like thousands of unrelated users — and that is the entire game.
Not all proxies are equal
The defensive story turns almost entirely on what kind of address a proxy hands out, so it’s worth separating the three main types.
Datacenter proxies are IP addresses owned by hosting and cloud providers. They’re cheap, fast, and available in bulk — and they’re the easiest to catch. Those address ranges are publicly known to belong to data centers (you can look up the owning network, its ASN, from the IP), and no ordinary person browses from an Amazon or Hetzner server. A defender can flag datacenter traffic with high confidence. For anything that matters, datacenter proxies are the amateur tier.
Residential proxies are the problem. These are real IP addresses assigned by consumer ISPs to real homes — the same kind of address your own internet connection has. Traffic routed through one appears to come from an ordinary Comcast or Verizon subscriber in a real neighborhood, because in a literal sense it does. There’s no datacenter ASN to flag, no obvious tell in the address itself.
Mobile proxies are harder still. These use IP addresses from cellular carriers, and mobile networks route many real subscribers through a small number of shared addresses (carrier-grade NAT). That means a single mobile IP might legitimately represent hundreds of real people — so not only does the address look human, blocking it risks cutting off a crowd of innocent users. Mobile IPs carry the highest trust and the highest false-positive cost, which is exactly why they’re prized.
ISP proxies (static residential) are the hybrid, and the one that quietly defeats a defender’s favorite shortcut. Operators acquire IP ranges that are registered to consumer ISPs — leasing blocks, or arranging it with the ISPs directly — but host them in a datacenter. The result is an address that looks residential to a WHOIS or ASN lookup, because it genuinely belongs to a Verizon- or Comcast-style range, while delivering datacenter speed, stability, and the ability to hold the same IP for weeks (“static”). For an abuser it’s close to ideal: the legitimacy of a residential address without the flakiness of routing through someone’s actual living room. And it drives a stake through the most common classification check — “does this IP belong to an ISP or to a hosting provider?” — because now the honest answer is both.
How abusers use them, and how defenders respond
The abuser’s move is straightforward: spread activity across a large pool of addresses so no single one crosses a rate limit, and so IP-based reputation has nothing to grab onto. Scrapers, e-commerce bots, credential-stuffers, and ad-fraud operations all lean on this same trick of manufactured diversity.
The defender’s first instinct — IP intelligence — works well against the amateur tier and poorly against the rest. Flagging datacenter ranges, consulting known-proxy lists, and scoring address reputation catches a lot of low-effort abuse. But it runs directly into a hard limit with residential and mobile proxies, because there’s nothing wrong with the address. The IP belongs to a real home or a real carrier. IP reputation, the backbone of a generation of defenses, quietly stops working.
So detection has to move up the stack, away from where the traffic claims to come from and toward how it behaves:
- Cross-session correlation. A thousand IPs that all present the same device fingerprint, or behave with suspicious similarity, are probably one actor wearing a thousand masks. The IPs are clean; the pattern across them is not.
- Behavioral consistency. Automated activity, however well-distributed across addresses, tends to share timing, sequencing, and interaction signatures that real independent humans don’t.
- Velocity and impossible-travel. One account touched from addresses in five countries in ten minutes is a story the geography can’t support.
- Fingerprint coherence. The same environment-integrity checks that catch a spoofed browser catch a proxied one, because the proxy changes the address but not the fabricated environment behind it.
The through-line: once the IP can’t be trusted, the abuser has to be caught by the consistency of everything else, aggregated across the very sessions the proxies were meant to keep separate.
Why residential proxies are so hard — the honest version
It’s tempting to frame residential proxies as a detection puzzle waiting for a clever solution. The deeper reason they’re hard is that they’re not a trick at all — the traffic really is coming from a real residential connection. There is no artifact to detect in the address, because nothing about the address is fake.
That forces defenders into an uncomfortable position. The signals that do work — behavioral correlation, fingerprinting, velocity — are probabilistic and carry real false-positive risk, and the cost of getting it wrong lands on actual people. Block a shared mobile IP too aggressively and you’ve locked out a stadium’s worth of legitimate users. This is the recurring tax of bot defense: the harder you push against sophisticated evasion, the more you risk punishing the honest majority, and residential and mobile proxies sharpen that trade-off to a point.
Where residential proxies come from — the part nobody advertises
Which raises the question that the industry mostly prefers not to answer loudly: if these are real people’s home and mobile connections, how does a proxy provider get millions of them?
The answer is that, one way or another, real people’s devices are being used as exit nodes — and often those people have no meaningful idea it’s happening.
At the transparent end of the spectrum, there are openly-branded “share your bandwidth, earn a little money” applications (Honeygain is the best-known example) where a user consciously installs software that resells their spare connection. Consent exists, at least nominally.
At the other end — and this is the larger, murkier reality — the sharing is bundled and buried. A common model: a free app (a game, a utility, a VPN, a wallpaper app) integrates a third-party SDK whose real purpose is to quietly route other people’s traffic through the user’s connection. In exchange, the SDK vendor pays the app developer. The user downloaded a flashlight app; what they also installed was a residential exit node, disclosed nowhere a normal person would read, or not disclosed at all. Security researchers have repeatedly found these SDKs embedded in otherwise-ordinary apps in both the Android (APK) and iOS (IPA) ecosystems.
From there it’s an aggregation business. The bandwidth harvested from all those conscripted devices is pooled and resold — through a layer of providers that range from ostensibly-legitimate data companies to openly gray-market operations — to scrapers, e-commerce bots, ad-verification firms, and anyone else who needs to look like a crowd of real residential users. The person whose phone is doing the proxying sees none of the money and none of the traffic. They just notice their data usage is a little high.
This reframes residential proxies as something bigger than a bot-defense nuisance. It’s a software supply-chain problem: a shady SDK inside a popular free app can conscript millions of real devices into an infrastructure the device owners never agreed to and can’t see. That’s a mobile-security and app-store-integrity issue as much as an anti-bot one, and it’s why the two fields keep bleeding into each other.
Where the pool cracks: when abuse outgrows the supply
For all that residential proxies defeat IP reputation, they have a structural weakness — and it shows up exactly where abuse is most intense. The supply of real residential IPs is large but finite, and demand is spiky. A limited sneaker drop, or a hot restock on a giant retailer like Walmart, sends thousands of operators reaching for residential IPs in the same few minutes. When demand outruns the pool, the infrastructure starts to overlap in ways no real household ever would — and the overlap leaks signal.
Oversubscription. Providers rent from a finite pool, and under peak load the same exit IP gets handed to multiple customers at once. Now a single residential address — nominally one home — is driving several independent automated sessions simultaneously, often hammering the exact same product. A real family does not open forty checkout attempts for one item from one connection in the same second. The address still looks residential; the concurrency and behavior on it are impossible.
Cross-provider collisions. Because a single harvested device often carries more than one bandwidth-selling SDK — a user with several sketchy free apps is enrolled in several pools at once — the same physical IP can be sold by two different providers to two different customers who have no idea they’re sharing it. That produces the same collision from another angle: one address showing multiple uncoordinated automated actors, each with its own fingerprint and rhythm, none aware of the others.
This is the quiet gift a high-abuse site gets for free: the attackers’ own scale turns the residential pool against them. The harder everyone leans on the same finite infrastructure, the more that finiteness shows — as impossible concurrency, as fingerprint disagreement on a single address, as behavior a genuine one-household connection could never produce. A site under enormous bot pressure can, in principle, detect because of that pressure: the pool is recycled so aggressively that collisions become a reliable tell.
It doesn’t make residential proxies easy — patient, low-and-slow abuse that never oversubscribes still slips through, which is why the sophisticated operators throttle themselves. But it flips the intuition: the defender’s best signal often isn’t any single request, it’s the impossible shape of everything happening on one address at once.
What a defender should take from this
- Don’t trust IP reputation alone — residential and mobile proxies are built to defeat it. Treat the address as one weak signal, not a verdict. The clean-looking IP is often the whole point of the attack.
- ASN/WHOIS classification is gameable. “ISP-registered” no longer means “a real home” — static-residential ranges are ISP-registered and datacenter-hosted at once. Corroborate registry data with actual hosting and routing behavior (latency, network characteristics), not the WHOIS entry alone.
- Catch the actor, not the address. The durable signal is consistency across sessions the proxies tried to separate — fingerprint correlation, behavior, velocity. Look for the one actor wearing a thousand faces.
- At scale, watch for the impossible shape. Under heavy abuse, oversubscribed residential pools betray themselves — the same address driving many concurrent, uncoordinated automated sessions is a collision no real household produces. High bot pressure is also, paradoxically, high signal.
- Respect the false-positive cost. Shared residential and carrier IPs mean real people sit behind addresses you might want to block. Over-blocking by IP is how anti-abuse work quietly harms the users it’s meant to protect; weigh that cost explicitly.
- Watch the SDK supply chain. If you build apps, know what your dependencies actually do — a bandwidth-sharing SDK is a reputational and security liability riding inside your product. If you’re a user, treat “free” apps that seem to have no business model with suspicion; sometimes the product being sold is your connection.
Proxies are, at bottom, a way to turn one into many — and residential proxies do it using the borrowed identities of real people, harvested through a supply chain most of those people never knew they were part of. Understanding that is the difference between fighting the address and fighting the actor. Only one of those fights is winnable.
This article is a defensive and awareness-focused overview of proxy infrastructure and its abuse. It describes how the ecosystem works and how detection approaches it, not how to operate proxies or evade detection, and it names no sourcing or purchasing channels.