iplogs.com

Residential vs datacenter IPs

Residential-proxy networks (Bright Data, Webshare, Oxylabs, IPRoyal, NetNut) sell access to real consumer broadband connections — so their traffic looks like a normal user to ASN-only detectors. Here's why ASN classification alone fails, and the additional signals that actually work.

Why simple ASN-based detection fails

A residential proxy exit is, by construction, a real consumer device on a real consumer ASN — Comcast, BT, Deutsche Telekom, Reliance Jio. The ASN of the exit IP tells you nothing. Most commercial detection vendors flag these as "clean" because they stop at the ASN check.

Detection has to come from somewhere else: the proxy backbone (the companies that aggregate the residential exits), behavioural anomalies (RTT mismatch, multiple geos for one user-agent), or published exit lists from the proxy vendors themselves.

Signals that actually work

  1. 1. Backbone IP reputation

    Residential-proxy vendors publish customer-facing IPs (the gateway clients hit before traffic is routed through the consumer device). Backbones we track: Webshare, Bright Data, IPRoyal, Oxylabs, NetNut, Smartproxy, Soax. A match here is ground-truth proof of residential-proxy use.

  2. 2. RTT mismatch (SNITCH)

    A residential proxy adds a hop between the client and your server. The TLS handshake RTT is significantly higher than the TCP RTT (the proxy is doing TLS termination on behalf of the user). The SNITCH research from NDSS 2025 formalises this — we run it as a standalone signal.

  3. 3. Geo / language mismatch

    A browser reporting Asia/Tokyo timezone from a Mexican residential IP is a strong proxy tell. Real users with travelling browsers are rare; coordinated mismatches suggest a proxy aggregator routing arbitrary clients through arbitrary exits.

  4. 4. JA3/JA4 fingerprint mismatch

    Residential-proxy SDKs can rewrite the TLS ClientHello as part of the relay process. The resulting JA4 doesn't match the fingerprint a stock browser would emit on the user's claimed OS/browser combination.

  5. 5. Velocity / behavioural anomalies

    One residential-proxy customer might rotate through hundreds of exits per minute. From your server's perspective: the same user-agent, the same session cookies, but a new IP every request. That's not a real user.

  6. 6. BGP single-homing for "residential" IPs

    Real consumer ISPs are multi-homed (multiple upstream peers). Some residential-proxy operators use small ASNs that are single-homed to one transit provider — a structural giveaway that the IP isn't true consumer broadband.

What this looks like in our API response

When residential-proxy use is detected, the response includes a residential_proxy_backbone signal in signals[], the backbone name in vpn_provider_sources[], and a verdict in the suspicious or vpn_likely bucket (depending on cross-source agreement).

{
  "verdict": "vpn_likely",
  "score": 0.62,
  "signals": [
    {
      "type": "residential_proxy_backbone",
      "weight": 0.40,
      "matched": true,
      "detail": "Listed as a Webshare residential gateway"
    }
  ],
  "ip_info": {
    "vpn_provider": "Webshare",
    "vpn_provider_sources": ["Webshare residential backbone"]
  }
}

Datacenter IP detection (the easier sibling problem)

Datacenter IPs are simpler to flag. The ASN is a hosting provider (AWS, GCP, OVH, DigitalOcean, Vultr), the PeeringDB classification is "Network Services" or "Content", and reverse DNS often gives it away (ec2-XX-XX-XX-XX.compute-1.amazonaws.com). We combine the X4BNet datacenter aggregator (41,735 CIDRs), PeeringDB classification, manual cloud-provider overrides, and ASN-level rules. False-positive rate on this layer is <1%.

Build VPN/proxy detection into your product: see implementation guide. Block at the edge: Cloudflare/Nginx/Stripe recipes.