A datacenter proxy is easy. The IP belongs to a hosting company, it appears on public lists, and any filter worth running blocks it before you finish reading this sentence.
A residential proxy is a different problem entirely. The traffic exits through a real home broadband connection — a real ISP, a real city, a real consumer subnet, often a real person's router. Every reputation check you can run comes back clean, because the IP genuinely is clean. The IP is not the fraud. The IP is a borrowed exit door.
This is the single hardest category in traffic filtering, and most of what is written about it either understates the difficulty or quietly implies a solved problem. Neither is honest.
Why your filter misses it
Almost every proxy defence in the wild is a lookup: take the IP, check it against a list, block on match. That model works for datacenter ranges because hosting IP space is published, stable and finite. It fails on residential proxies for three structural reasons:
- The address space is consumer space. Blocking it means blocking the ISP your actual buyers use. A list that flagged it aggressively would cost you more real customers than fraud.
- It rotates. Large pools cycle through addresses continuously. By the time an IP is characterised and listed, that exit has moved on and a fresh one is in play.
- The exit is genuinely residential. Geolocation, ASN classification and reputation scoring all agree it is a home connection — and they are all correct. They are simply answering a question that does not identify the fraud.
The consequence: a filter that scores IP reputation alone will pass proxy-routed bot traffic at close to a hundred percent, while feeling extremely confident about it.
The question that actually works
The breakthrough is to stop asking “is this IP bad?” and start asking “is this population behaving like a population of real households?”
A single visit through a residential proxy is close to indistinguishable from a real user, and we will not pretend otherwise. But a pool is not a single visit. Pools have statistical properties that households do not, and those properties survive rotation because they are consequences of the architecture rather than of any particular IP.
Real consumer traffic from a given network carries a characteristic mix — of connection types, address families, device populations, time-of-day distribution and geographic spread. Traffic that has been funnelled through a proxy layer and re-emitted carries a different mix, and the difference is measurable against that network's own clean baseline. That comparison is the core of what we run: an anomaly measured per source and per network, against how that same network normally behaves, rather than against a global list.
We are deliberately not publishing the specific signals, thresholds or feature set. Publishing them would hand a tuning guide to exactly the operators the system is built to catch, and the value of a behavioural signal is inversely proportional to how well the adversary understands it. What we will say is that the detection currently tracks a defined set of suspect network populations built from live traffic, and it is rebuilt continuously rather than shipped as a static list — because anything static is obsolete within weeks in this category.
What it looks like in production
Over a recent 24-hour window across live pop traffic, out of 25,430 filtered events, proxy-family detections accounted for 442 blocks from three independent layers operating on different evidence:
- A commercial proxy/VPN intelligence layer covering declared VPN, TOR, datacenter and public-proxy exits.
- A behavioural network-population layer built from our own traffic against per-network clean baselines.
- A VPN-network layer covering known consumer VPN infrastructure.
The important detail is not the total. It is that they are independent. Three layers reading different evidence means a pool that defeats one still has two to survive, and it means we can require corroboration before killing traffic rather than acting on a single weak signal.
The false-positive problem is the real problem
Anyone can raise a proxy catch rate. Set the thresholds hard enough and you will catch every proxy on earth — along with a large share of your genuine mobile audience, because carrier-grade NAT, IPv6 transition mechanisms and shared telco infrastructure produce signatures that look superficially proxy-like.
This is where we have spent the most engineering effort, and where the discipline matters more than the detection: we do not loosen proxy thresholds to recover volume, and we do not tighten them to improve a catch-rate number. Volume is recovered only by removing false positives on real humans — which means every aggressive rule needs an explicit carve-out for the legitimate cases that mimic it, and those carve-outs have to be re-validated against live traffic rather than assumed.
A vendor quoting a proxy catch rate without a false-positive rate is quoting half a metric. The half they left out is the half that costs you customers.
The limit nobody admits
Here is the part most vendors will not print, and it is the reason this article exists.
A single visit from a freshly rotated residential exit, used once and discarded, with a coherent device fingerprint, is not reliably detectable from server-side evidence alone. Not by us, not by anyone, at any price. The evidence needed to separate it from a real household simply is not present in one request.
What is detectable is the pool it came from, once that pool has produced enough traffic to differ statistically from the networks it hides in — and the zones that concentrate it. This is why serious proxy defence operates at the population and zone level rather than promising per-visit certainty. Anyone selling per-visit certainty on rotated residential traffic is selling confidence, not evidence.
We would rather tell you the boundary than let you discover it after you have bought.
What to do about it
- Stop treating IP reputation as proxy detection. A clean residential IP reputation is the expected result for this attack, not a reassurance.
- Judge at the zone and network level. Individual visits are noisy; populations are not. Evidence accumulates where the traffic concentrates.
- Require corroboration. Never kill on a single weak signal — the cost of a false positive on a real buyer is higher than the cost of one leaked bot.
- Re-validate carve-outs against live traffic. Mobile carrier infrastructure changes, and a rule that was safe last quarter can start eating real users.
- Demand the false-positive number. From any vendor, including us.
Related reading: what a residential proxy is and why filters miss it, invalid traffic explained for media buyers, and ghost traffic on pop and push.