How to detect residential proxies

Residential proxies run on real home and mobile IP addresses, so the usual tricks for spotting VPNs and datacenter proxies don't touch them. This is what does work, and how far it gets you.

Why residential proxies are uniquely hard

A residential proxy sends its traffic out through someone's real home or mobile connection. The IP address you see is registered to an ordinary consumer ISP - Comcast, Vodafone, a mobile carrier - the same as the connection of any other household.

That's the whole problem. VPNs and datacenter proxies are easy to flag because they run on servers in datacenters, and datacenter address ranges are registered to hosting companies and publicly catalogued - you can keep a list of them and match against it. A residential proxy runs on an address registered to a home ISP, exactly like every real customer of that ISP. Nothing in the registration data separates the proxy from the actual resident sitting next to it.

So detecting one means giving up on the registration data and asking a different question: has this address actually been seen working as a proxy? Everything below is some attempt to answer that.

Approach 1: Network classification

The cheapest check is a single API call against any IP-data provider: look up which company the address is registered to. Hosting and datacenter companies own well-known ranges, so flagging anything registered to one clears out the bulk of casual VPN and datacenter-proxy traffic in one step.

Where this approach hits a wall

This check looks up which company an address is registered to. A residential proxy runs on a normal home connection, registered to an ordinary ISP - the same as every real customer of that ISP. So the check just sees a normal home address, and nothing marks it as a proxy. It cannot tell a residential proxy apart from a real home user. These checks are still useful as a first step, but by themselves they miss every residential proxy in your traffic.

What IPHub's Basic plan covers

The Basic plan covers this baseline out of the box - VPN, Tor exit nodes, open proxies, and datacenter/hosting IP addresses, with ASN classifications largely hand-curated rather than auto-derived from registry data. It is the right tier if your traffic risk is dominated by datacenter-class proxies. Catching residential proxies on top of that needs the approach below.

Approach 2: Active P2P network monitoring

The only way to be sure an IP address is a residential proxy is to observe it working as one. In practice that means joining the peer-to-peer (P2P) proxy networks in order to determine their IP addresses. This flips the question the checks above ask - not who owns the address, but what it has actually been seen doing.

What this approach gets right

This is the only approach that can flag an IP address before the fraudster makes their first request to your site. Other signals - a failed payment, a suspicious login - only appear once the user is already inside, and by then some harm may already be done. An IP address check happens before any of that, so you can act earlier.

What it costs and where it's limited
  • You can only watch the networks you manage to join. If you cannot get into a network, you cannot see the IP addresses inside it.
  • The watching has to run all the time. These networks change their IP addresses very often, so a snapshot taken a while ago describes the past, not what is happening now.
  • Each result ages fast. An IP address seen very recently is a strong signal; one that hasn't been seen for a while may already have left the network - which is why stale residential proxy data is worse than none.
What IPHub's Professional plan covers

The Professional plan adds residential proxy detection on top of the Basic baseline, exposed as the residentialProxy classifier with confidence split into block=1 (recent, high-confidence) and block=2 (older, soft signal). The overview has the API-side picture; the best-practices guide covers integration.

The operational reality

Even with active monitoring, the signal is probabilistic, and a detection system has to acknowledge that in three places:

  • Confidence decay. A confirmation from today and a much older one are not the same signal. IPHub splits these into block=1 (recent, high-confidence) and block=2 (older, soft signal). See the overview's FAQ entry on block=2.
  • Shared-IP false positives. CGNAT, mobile carrier pools, and dynamic residential IP addresses all share an address across many subscribers. One subscriber running proxy software is enough to flag the shared IP for everyone behind it. The best-practices guide's section on false positives covers the patterns and how to keep legitimate users out of the blast radius.
  • Cache TTLs. Residential proxy IP addresses rotate continuously, so long cache windows let stale verdicts pile up. The caching section of the best-practices guide has concrete TTL guidance.

Detection is one input to a decision, not the decision itself. The right response to a flagged IP address depends on what action it's about to take - logging on a content page, friction on account creation, manual review on a payment - and the best-practices guide's response patterns map signal strength to response.

Frequently asked questions

Reliably enough to be useful, not perfectly. Active monitoring of P2P proxy networks produces a continuously updated list of confirmed exit nodes, but residential proxy IP addresses rotate, networks change, and any single IP carries some chance of being a false positive. The right framing is that detection gives you a high-value signal to combine with your own behavioural and account-level signals - not a verdict to act on alone.

A commercial VPN's exit IP addresses sit on hosting infrastructure owned by the VPN provider, so they're identifiable by ASN, hostname, and reputation data. A residential proxy's exit IP addresses are real residential ISP addresses, indistinguishable from any other home connection by ownership data. VPN detection is largely a list-and-attribute problem; residential proxy detection requires actively observing the proxy networks themselves.

In principle, yes. In practice, the operational lift is the hard part: you need to identify which P2P proxy networks matter for your traffic, get a client into each one, route traffic through them continuously, capture exit-node IP addresses, store and serve the resulting list with low-latency lookups, and keep the whole pipeline running as networks change.

For most teams, the cost of standing that up and keeping it healthy outweighs the cost of consuming a feed from a provider that already runs it. The same logic applies to most IP-reputation problems; residential proxies sit at the harder end of the spectrum.

Accuracy depends on the freshness of the underlying data and the structure of the IP. A high-confidence hit (IPHub returns this as block=1) means the IP was confirmed acting as a proxy recently enough to trust the verdict. Older observations come back as block=2 - still useful as a soft signal, but with the IP having had more time to rotate out. False positives concentrate on shared addresses (CGNAT, mobile carriers, dynamic residential IP addresses); the best-practices guide covers how to handle them.

Continuously. The exit-node population of any given P2P proxy network turns over constantly - new IP addresses join as users install bandwidth-sharing apps, others drop off as devices go offline or rotate addresses. Detection that runs against a static list goes stale fast; detection that consumes a continuously updated feed stays useful.

Related

Ready to look up an IP address?

Free lookups are available without an account. Residential proxy detection is included in the Professional plan.