Residential Proxy Detection: How It Works, Why It's Hard

1. The same IP serves real people and proxy traffic

The device hosting a proxy exit node keeps being someone's actual device. The SDK routes third-party traffic in the background while the owner streams, shops, and reads the news on the same connection. From the target website's side, both kinds of traffic arrive from one address with one clean history.

Cloudflare put a number on this while training its detection models: 4 out of 5 requests from residential proxy IPs came from legitimate, direct connections, not proxied ones. A reputation system that flags the IP and blocks everything from it gets exactly one decision right in five.

2. Exit nodes churn faster than lists update

A node exists while the app hosting the proxy SDK is running. Close the app and the exit vanishes; open it tomorrow and it returns, or the provider backfills the slot with a different device in another city. Providers advertise pools they claim reach 30 to 100 million residential and mobile IPs, rotated continuously.

Rate limiting collapses against that pool size. A credential-stuffing run can spread thousands of login attempts across thousands of addresses, each of which appears once, politely, and never again. Per-IP thresholds see nothing worth flagging.

3. CGNAT puts a crowd behind one address

Mobile networks and many fixed-line ISPs use carrier-grade NAT, which parks hundreds or thousands of subscribers behind a single public IP. If one phone behind that address runs a proxy SDK, the address earns a proxy history that every other subscriber inherits. Blocking it is collective punishment, and attackers know defenders hesitate.

4. Sold twice, reassigned tomorrow

The provider ecosystem itself muddies attribution. The same residential IP can appear in more than one provider's pool, which means one real device or connection may be sold, resold, or exposed through multiple proxy networks at the same time.

In our residential proxy data across major providers, shared IPs are a common pattern, not an edge case. On average, 44.1% of IPs across these providers are shared, meaning the same residential IP appears in more than one provider's pool.

In practical terms, this makes provider attribution, blocking, and risk scoring harder. If a security team blocks one provider's known pool, the same device may still reach the platform through another provider. If traffic spikes from multiple provider names but overlaps on the same IPs, the issue may not be several independent abuse sources; it may be the same underlying residential infrastructure being monetized through multiple networks.

Then the ground shifts again. ISPs reassign addresses as subscribers come and go, so yesterday's proxy exit node can become today's clean subscriber with a stale reputation attached. Detection data has to expire. An entry without a last-seen date is a false positive waiting to happen.

This is why freshness is not a nice-to-have in this field. A residential proxy list is a photograph of a crowd, and the crowd moves.

1. Provider enumeration and attribution

The most direct method is to do what attackers do: subscribe to residential proxy services, route traffic through them, and record which exit IPs the requests emerge from. Done continuously across many providers, this builds a map of who is selling which addresses, refreshed as pools rotate.

Attribution is the point, not just a yes/no flag. Knowing an IP surfaced through a specific provider three days ago supports targeted policy: throttle ranges tied to the network currently hammering your signup flow while leaving the rest alone. Our residential proxy dataset tracks 20 million entries this way, each carrying a provider name (GoProxies, Evomi Proxy, NetNut, anyIP, DataImpulse, and dozens more) and a last-seen date, updated daily.

2. Network-level signals

Connection fingerprints provide a deeper view of whether traffic has been relayed through a proxy. The TCP handshake exposes characteristics such as packet sizes, window values, and option ordering, which vary by operating system and network configuration.

When a session claims to come from a phone on home Wi-Fi but its handshake resembles a Linux server operating several networks away, that mismatch becomes a useful indicator. Connection fingerprints work best as a corroborating signal rather than standalone proof, since proxy architectures that terminate connections directly on the exit device can obscure or alter the original fingerprint.

3. IP context signals

Before any advanced analysis, cheap context filters a lot of noise. The ASN an address belongs to tells you whether it sits in consumer ISP space or hosting space, and the residential proxy vs datacenter proxy gap starts exactly there: datacenter ranges announce themselves in network registrations, residential proxy ranges do not. Checking whether an IP is residential or datacenter is the first cut every triage makes.

Geographic consistency adds another layer. An IP that geolocates to one country while the session's language, timezone, and billing address point somewhere else is not proof of proxying, but it stacks neatly with other signals.

4. What the session does

Behavior is the tiebreaker for addresses that look clean. Automated sessions tend toward metronomic request timing, narrow endpoint focus (login, checkout, signup), and geography that jumps cities mid-session. None of this is decisive alone, because power users and shared devices produce weird patterns too; behavioral signals modulate a score rather than set it.

5. Live connection analysis

Everything above leans on history, and history has a blind spot: the IP that joined a proxy pool an hour ago, or the clean household address that started relaying traffic this afternoon. Live analysis closes it by evaluating the connection in front of you, at request time, instead of asking what the address did last month.

Our real-time proxy and VPN detection runs network-level tests against the active session and returns a proxy score, VPN score, and confidence rating even when the IP has no recorded reputation at all. It also clears reassigned addresses that static tags would keep punishing, which cuts false positives from the reallocation problem above.

1. Batch scoring with a local database

For log analysis, traffic studies, and network-level screening, a local lookup beats an API call: no latency, no per-query cost. The Residential Proxy Database ships as CSV and MMDB (20M entries, updated daily), and the MMDB format answers lookups in microseconds. Field details are in the database documentation.

