Understanding Proxy Types

What a target site reads from your exit IP's registration, and why datacenter, residential, shared and rotating exits are treated so differently.

Every proxy performs the same mechanical job: your request goes to the proxy, the proxy forwards it, and the target sees the proxy's address instead of yours. The differences between proxy types (and the reason the prices differ by an order of magnitude) have almost nothing to do with the software. They come down to the identity of the exit address: which organization it is registered to, what kind of network announces it, and who else has been using it.

This article is the taxonomy. It explains what each type physically is and how a target site classifies it. If what you actually want is a procedure for picking one (which type for which job, when to pay more), that is a different question with a different article: choosing the right proxy type.

How does a website know what kind of IP you are using?

From public records, not from anything it can see in your request.

No IPv4 address is anonymous in the sense people casually assume. Every address is allocated through a regional internet registry to a named organization, and routes to it are announced by an autonomous system (an ASN) with a public number and a public name. All of this is queryable by anyone: whois on the command line, free lookup databases, and commercial feeds that enrich the raw registry data with classifications.

When your request arrives, a target can look up the source address before reading a single byte of your payload and learn: which ASN announces it, whether that organization is a hosting company or a consumer internet provider, which country the registration points to, and whether the address appears on any shared reputation list. This lookup is nearly free for the target (one query against a local database), which is precisely why it is the first filter that any site under automation pressure applies.

The single most consequential bit in that lookup is the distinction between a hosting ASN and an eyeball network. A hosting ASN (datacenter operators, cloud platforms, server rental companies) originates almost no ordinary human browsing. An eyeball network (the ASN of a consumer ISP) originates almost nothing else. A target that wants to separate people from programs gets enormous leverage from that one classification, and every proxy type below is really a position relative to it.

What is a datacenter proxy?

A datacenter proxy is an IP address assigned to a machine in a hosting facility, announced by a hosting ASN, with your traffic relayed through that machine.

Everything characteristic about the type follows from the physical reality. The machine sits on server-grade bandwidth, so throughput is high and stable. One machine can hold many addresses, so the addresses are inexpensive to operate at volume. And here is the part an honest taxonomy has to include: the registration data says exactly what it is. Commercial IP-intelligence databases label hosting ranges as hosting, and any target that subscribes to one knows within a millisecond of your TCP handshake that this request did not originate in somebody's living room.

Whether that matters depends entirely on the target. Most of the web does not check: public APIs, sites without bot pressure, price feeds, internal tooling, and the long tail of ordinary websites treat a datacenter visitor like any other, and for those the type's speed and low cost make it the sensible workhorse. Targets that face heavy automation (large marketplaces, social platforms, ticketing, travel search) commonly treat a hosting-ASN source as elevated risk: more challenges, tighter per-address limits, sometimes an outright block on the whole range. The datacenter proxies page describes what node4 operates in this category.

What is a residential proxy?

A residential proxy's exit is a device sitting on an ordinary broadband subscription: an address allocated by a consumer ISP to a household and announced by that ISP's eyeball ASN. The provider routes your traffic so that its final hop toward the target originates from that line.

Now the registry lookup returns an answer shaped like a subscriber, because the exit is a subscriber. The target cannot separate your request from its legitimate audience on registration data alone, which is the entire value of the category and the reason it commands a premium.

The physical reality imposes trade-offs that a spec sheet tends to gloss over. The addresses are borrowed rather than owned: pool membership shifts as the underlying devices connect and disconnect, so an individual exit has a limited and unpredictable lifetime. Each exit runs at consumer-line speed, not server speed, so throughput varies exit to exit. And commercially, residential access is metered by traffic volume rather than sold per address (the scarce resource is the consumer line itself, not the address count), which changes the economics of any workload that moves a lot of bytes. Delivery is through a gateway, described below, and geographic targeting rides in the username; country and city targeting covers that grammar. The residential proxies page covers the product side.

