Residential proxies: why IP blocking stopped working on its own

Short answer: Residential proxy networks route bot traffic through real household IP addresses, many of them on devices whose owners never agreed to carry it. That is why address blocklists decay in days and why behaviour, not address, has to carry detection now.

You blocked the addresses behind last week's attack and the attack came back on Tuesday from addresses belonging to somebody's smart TV in Ohio. That is the residential proxy problem in one sentence: the traffic now leaves from real homes, so the address tells you almost nothing about who sent it.

Where residential proxy addresses come from

Some supply is sold openly: apps and SDKs that pay users, or offer a free VPN, in exchange for routing traffic through their connection. A darker supply exists too. Krebs on Security's investigation of the BADBOX 2.0 operation described a botnet of off brand Android TV boxes and similar devices, sold with proxy capability already embedded, turning living room hardware into exit nodes for whoever rented the network.

For a defender the origin matters less than the consequence. The address on the request belongs to a real subscriber, has a clean history, and will be used by that household for ordinary browsing an hour later. Blocking it punishes a bystander and the attacker rotates to the next address in a pool that can number in the millions.

Why blocklists decay so fast now

A data centre blocklist used to hold for months because the ranges were stable and clearly not shoppers. Residential pools churn constantly: addresses are reassigned by providers, devices sleep and wake, and the same proxy network presents a different address for almost every request in a campaign. A list built from Monday's attack can be mostly stale by Friday, while its false positives, real households, keep accumulating.

Cloudflare's guidance on bot management makes the practical point: address reputation is now one signal among many, useful for the obvious cases and weak against rotating residential supply. Detection has to weight what the session does, the sequence and timing of requests, header and fingerprint consistency, and account behaviour, over where it appears to come from.

Signals that survive proxy rotation

Rotation changes the address, not the job. A credential stuffing run still tests passwords at machine pace against one endpoint. A scraper still walks categories in an order no shopper uses. A scalper still arrives with a new account and buys the scarcest item first. Behavioural patterns repeat because the underlying task repeats, and tasks are harder to randomise than addresses.

Fingerprint consistency helps too. A session claiming a current desktop browser while presenting header ordering, TLS traits, or screen properties that do not match that browser is lying about something, and the lie is stable across its addresses. None of these signals is decisive alone. Layered, they separate a household browsing from a household connection rented by the hour.

What to keep IP controls for

Address controls are not dead, they are demoted. Keep them for the clear cases: data centre ranges hitting consumer endpoints, addresses with thousands of requests an hour, known anonymiser exits where your buyers never are. Those blocks are cheap and safe. Just stop expecting them to carry a campaign defence, and stop reporting blocked addresses as blocked attackers.

The honest metric is attack success: accounts taken over, cards tested successfully, units scalped. When address blocks rise and attack success stays flat, the proxy pool is absorbing your defence. That gap, visible in your own numbers, is the argument for spending on behavioural detection instead of a bigger blocklist.

Keep reading: Disposable email checks: stopping fake accounts at the signup form, politely, ATO detection IDs: naming the attack session instead of chasing addresses.

Frequently asked questions

What is a residential proxy in plain language?

A service that routes internet traffic through real household connections, so requests appear to come from a home address instead of a data centre. Some supply comes from apps users install for payment or a free VPN. Investigations have also found proxy software embedded in cheap streaming devices without owners understanding it was there.

Why does blocking the IP address fail against these networks?

Because the pool is huge and constantly changing, and each address belongs to a real subscriber. The attacker rotates to a fresh household address for the next request, while your block lands on a bystander who later uses the same address for ordinary browsing. The list decays in days while false positives accumulate.

What signals work if the address does not?

Behaviour and consistency: the sequence and pace of requests, whether a session follows the steps a buyer takes, account age and purchase shape, and whether the browser fingerprint matches what the session claims to be. The attacker's task repeats even when the address changes, and the task is what detection can hold onto.

Should I remove IP blocking entirely?

No. Keep it for the obvious cases: data centre ranges on consumer endpoints, extreme request rates from one address, and anonymiser exits your customers never use. Treat it as one cheap layer, and judge the defence by attack success, takeovers, successful card tests, scalped units, rather than by addresses blocked.

Get a free bot-traffic audit