# Install the official reader first: pip install ipgeolocation-mmdb-reader
import os
from ipgeo_mmdb_reader.reader import IPGeolocationMMDBReader


def check_residential_proxy(ip_address: str) -> dict:
    """
    Check if an IP is a known residential proxy using
    ipgeolocation.io's Residential Proxy Database (MMDB format).
    """
    db_path = os.environ.get("RESIDENTIAL_PROXY_DB_PATH")
    if not db_path:
        raise ValueError("Set RESIDENTIAL_PROXY_DB_PATH environment variable")

    try:
        with IPGeolocationMMDBReader(db_path) as reader:
            result = reader.lookup(ip_address)

            if result is None:
                return {
                    "ip": ip_address,
                    "is_residential_proxy": False,
                    "provider": None,
                    "last_seen": None,
                }

            return {
                "ip": ip_address,
                "is_residential_proxy": True,
                "provider": result.get("proxy_provider", "Unknown"),
                "last_seen": result.get("last_seen"),
            }

    except FileNotFoundError:
        raise FileNotFoundError(f"Database file not found at {db_path}")
    except Exception as e:
        # Log the error; don't expose internal details to callers
        print(f"Residential proxy DB lookup failed for {ip_address}: {e}")
        return {
            "ip": ip_address,
            "is_residential_proxy": False,
            "provider": None,
            "last_seen": None,
            "error": "Lookup failed, treating as non-proxy",
        }

The provider field earns its keep in rules. If one network's ranges suddenly dominate your signup traffic, you can rate-limit that provider specifically instead of swinging at every residential IP in the region.

2. Per-request checks with the detection API

Login, checkout, and signup flows want richer signals at decision time. The Proxy & VPN Detection API returns proxy, VPN, Tor, and relay flags with provider names, confidence scores, and an overall threat score in a single v3 call; residential proxy detection is a core capability of it, not an add-on. A flagged response comes back like this (full security object):

{
    "ip": "100.0.12.2",
    "security": {
        "threat_score": 45,
        "is_tor": false,
        "is_proxy": true,
        "proxy_provider_names": [
            "Oxy Labs"
        ],
        "proxy_confidence_score": 99,
        "proxy_last_seen": "2026-07-17",
        "is_residential_proxy": true,
        "is_vpn": false,
        "vpn_provider_names": [],
        "vpn_confidence_score": 0,
        "vpn_last_seen": "",
        "is_relay": false,
        "relay_provider_name": "",
        "is_anonymous": true,
        "is_known_attacker": false,
        "is_bot": false,
        "is_spam": false,
        "is_cloud_provider": false,
        "cloud_provider_name": ""
    }
}

import logging
import os

import requests

logger = logging.getLogger(__name__)

API_URL = "https://api.ipgeolocation.io/v3/security"


def score_request_ip(ip_address: str) -> dict:
    """Check one IP against the Proxy & VPN Detection API and map it to a decision."""
    api_key = os.environ.get("IPGEO_API_KEY")
    if not api_key:
        raise ValueError("Set IPGEO_API_KEY; never hard-code API keys")

    try:
        response = requests.get(
            API_URL,
            params={"apiKey": api_key, "ip": ip_address},
            timeout=5,
        )
        response.raise_for_status()
        security = response.json().get("security") or {}
    except requests.exceptions.RequestException as exc:
        # Fail toward a challenge, not an outage: log it and let the
        # caller add friction while the lookup is unavailable.
        logger.error("Security lookup failed for %s: %s", ip_address, exc)
        return {"ip": ip_address, "decision": "challenge", "error": str(exc)}

    threat = security.get("threat_score") or 0
    confidence = security.get("proxy_confidence_score") or 0
    is_res_proxy = bool(security.get("is_residential_proxy"))

    # Residential proxy IPs also carry real household traffic, so a high
    # confidence score alone is not grounds for a block. Require corroborating
    # threat signals, and prefer friction over denial on shared address space.
    if is_res_proxy and confidence >= 90 and threat >= 80:
        decision = "block"
    elif is_res_proxy and confidence >= 50:
        decision = "challenge"
    elif threat >= 45:
        decision = "challenge"
    else:
        decision = "allow"

    return {
        "ip": ip_address,
        "decision": decision,
        "is_residential_proxy": is_res_proxy,
        "confidence": confidence,
        "threat_score": security.get("threat_score") or 0,
        "providers": security.get("proxy_provider_names") or [],
        "last_seen": security.get("proxy_last_seen"),
    }

For backfills and audits, the same data is available in bulk: the v3 bulk endpoint accepts up to 50,000 IPs per request on paid plans, which start at $19/month.

3. Decision bands, not binary blocks

The API's documented threat-score bands are a sane default: 1-19 allow with standard controls, 20-44 combine with other context, 45-79 add friction, 80-100 block or route to review. Layer the proxy confidence score on top: a 99 justifies a hard response on sensitive endpoints, while a 55 earns a CAPTCHA or step-up auth, not a ban.

Two cautions. On CGNAT and mobile ranges, prefer challenges over blocks even at high confidence, because one address is many people. And most residential proxy detection software will not tell you how it reaches a verdict; treat opacity as a smell. A vendor handing you a bare true/false has quietly chosen a false-positive rate on your behalf, and you should insist on the score instead.