How to tell if a proxy is ISP or datacenter comes down to two public records and one judgement. The records are the registry entry that names who holds the address and the routing entry that names which network announces it. The judgement is whether that holder and that network are a consumer internet provider or a hosting company. You can read both records for any address in a few minutes with curl and dig, which makes the vendor's label something you verify rather than something you accept.
This guide shows the lookups in order, runs them against a documentation address so the output shape is concrete, explains why commercial IP databases disagree, describes what the ProxyForge proxy checker reports and where it guesses, and ends with how to test a vendor's claim before you pay.
Why the distinction matters
An ISP proxy and a datacenter proxy differ in what a target can learn about the address, and that changes how the traffic is treated. A target that classifies traffic by network type sees a datacenter address as server traffic, because the registry and the routing table say so. An address whose block is held by a consumer provider and announced as part of an access network reads, to the same classification, as an ordinary subscriber range. That is the property an ISP proxy is sold on, and whether a given leased address has it depends on how the lease is arranged. Our comparison of residential, ISP and datacenter proxies covers when each is the right choice.
For a buyer two points matter:
- You are paying for a property. An ISP line is priced and sold on the expectation that targets classify the address as an access network. Whether a given address has that property depends on the arrangement behind it and on the target, so test it rather than infer it from a single record.
- Both kinds are legitimate. Datacenter addresses suit high-throughput collection, testing and allowlisted integrations. The failure to catch is a mismatch between label and record.
What an address's registry record shows
Every public IPv4 address sits inside a block recorded by one of the five regional internet registries. The record is served over RDAP, the registry protocol specified in RFC 9082. Three things in it matter here.
The holder. The entity with the registrant role is the organisation the block is registered to. For an address leased from a consumer ISP it depends on how the lease was recorded: the ISP, or the vendor if the block was reassigned to it. For a hosting company's own range it is the hosting company. A range sub-allocated to a customer usually appears as a more specific record naming the customer, with the upstream holder one level up in parentHandle.
The allocation type. The type field, where the registry fills it in, is the registry's own allocation category, such as a direct allocation or an assignment. It describes how the block was handed out, not what kind of network uses it. It never says ISP or hosting.
The block's extent and status. startAddress, endAddress and status tell you how large the block is and whether it is active.
Who announces the address is a separate fact, held in the global routing table.
Step by step: look up an address
The commands below take one IPv4 address. Replace the placeholder with an address from your own allocation.
Step 1: find the exit address
The address to test is the one a target sees, which is not always the one in your proxy list. Send a request through the proxy and read the answer. The ProxyForge echo endpoint behind the proxy checker returns JSON:
curl -s -x http://HOST:PORT --proxy-user USER:PASS https://api.proxyforge.io/tools/echo
The response carries ip, ipVersion, country, userAgent, checkedAt and two header fields, headers and revealing. Use the value of ip in the steps below. If it differs from the address in your list, the proxy exits somewhere other than where it listens, and the exit address is the one that counts.
Step 2: read the registry record
IP=203.0.113.10
curl -sL "https://rdap.arin.net/registry/ip/$IP" | jq '{
handle, name, type, status, startAddress, endAddress, parentHandle,
registrant: [.entities[]? | select(.roles | index("registrant"))
| {handle, name: ((.vcardArray[1][]? | select(.[0]=="fn") | .[3]) // null)}]
}'
ARIN answers for its own region and redirects other addresses to the right registry, so one endpoint covers the world; -L follows the redirect. The shape of the answer is stable across registries: a network object with a handle and name, a start and end address, a status list, and an entities array in which each entity has a roles list. The registrant's display name sits inside a vcardArray under fn, which is why the filter above digs for it. Registries fill fields unevenly, so expect null in places.
Step 3: find who announces it
The registry holder and the announcing network can differ, and the announcing network is the stronger signal for how traffic is classified. Team Cymru publishes origin data over DNS. Reverse the octets and query the origin.asn.cymru.com zone:
IP=203.0.113.10
dig +short "$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}').origin.asn.cymru.com" TXT
When the address is announced, the answer is one line of pipe-separated fields: the origin ASN, the announced prefix, a country code, the registry and an allocation date. When nothing announces it, the answer is empty. RIPEstat gives the same information as JSON, and an empty list of ASNs there means the same thing:
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=$IP" | jq '.data'
Step 4: name the ASN
With an ASN in hand, ask who operates it. The commands use AS64496, an ASN reserved for documentation, as a placeholder:
dig +short AS64496.asn.cymru.com TXT
That line returns the ASN, a country, the registry, an allocation date and the operator's name. Many operators also declare what kind of network they run in PeeringDB, whose network record has an info_type field with values such as Cable/DSL/ISP and Content:
curl -s "https://www.peeringdb.com/api/net?asn=64496" | jq '.data[0] | {asn, name, info_type}'
That field is declared by the operator, only operators who registered have one, and a hosting company can describe itself as it likes. Treat it as a hint that agrees or disagrees with the operator's name.
A worked example with a documentation address
203.0.113.0/24 is reserved for documentation, so it names no real holder and is safe to use for syntax. Running steps 2 to 4 against 203.0.113.10 gives a clean illustration of what each lookup returns, including what the empty cases look like.
| Lookup | What came back | What it means |
|---|---|---|
| RDAP registry record | A /24 block with status of reserved, a parentHandle pointing at the enclosing block, a type of null, and a registrant entity whose display name is the number-assignment authority |
The block is registered, to no commercial holder. The empty type shows that registries leave fields unfilled |
| Team Cymru origin query | An empty answer | No network announces the address |
| RIPEstat network info | An empty ASN list and an empty prefix | Same finding from a second source |
| PeeringDB, for the documentation ASN 64496 | An empty data list |
Absence of a PeeringDB record is common for real networks too and proves nothing |
For an address sold as ISP, the same four lookups may give a consumer provider as registrant, an ASN whose operator is that provider or a network it authorizes, and a declared type, if there is one, that fits an access network. Depending on the arrangement, any of these may name another party instead. A hosting company's address reads the same way with a different name throughout. Every one of these is a reading of names, which is where the judgement comes in.
Reading the result
Put the facts side by side and apply this table. The rules are heuristics: an ISP may be the holder, the announcer, both or neither, depending on the lease, so each reading is evidence to weigh, not proof of the product category.
| Registrant | Announcing ASN | Reading |
|---|---|---|
| Consumer ISP | Same ISP, or a network the ISP authorizes | Consistent with an access-network address |
| Hosting company or the proxy vendor | Same organisation | Consistent with a datacenter address; weigh it against the vendor's explanation of the arrangement |
| Consumer ISP | A hosting network with no stated relationship to the ISP | Weigh it with the vendor's own description of how the addresses are sourced; a mismatch with no explanation is a finding |
| Name you cannot identify | Unrelated to the registrant | Ask the vendor for the lease or registration before relying on the label |
The second row is the one to expect on a datacenter line. ProxyForge datacenter proxies are published as ranges registered to ProxyForge and announced from its own ASN, so a lookup on one of those addresses should show exactly that and we do not present it as residential. The ISP line is published as addresses leased from consumer ISPs and hosted on our racks. Both lines include a paid trial, so you can test addresses against your own targets before you commit to a term.
How IP-data databases classify an address, and why they disagree
Most targets do not run the lookups above on every request. They buy or build an IP-data feed that labels each address as residential, business, hosting, mobile or similar. The feeds are built from a mix of inputs:
- Registry names. Which organisation holds the block, matched against lists of hosting and access providers.
- Announcing network. The origin ASN and what is known about its operator.
- Active measurement. Scans and reverse DNS patterns that reveal server hardware, and latency or hop data that reveals where an address terminates.
- Observed traffic. How the address has behaved across the feed's own sightings, including whether many unrelated users share it.
- Reports and corrections. Submitted data from customers and from the operators themselves.
Each vendor weights these differently and refreshes on its own schedule. An ISP-leased address hosted in a facility is a genuine edge case: where the registry says access provider, the measurement can still say server rack. One feed follows the registry, another the measurement, and a third changes its mind after a refresh. So the same address can read as residential in one tool and hosting in another, and a label checked last month is not one to assume today.
An address therefore has several classifications, not one, so test against the sources your targets are likely to use rather than a single tool. Our guide to static residential proxies explains the same limit from the buying side.
What the ProxyForge proxy checker reports
The proxy checker shows what a website receives from the connection your browser is using. It reports four things: the exit address, the network that announces it, whether WebRTC exposes a second address, and any proxy-revealing headers. To check a proxy, route the browser through it, or use the curl command on the page, which prints the exit address and headers but not the network lookup.
The network line comes from a lookup on the exit address that your browser makes to ipapi.is. Without an API key, which is all a public page can use, that lookup returns the announcing ASN with its operator name and the company holding the address block. It does not return a network type or any datacenter, proxy or VPN flag. So the page classifies in two weak ways and says so:
- It checks the ASN against a short list of well-known hosting and cloud networks. A match is labelled a hosting network, as a guess.
- It matches the operator's and the holder's names against word patterns for hosting terms (such as hosting, cloud, server, colocation) and for access-provider terms (such as telecom, broadband, cable, mobile). A match is labelled a guess, hosting or internet provider.
If neither matches, the page answers "Can't tell", which is the right answer for a hosting company with a neutral name or an ISP whose name has no telecom word. The result is a heuristic from names. It does not read the registry record or consult the commercial databases that targets use. Use it for a fast first read and the lookups above for evidence.
Check a vendor's claim before you pay
A label becomes a claim you can test the moment a vendor lets you hold an address. Work through this before you commit to a term:
Ask how the addresses are sourced. Before ordering, ask the vendor, in writing, how the addresses are obtained and under what kind of agreement. Arrangements differ, so the answer tells you which differences between a label and a record are explained. A vendor that can answer in one sentence has thought about it.
Test a sample, not one address. Order a handful through a trial or a small first order. Run steps 1 to 4 on every address and keep the output.
Check the spread. List the addresses and count them per /24. This one-liner works on a file with one address per line:
cut -d. -f1-3 addresses.txt | sort | uniq -c | sort -rnProxyForge publishes a default cap of 64 addresses per /24 on its ISP line. Whatever the vendor publishes, the count tells you whether the allocation matches.
Compare label and record. Use the table in this guide. A mismatch is not proof of bad faith, but it needs an answer in writing.
Test against your own targets. The record is what a target could learn. How a target actually treats the address is only visible by sending it requests.
Repeat after replacement. A replaced address is a new address. Run the lookups on the replacement as well.
Our guide to verifying a provider's IP sourcing covers the questions a lookup cannot answer, and what IP provenance is explains the chain of custody. For the commercial side, see the checklist for buying ISP proxies.
Limits
- A lookup shows records, not behaviour. The registry and the routing table describe where an address is registered and announced. They do not say how a target will treat it.
- Records change. A prefix can be re-announced, sub-allocated or withdrawn.
- Names are not types. Deciding that an organisation is an ISP or a hosting company from its name is a judgement. The proxy checker makes that judgement mechanically and labels it a guess for that reason.
- The commands cover IPv4. The ISP and datacenter lines discussed here are IPv4. IPv6 lookups use different query forms.
- Lease legitimacy is a separate question. A lookup can show who an address is registered to. It does not show that the ISP agreed to the proxy use. That answer lives in the vendor's contracts and sourcing records, described on our sourcing page.
If you are weighing ISP against datacenter for a workload, the product pages for ISP proxies and datacenter proxies set out what each line includes, and the ISP and datacenter pricing pages list the published rates.