Residential proxies: why your IP blocklist stopped working

What changed, and when

For most of the web's history, hostile automation was easy to place. It came from a datacentre. The address belonged to a hosting company, the autonomous system was one you could look up, and blocking the whole range cost you nothing because no customers lived there.

That heuristic is dead, and it died commercially rather than technically. Residential proxy networks now sell access to millions of addresses belonging to ordinary home and mobile connections, priced per gigabyte, with a self-service dashboard and rotation on every request.

The result is that an attacker's traffic now arrives from the same address space as your customers. Not a lookalike of it — the same space, often the same ISP, sometimes the same city.

Every control you built on "is this address suspicious in itself" now has a false-negative problem you cannot fix by improving the list.

Where the addresses come from

This matters because it determines what you can safely do about them.

Some are consented. A user installs a free VPN, a browser extension or a mobile game that discloses, somewhere in its terms, that idle bandwidth is resold. They agreed, in the sense that lawyers use the word.

Some are barely consented. An SDK bundled into an app the user wanted, with a disclosure written to be technically present and practically unread.

Some are not consented at all. Compromised routers, IoT devices and phones enrolled into a proxy network by malware, whose owner has no idea their connection is being resold.

So behind a residential proxy address there is usually a real person who is not attacking you, and often does not know their line is being used. That is the whole reason blocking the address is the wrong move.

Why buying a proxy list does not fix it

The obvious answer is to buy a feed of known residential proxy addresses and block them. It fails for four reasons that compound.

The pools rotate faster than the lists. An address is in the pool for the duration of a session and then is not. By the time a feed lists it, the address may be back to being nothing but a family's broadband.

The lists are stale in the direction that hurts. A false positive on a recycled address blocks a real customer, and you will not hear about it — people who cannot check out do not file bug reports, they leave.

Coverage is a fraction. Estimates of pool sizes run to the tens of millions of addresses. No feed has all of them, and the ones it does have are the ones that were cheap to find.

You are still not answering the question. "Is this address in a proxy pool" is a different question from "is this session automated", and only the second one is what you actually want to know. A journalist on a privacy VPN and a scraper on a residential proxy can share an address; one of them should get through.

What survives the change

Everything that describes the session rather than the address.

Transport fingerprints. The proxy relays bytes; it does not rewrite the TLS handshake. Whatever client made the connection still announces its own ordered set of cipher suites, extensions and curves — the JA3 or JA3N hash. A scraping library behind a residential address still looks like a scraping library, and matching a real browser here means reproducing a whole crypto stack rather than editing a header.

Behaviour. A session that fills a form without the timing of typing, moves focus in a way a hand does not produce, or submits faster than a person could have read the page, is automated regardless of whose broadband it borrowed.

Rate across accounts, not across addresses. The signal in credential stuffing was never "many attempts from one address" — that stopped being true when rotation became cheap. It is "one attempt against each of four hundred accounts", which is visible only if something scores the actor rather than counting requests per address.

Consistency. A client claiming to be Safari on iOS while presenting a TLS fingerprint that no iOS build produces has contradicted itself, and the proxy does not help with that.

Reputation that is worth having

Address reputation is not useless after this change — it just has to be weighted correctly.

Weight by how shared the address is. An address that resolves to a residential ISP or a mobile carrier is likely shared, and a single bad session should move its reputation far less than the same session from a dedicated datacentre host. Getting this wrong is how you block a company because one person on their network ran a scraper.

Decay it. Reputation on a rotating pool must age out quickly, or you are punishing next month's owner of the address for last month's tenant.

Prefer cross-site signal for first contact. The first time an address appears on your site you have no history for it. If it ran a credential list against someone else's login last night, that is worth knowing — and it is the only thing that helps on the very first request.

Keep the human override. Whatever the scoring says, you need an allow list that outranks it, and you need to actually maintain it.

Where Karma sits

Karma scores the session — behavioural signals and TLS/HTTP2 fingerprints — and keeps address reputation as a weighted input rather than as the answer. Addresses that look shared are treated as shared, and reputation decays.

The opt-in shared pool covers the first-contact case: an address that behaved like a bot on another account's site is known before it reaches yours, which is exactly the moment a per-site blocklist has nothing to say.

The free Detect plan runs this with enforcement off, so you can see how much of your traffic arrives from residential space and what the verdicts say about it before you change anything.