What is the difference between shared and private proxies?

Shared and private are not a third kind of network; they are an axis that cuts across the types above, and it exists because reputation systems attach history to the address, not to the account using it.

On a shared proxy, several customers exit through the same addresses. The cost of the address divides across those customers, which is why shared is the cheap end of every catalog, and the history divides the same way. A rate limit tripped by another tenant yesterday, a CAPTCHA farm someone ran last month, an abuse report filed against traffic you never sent: all of it accrues to the address, and your requests inherit the accumulated record the moment they exit through it. This is not a defect to be engineered away; it is the deal being offered, and it is a perfectly good deal against targets that do not keep per-address grudges. What shared proxies are and how they are packaged is on the shared proxies page.

On a private (dedicated) proxy, the address carries your traffic and nobody else's. The record is yours to build or to ruin, and a clean history stays clean for exactly as long as your own behavior keeps it that way. Privacy of history also matters wherever the target binds state to the address (logged-in sessions, carts, anything where the site remembers the IP), because an address that only ever presents one customer's behavior looks coherent in a way a ten-tenant address cannot.

What is the difference between a static proxy and a gateway?

How the product reaches you. A static endpoint is an address you connect to directly; a gateway is one hostname that picks an exit for you on each connection.

The third axis is how the product is delivered to you, and it is easy to conflate with rotation itself.

A static endpoint is a specific address you hold. The dashboard lists a host and port for each one, and every request you send through that endpoint exits from that same address. The address is the product: it appears in your configuration, you can whitelist it with third parties, and the target watches it accumulate your entire history.

A gateway is a single fixed hostname standing in front of a pool. You configure one endpoint and never change it; the gateway chooses the actual exit for each connection. This is how rotation is packaged (fresh exits without you managing an address list), and it is also how residential access is packaged, since the underlying pool is in constant flux and a fixed per-address product could not be honest about that. When a workload needs the same exit across several consecutive requests, gateways offer session pinning, covered in sticky versus rotating sessions. The rotating products node4 runs on this model are described on the rotating proxies page.

The classification consequence is worth stating plainly: a static endpoint concentrates your history onto one address a target can profile; a gateway spreads it thinly across a pool. Which of those is desirable depends on the workload, not on any inherent ranking.

Mobile, for completeness

You will meet a fourth category elsewhere: mobile proxies, whose exits sit on cellular carrier networks. Their distinguishing property is carrier-grade NAT: carriers place very large numbers of subscribers behind each public address, so a target that blocks one risks blocking a crowd of genuine customers, and targets calibrate accordingly. That mechanism, not anything magical about phones, is what the category trades on. It is described here only so the label is not mysterious when you encounter it; this taxonomy otherwise leaves it aside.

How a target combines all of this

Real defenses are layered, and the layers map neatly onto what this article has covered.

The first layer is the registration lookup: ASN, hosting-versus-eyeball, country. It is static, cheap, and decided before your request is even read. Your proxy type is essentially your position at this layer.

The second layer is per-address reputation: shared feeds and the target's own memory of what each address has done. The shared-versus-private axis lives here, and so does the static-versus-gateway one, because both determine what history an address carries into the next request.

The third layer is behavioral, and no proxy type addresses it at all: request rate, header consistency, TLS fingerprint, the timing texture of the traffic. A residential exit issuing forty requests per second is still unmistakably a program. Buying a better position at layers one and two buys nothing at layer three. That is why the type question is necessary but never sufficient, and why why is my IP getting blocked is the companion piece to this one.

Where this leaves you

You now have the map: registration determines how an address is classified, tenancy determines what history it carries, and delivery mechanism determines how that history is distributed. None of that tells you what to buy; that requires knowing what your specific target checks, and it deserves the evidence-driven treatment in choosing the right proxy type. If you would rather establish a working baseline first and reason about types afterwards, the quick start guide gets a first verified request through in about ten minutes.