PRO

Residential proxy detection: best practices

How to use IPHub's residential proxy detection well.

Who this is for: teams integrating, or considering upgrading to, IPHub's Professional plan for residential proxy detection. The integration specifics here refer to IPHub's API (the block field, the residentialProxy classifier).

The short version: residential proxy detection is a high-value but probabilistic signal. Treat it as input to a decision rather than the decision itself, and you will catch sophisticated fraud without burning legitimate users.

1. What the signal actually represents

A residential proxy hit (block=1 with residentialProxy=true) means the IP address has been observed acting as an exit node in a peer-to-peer (P2P) proxy network - typically a home broadband or mobile connection where a free app, browser extension, or bundled SDK is sharing bandwidth (often without the user fully understanding).

It does not mean:

  • The current request is fraudulent (a fraudster could be routing through that IP - or it could be the IP's actual owner).
  • Every device behind the IP is compromised. Most residential connections have multiple devices and users, and only one needs the proxy software for the IP to be flagged.

Used well, the signal lets you find sophisticated fraud that conventional VPN and datacenter detection isn't designed to catch. Used as a hard ban, it will occasionally lock out the proxy-runner's housemates, neighbours behind the same CGNAT, or the next user the carrier rotates that IP to.

2. block=1 vs block=2 for residential proxy

block=1 - Residential proxy

Recent, high-confidence observation - the IP was confirmed acting as a proxy exit node recently enough that we believe it still is. Treat as a strong signal.

block=2 - Possible residential proxy

Older observation. The IP was seen as a proxy in the past but has not been re-confirmed recently - it may have rotated away from the network. Treat as a soft signal.

The two-level system exists precisely so you can act on the signal at different confidence thresholds. Treat block=1 as a strong signal and block=2 as a soft one; section 4 below covers how to map these to concrete responses depending on the stakes of the action being protected.

3. Where false positives come from

Even a high-confidence residential proxy hit (block=1 with residentialProxy=true) is not a guarantee that the current request is fraudulent. The most common sources of legitimate-user collateral are:

  • CGNAT (Carrier-Grade NAT). Many ISPs - especially mobile carriers - share a single public IPv4 address across many subscribers. One subscriber running proxy software is enough to flag the shared IP for everyone behind it.
  • Mobile data. Mobile carrier IP pools rotate aggressively - an IP flagged minutes ago may now be assigned to a completely different subscriber.
  • Dynamic residential IPs. Many home ISPs reassign IPs on reconnection or after lease expiry. An IP confirmed as a proxy yesterday can belong to a different household today.

This is not a defect of the detection - it is a fundamental property of IP-based identity. The right response is not to abandon the signal but to use it proportionally.

This caveat is residential-proxy-specific. Non-residential block=1 verdicts (hosting, VPN, Tor, open proxy) are essentially binary - the IP belongs to that infrastructure or it doesn't.

4. Recommended response patterns

Pick the response that matches the cost of a false positive. At any tier, combining the signal with your own behavioural signals (velocity, device fingerprint, account age) gives a sharper outcome than acting on either alone.

Low stakes

Examples: browsing, content pages, signup landings.

Response: log only, no friction.

Medium stakes

Examples: account creation, login, password reset.

Response: apply friction - CAPTCHA, email verification, step-up auth, rate-limiting.

High stakes

Examples: payments, withdrawals, account changes.

Response: manual review, or require strong verification (3DS, ID check).

Survey research and panels

The cost calculus tilts toward stricter responses here - tainted data damages the dataset, but missing one respondent in a panel of thousands usually matters less. Combine the signal with the quality controls panels already use (attention checks, response-time outliers, straight-lining) rather than treating it as the sole exclusion criterion. Be more cautious about strict response policies if your panel skews mobile.

The combined approach (IPHub + attention checks) is well-established for IPHub's VPS/VPN detection - see Kennedy et al. (2020). Residential proxy detection is a newer IPHub feature without equivalent published research at the time of this writing; if you're piloting it, we'd love to hear what works.

5. Handling a user who reports being wrongly flagged

Sooner or later a customer will email you saying "I was blocked and I'm not using a proxy." A few things that help:

  • Take it seriously. They may well be correct - a housemate may have installed bandwidth-sharing software, their mobile carrier may have rotated them onto a flagged IP, or they may be behind CGNAT with a proxy-running neighbour.
  • Have a manual override path. A way to whitelist a specific account or session so a verified-legitimate user is not stuck waiting for the IP to clear.
  • Suggest they check their household. Free "VPN" or "proxy" apps - especially mobile ones - are a common cause. Uninstalling them stops the device from acting as an exit node; the IP will eventually drop out of the high-confidence detection.

6. Caching

Because residential proxy IPs rotate continuously, long cache TTLs work against you - you can hold a stale "is a proxy" verdict on an IP that has since been reassigned to a legitimate user, or vice versa. Cache for a short window such as a minute, or as low as 1-10 seconds for fraud-sensitive checks; for less sensitive use cases see the caching FAQ.

Related