Datacenter proxies

A datacenter proxy exits from an address that a hosting company or cloud platform holds in its own name, in a rack, on a short and stable path. It is the right purchase for anyone whose target does not care where the request came from — a far larger share of targets than the market for expensive proxies suggests.

The registration is the category

Nothing about the packets identifies a datacenter proxy. The address does. Every public address sits inside a block allocated by a regional internet registry to a named organisation, and that allocation is published, queryable and free to read. A defence needs no behaviour, no timing and no fingerprint to know what it is talking to. It needs one lookup, which finishes before your first byte of application data arrives.

Two things follow, both counter-intuitive if you think of proxies as disguise.

• Rotating within the range buys nothing. A replacement address drawn from the same allocation carries the same registration, so rotation changes the identity and not the classification.
• Good behaviour does not earn a reprieve. If the decision was made on the network record, a perfectly ordinary request is refused as fast as an abusive one.

You can read the same record the defence reads. WHOIS is the older interface, specified in RFC 3912 and answering on TCP port 43; RDAP is the structured successor, with its query format in RFC 9082 and the rules for finding the right registry in RFC 9224.

# Who holds this address? IP is one you were sold.
whois "$IP" | grep -iE 'orgname|netname|org-name|descr'

# The same in JSON. -L matters: the bootstrap answers with a redirect
# to the responsible registry, and without it you get an empty body.
curl -sL "https://rdap.org/ip/$IP" | python3 -m json.tool | head -40

If the holder is a hosting company, the address is a datacenter address whatever the invoice calls it. See ASN for how that record turns into a classification.

Why it is billed per address

The supply side is a server and an allocation, both of which the provider keeps. Bandwidth in a datacentre is the cheap part and the address is the durable part, so the address is the unit you rent, usually monthly and usually with traffic unmetered or generously capped. That is the mirror image of residential, where the address is transient and the bytes are the cost — and it is why heavy transfer is affordable here and ruinous there.

What you are really buying is diversity. A block of addresses in one /24 is one reputation wearing many hats: a service that classifies the range removes every address you hold at once. Ask how many distinct subnets and networks the allocation spans before you ask how many addresses it holds.

Shared and dedicated matter for the same reason. On a shared address your reputation is the sum of strangers' behaviour, and you never see what they did. On a dedicated one the history is yours, so behaviour becomes a variable you control.

Where the registration does not matter

Situation	Does the hosting registration hurt?	Why
An API where you authenticate with a key	No	The service already knows who you are
Uptime and availability monitoring	No	You want a consistent vantage point
Systems you own or are testing	No	Nothing is classifying you
Bulk transfer of large files	No	Unmetered traffic on a short path is the point
Targets with no bot defence at all	No	Common, and cheap to establish first
Consumer sites with commercial filtering	Yes	Classified before any behaviour is seen
Account work needing a plausible home line	Yes	A hosting address contradicts the story
Anything you were already blocked on at the network layer	Yes	Another address in the same class repeats it

The first five rows are why the category persists. The mistake is to read a block on one target as a verdict on all of them, and to move an entire estate onto a metered plan to fix one site. The comparison guide gives the order to test in; if what you need is a stable, exclusive address with a consumer registration, that is an ISP proxy.

Verifying what you bought

This is one of the few purchases here you can audit before using it, because everything defining the category is public. Take the addresses you were given and check who holds them, how many independent subnets they span, and whether your targets already refuse them.

# Distinct /24s across the list
cut -d. -f1-3 ips.txt | sort -u | wc -l

# Distinct announcing networks
while read -r ip; do
  whois -h whois.cymru.com " -v $ip" | tail -1
done < ips.txt | awk -F'|' '{print $1}' | sort -u | wc -l

Then test rather than speculate: request a page whose content you can predict through each address, and compare. One failing address is noise; a whole subnet failing together is classification, not luck. Record the exit address with every result, because without it you cannot separate a bad address from a bad target.

What to ask before you buy

• How many distinct subnets and networks does this allocation cover? Address count alone predicts nothing.
• Shared or dedicated, and if shared, how many customers per address?
• What was this address used for before me? Ask whether addresses are quarantined between customers.
• Is traffic genuinely unmetered, or capped? Find the cap before planning bulk transfer around it.
• Are replacements free when an address turns out to be classified, and on what evidence?
• Which country is the registration in, and which the hardware? They differ often, and geo-targeting databases follow neither reliably.
• Which authentication model is supported? Address allow-listing breaks silently when your own address changes; credentials travel but leak into logs.

What we do not publish about this category

No prices, no speeds, no success rates and no counts of available addresses. Price per address is the most volatile number in this market and belongs beside a dated price list, not in a reference page. Throughput depends on your route to the datacentre, the destination's capacity and the time of day, so a figure from our vantage point says nothing about yours. A success rate here is a statement about the targets tested, not about the proxies.

What you can do instead is unusually easy here, because the evidence is public. Run the WHOIS and RDAP lookups above on a sample before you commit, measure throughput from the machine that will do the work, and use the tools to confirm what the far end sees.