Unlike a botnet of compromised devices, a residential proxy DDoS rents its source addresses rather than infecting them: the traffic still arrives from real homes, but no malware put it there. It is an evasion-focused use of attack infrastructure, and separating it from genuine users is increasingly part of a thorough DDoS test. Proxy networks resell access to IP addresses assigned to consumer broadband and mobile carriers, sometimes sourced from real devices running an SDK the owner consented to in an app's fine print. Tunnel Layer 7 requests through that pool and the malicious traffic originates from the same address space as genuine customers.
What makes it different from a botnet
Both a botnet and a residential proxy DDoS win by dispersion: many source addresses, each staying under the per-IP thresholds that would catch a single loud sender. That shared mechanism is covered under botnet, so the interesting part is where the two diverge.
A botnet is devices the operator compromised and now controls. A residential proxy network is a commercial service: the operator pays for exit capacity and routes requests through addresses it does not own and never infected. The practical consequence is that the address pool looks cleaner than a botnet's. These are not IoT cameras with known-bad reputations; they are the same broadband and 4G/5G ranges your paying customers connect from, which is precisely why the source is so hard to judge.
That also changes the economics of blocking. A residential proxy exit sits behind carrier-grade NAT more often than not, so a single address can front hundreds of real subscribers. Drop it and you drop them too.
Why it matters under attack
This is the hardest source model to filter, because every network-identity signal a defender normally leans on degrades at once. IP reputation is weak when the addresses are clean consumer space with no attack history. Geo-blocking fails when the exits sit in exactly the regions your genuine audience comes from. ASN-based rules fail because the traffic rides the same consumer ISPs as real users. Every one of those controls, applied bluntly, risks severing paying customers along with the attack.
So the defense has to move from where a request comes from to how the client behaves. Request fingerprinting (JA3/JA4, header order, TLS quirks), challenge-response that a real browser passes and a headless proxy client does not, and bot management that scores behaviour over a session rather than judging a single packet. The question stops being "is this address bad" and becomes "does this client act like a human using the app".
What a DDoS test measures
A test built around this source model measures how cleanly the L7 controls separate two populations that look identical at the network layer: real users and proxied attack traffic sharing the same ranges. It drives requests through realistic residential-shaped sources and watches the false-positive rate as the behavioral controls tighten, because the failure that matters most here is not letting the attack through, it is blocking real customers while trying to stop it.
The deliverable is where the fingerprinting and challenge tier holds, where it starts flagging genuine sessions, and how much of the flood survives all of it. For how that separation factors into measured resilience, see DDoS resilience testing.