Types of Proxies: Datacenter, ISP, Residential, and Mobile Compared

"Proxy" is one word doing the work of at least four. A rented cloud server relaying scraper traffic and a stranger's smart TV relaying credential-stuffing attempts are both proxies, but they cost an attacker different amounts, hide behind different amounts of collateral damage, and demand completely different responses from you. Treating them as one category is how teams end up either blocking real customers or waving through industrial abuse. This is the working taxonomy, on both axes that matter.

Axis one: where the exit IP comes from

This is the axis that changes your decision, because it determines both what the address looks like in the registry and how much collateral damage a block causes.

Datacenter proxies

The exit is a server at a cloud or hosting provider. The address sits in address space whose ASN is classified as hosting, and the network was never intended to carry consumer traffic.

Datacenter proxies are cheap, fast, and available in enormous blocks, which is exactly why they are the easiest to catch. A consumer-facing login or checkout arriving from a datacenter or hosting range is automation until proven otherwise. Real customers do not shop from AWS. The economics are the whole story: a datacenter proxy costs cents, so attackers burn them freely and you can afford to treat them as a strong signal.

The honest exception is business traffic. Corporate VPN egress, security gateways, and enterprise SASE products legitimately exit from hosting-classified space. That is a real false-positive class in B2B products, and it is why connection type belongs in a score rather than in a hard rule.

ISP proxies (static residential)

The hybrid, and the one most people have never heard of. The IP address is registered to a consumer ISP, but the machine answering on it lives in a datacenter. Operators acquire or lease consumer-ISP address space and announce it from hosting infrastructure.

The result is a deliberate contradiction: datacenter speed, stability, and uptime, wearing consumer-ISP WHOIS records. A detection method that only reads the registry sees "Comcast" and moves on. Catching these means comparing what the registry claims against where the prefix is actually announced, what else lives in that range, and how the endpoint behaves under a direct probe. ISP proxies are the reason registry lookups alone are not a detection strategy.

Residential proxies

The exit is a real consumer connection in a real home. The address belongs to a legitimate ISP, geolocates to a plausible suburb, and looks exactly like a customer, because it is one. Someone else's.

That last part is the important part, and it is covered properly below. Residential proxies are expensive, usually sold by bandwidth rather than by address, and they are the default tool for serious abuse precisely because they defeat the signal that catches datacenter traffic. When your traffic fills up with them, the pattern is recognizable: see why so many residential proxies show up in your traffic and the fraud-side detection playbook.

Mobile proxies

The exit is a real cellular connection on a real carrier, and this is the hardest case, though not for the reason people assume. Mobile proxies are often quite detectable. The problem is what happens next.

Mobile networks sit behind carrier-grade NAT (RFC 6888), so a single public address can represent thousands of unrelated subscribers simultaneously. Block the address and you block a city block's worth of innocent customers. Attackers know this, which is why mobile proxies are marketed on their unblockability rather than their invisibility. The correct response is verification, not rejection, and the detection specifics are in how to detect mobile proxies.

The four compared

Read the last two columns together. Detectability and blockability are different problems, and the types get harder along different axes. Datacenter proxies are easy to spot and safe to block. Mobile proxies are often easy to spot and dangerous to block. Residential proxies are hard to spot and awkward to block. A single "is_proxy" boolean collapses all of that into nothing, which is why proxy type is the field that should actually drive your response.

Axis two: how the proxy speaks

The second axis is protocol, and it gets skipped in almost every "types of proxies" article, which then lists "HTTP proxy" and "residential proxy" as if they were alternatives. They are not. They are answers to different questions. A residential proxy speaks a protocol; SOCKS5 is a protocol that can run anywhere.

HTTP proxies understand HTTP. The client sends a full request to the proxy, which can read it, cache it, rewrite headers, and filter it. That makes HTTP proxies genuinely useful for corporate filtering and caching, and comparatively leaky for anyone trying to hide, since a careless HTTP proxy adds Via and X-Forwarded-For headers that announce its presence.

HTTPS tunnels use the CONNECT method (RFC 9110), which asks the proxy to open a raw TCP tunnel and stop interpreting. The proxy becomes a pipe, TLS runs end to end through it, and the proxy sees destinations but not content.

SOCKS5 (RFC 1928, March 1996) sits below the application layer entirely. It relays TCP and, unlike its predecessors, UDP, with support for authentication and both domain names and IPv6. It never inspects the payload and never adds headers.

For an attacker, SOCKS5 usually wins: protocol-agnostic, quiet, and it leaks nothing at the application layer. For a defender, that same property is an opportunity. A machine speaking SOCKS5 on an address that claims to be a residential broadband line is answering a question no home router should answer, which is why protocol handshakes are a stronger form of evidence than any list.

One more distinction worth keeping straight

Forward proxies act on behalf of the client and are what this whole post is about. Reverse proxies act on behalf of the server (every CDN and load balancer is one) and are not an anonymity tool at all. Transparent proxies intercept traffic without the client configuring anything, which is what a hotel or ISP captive portal does. Only the forward category is relevant to fraud, but the words get used interchangeably often enough to cause real confusion in incident reviews.

Where the residential supply actually comes from

This is the part that reframes the whole topic, and it is the reason "just block residential proxies" is a naive instruction.

Residential proxy networks need real homes, and real homes do not volunteer. The first serious academic look at this, Resident Evil (IEEE Symposium on Security and Privacy, 2019), infiltrated these networks and mapped over 6 million residential proxy IPs across more than 230 countries and 52,000 ISPs, documenting how the hosts were recruited and what ran through them.

The FBI restated the recruitment mechanics in plain language in a March 2026 public service announcement, naming five channels: SDKs embedded in mobile apps that pay developers per install, free VPN services that bury proxy enrollment in the terms, compromised IoT devices, malware bundled with pirated games and media, and passive-income schemes where users are paid to sell bandwidth. The device list is worth reading twice: TV streaming devices, digital picture frames, phones and tablets, routers, digital projectors, and aftermarket vehicle infotainment systems.

The scale this reaches when it works is not theoretical. The 911 S5 network, dismantled by the US Department of Justice in May 2024, had compromised more than 19 million unique IP addresses worldwide, over 600,000 of them in the United States, and was rented out for everything from fraud to far worse.

So when a residential proxy hits your login page, the address usually belongs to someone who has no idea. That is the argument against permanent hard blocks on residential proxy flags, and the argument for detecting anonymized traffic without blocking real customers.

Why plain IP reputation is losing to this

If your defense is a blocklist, the residential and mobile categories are built specifically to defeat it, and there is now measurement to prove it.

GreyNoise analyzed 4 billion sessions over a 90-day window from late November 2025 to late February 2026 and reported that 39% of unique IPs targeting the network edge came from home internet connections, while accounting for only 22% of sessions. The reason for that gap is the finding that matters: 78% of those residential IPs appeared in only one or two sessions and were never seen again. A reputation system cannot flag an address that is gone before the second request.

The volume trend points the same way. Infoblox found DNS traffic to proxy-related domains growing from roughly 300 billion queries per month in early 2025 to over 500 billion by April 2026, with more than 65% of its cloud customers connecting to residential proxy services at all, largely through ordinary apps rather than anything obviously malicious.

The conclusion is not that IP intelligence stopped working. It is that a static list of bad addresses stopped working, because the supply rotates faster than any list updates. What still works is classifying the address by what it is and how it behaves at the moment of the request: connection type, ASN type, protocol response, and freshness of classification.

Matching response to type

The practical payoff of the taxonomy is a graduated response instead of one blunt rule:

• Datacenter on a consumer action. Strong signal. Safe to block or sandbox on most consumer products. Carve out known corporate egress for B2B.
• ISP / static residential. Treat as datacenter once the behavior contradicts the registry. The registry alone will tell you it is residential.
• Residential. Weak alone, strong in company. Escalate on corroboration: velocity, mismatched geography, a new device on an old account. Prefer step-up verification over rejection, because the household is probably a victim.
• Mobile behind CGNAT. Never a hard block on the address alone. Dampen shared-IP velocity, verify the user, and lean on identity and device signals instead.
• Tor exit. A separate case with a published list and near-zero legitimate-commerce use, covered in detecting Tor traffic by IP.

The rule underneath all five: the proxy type sets how much weight the network signal carries, and something else always has to carry the rest.

How GeoIPHub answers it

One lookup returns both axes rather than a single boolean. The asn group gives you asn_type and connection_type, which separate residential, mobile, datacenter, and satellite origins and expose the ISP-proxy contradiction where the registry story and the announcement do not agree. The detection group returns the flags with their taxonomy attached: is_proxy alongside proxy_type, is_residential_proxy with a residential_proxy_score, is_vpn with the named vpn_provider, plus Tor and relay detection, so you can act on which kind of proxy it is rather than merely that one exists. Classification is confirmed with active protocol handshakes across 11 VPN and proxy protocols, which is how a SOCKS5 or OpenVPN responder gets caught sitting on consumer address space, and the methodology documents how that evidence is gathered. An is_cgnat flag marks the shared carrier addresses where blocking is unsafe, and the explainable 0-100 fraud score arrives with a recommended_action so the graduated response above becomes a field rather than a judgment call. Every field ships on the free tier at 1,500 lookups per day. You can test any address right now with the VPN detection test or the datacenter IP check.

Where to go next

This post is the map of the territory. The mechanics live next door: how VPN and proxy detection actually works is the pillar covering handshakes, feeds, and provider naming, how to detect mobile proxies handles the CGNAT case in depth, and residential proxy fraud detection covers the commercial side. When you are ready to turn all of it into decisions that do not cost you customers, start with detecting anonymized traffic without blocking real customers. Name the proxy type first. The right response follows from it.