Why Residential IPs Get Flagged as Proxy or Hosting: How to Audit One

IP-intelligence vendors never see the device behind an address. They label the address from registry records, routing data, DNS names and behaviour they've observed. A "residential" IP gets flagged as proxy or hosting when one of those layers points to a datacenter. That can be the network that announces it, the specific /24 it sits in, its WHOIS organisation or reverse DNS, a mismatch between its registration country and where it geolocates, or a history of relaying proxy traffic. You can check every one of those layers yourself with free tools in about ten minutes per IP. This guide shows how.

Our explainer on IP reputation and fraud scoring covers how a score like IPQualityScore's is built and used by sites. This one is the practical companion: which classification signals produce the verdict, how four common vendors expose them, and a repeatable audit for a single IP or a sample of exit IPs.

Why an IP gets flagged as proxy or hosting

Most "hosting" or "proxy" verdicts on supposedly residential IPs come from five signals. Network ownership and routing come first, then names, then location consistency, then observed behaviour. Vendors combine them differently, which is why they disagree.

1. ASN type: who announces the address

Every routed IP is announced in BGP by an autonomous system (ASN). Vendors classify ASNs by the type of organisation behind them. IPinfo's ASN type is one of isp, hosting, business, education or government. PeeringDB, where networks describe themselves, has an info_types field. Its API returns ["Cable/DSL/ISP"] for Comcast (AS7922) and ["Content"] for Cloudflare (AS13335):

curl -s "https://www.peeringdb.com/api/net?asn=7922" | jq '.data[0] | {name, info_types}'

If the announcing ASN is a hosting company, almost every vendor will call the IP hosting, whoever the address is registered to. This is the most heavily weighted signal and the hardest to argue with.

2. The announced prefix, not just the ASN

When we've audited static "residential" or ISP IPs, the useful unit has often been the announced prefix, usually a /24, rather than the ASN. One /24 inside an otherwise clean ISP network can read as hosting while the rest of that ASN reads residential. The likely reason is that vendors correct their data at prefix level. A block that's been leased out, re-routed or seen hosting servers gets relabelled on its own, and the rest of the ASN keeps its label. A /24 is also the smallest IPv4 block that is generally accepted in the global routing table, so it's the natural unit for leasing and re-announcement. So when one IP is flagged, check its neighbours in the same /24 before you blame the whole provider or the whole ISP.

3. WHOIS organisation and reverse DNS

Registry records and PTR names are cheap signals, and vendors use them as tie-breakers. A netname or org containing words like "hosting", "cloud", "server" or "VPS", or a PTR like vps-123.example-host.net, pulls towards hosting. Residential ranges usually have ISP-style PTRs that encode the access technology or say "dynamic" or "pool". A missing PTR proves nothing either way. Plenty of ISPs don't populate reverse DNS, and plenty of hosting providers do.

4. Registry country vs geolocation country

A mismatch between the IP's registration country (from the regional internet registry, or RIR) and the country geolocation vendors place it in is one of the most common reasons we've seen for a "hosting" or "proxy" verdict on a static IP. Real home broadband rarely travels: a German ISP's customers are in Germany. Leased and re-announced blocks often do travel, with the registration staying with the original holder while the addresses are used elsewhere. Operators can declare where a prefix is really used with a self-published geofeed (RFC 8805), discoverable from WHOIS via RFC 9632. That moves the geolocation, but the registry mismatch stays visible to anyone who looks.

Here's a real example worth decoding: 1.1.1.1. Team Cymru's IP-to-ASN whois service (queried 2026-10-03) shows three different facts on one line:

$ whois -h whois.cymru.com " -v 1.1.1.1"
AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
13335   | 1.1.1.1          | 1.1.1.0/24          | AU | apnic    | 2011-08-11 | CLOUDFLARENET - Cloudflare, Inc., US

The block is registered in Australia through APNIC (it belongs to APNIC Labs). It's announced as a /24 by Cloudflare's ASN, which is registered in the US, and ip-api geolocates it to AU with hosting: true. For a resolver run jointly by APNIC and Cloudflare, that's all expected. On an IP sold to you as "residential US", the same three-way split would explain any hosting verdict.

5. Observed behaviour

The last layer is what vendors have seen the IP do: hitting honeypots, appearing in abuse feeds, running VPN or proxy software, or showing up as an exit of a known residential proxy network. This is the only layer that can flag a genuine home IP on a genuine ISP. IPinfo's residential proxy API returns the service an IP was seen in, with last_seen and percent_days_seen over a 7-day window. MaxMind defines is_residential_proxy as an IP that "is on a suspected anonymizing network and belongs to a residential ISP", with peer-to-peer proxy IPs explicitly excluded. Vendors draw that line in different places, but the point stands: a clean ASN doesn't protect an IP that's actually being used as a proxy.

How four vendors expose the verdict

Each vendor answers a slightly different question. Two "disagreeing" results are often both right. Field names below are from each vendor's current documentation.

AbuseIPDB adds one more label you'll often see: usageType, with values like "Data Center/Web Hosting/Transit" (docs).

ISP proxies: why they're a grey zone

"ISP" or "static residential" proxies are addresses registered to an ISP but routed to servers in a datacenter. They're a grey zone because the registry layer says residential while the routing and behaviour layers may not. Whether a given IP passes depends on which layers a vendor trusts most for that prefix.

The good version is an ISP announcing its own block from its own ASN with the servers on its network. There, the ASN type, WHOIS and geolocation all agree. The weaker version is an ISP-registered block announced by a hosting company's ASN, often after a lease. The registry still says "ISP", but the announcing ASN is hosting, which is the heaviest signal, and the registry country may not match the geolocation. Vendors catch up with these blocks prefix by prefix, which is why one /24 from a provider can be clean and the next flagged. Our ISP proxy explainer covers the product side. The audit below is how to tell which version you've been sold.

How to audit an IP yourself, step by step

Run the same five steps on every IP: get the exit IP, look up registration, look up routing, check DNS, then ask two or three vendors. Compare at the /24 level. Everything below works with free endpoints.

Step 1: get the real exit IP

Confirm which address the target actually sees. Don't trust a dashboard. For a proxy:

curl -s -x "http://USERNAME:PASSWORD@gate.proxyhat.com:8080" https://api.ipify.org

Our proxy checker does the same in a browser if you'd rather not script it.

Step 2: registration (RDAP, Team Cymru)

IP=1.1.1.1
# RDAP via the rdap.org redirector: registered range, holder, registry country
curl -sL "https://rdap.org/ip/$IP" | jq '{name, handle, country, type, startAddress, endAddress}'
# One-line summary: ASN, BGP prefix, registry CC, registry, AS name
whois -h whois.cymru.com " -v $IP"

Note the country and the holder name. For 1.1.1.1, RDAP returns "name": "APNIC-LABS", "country": "AU".

Step 3: routing (RIPEstat, bgp.he.net)

The RIPEstat Data API is free and keyless, and it covers address space from every RIR, not only RIPE's.

# Announcing ASN and the exact announced prefix
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=$IP" | jq '.data'
# Who holds that ASN, and is the prefix announced at all
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=$IP" | jq '.data | {resource, announced, asns}'
# Country from RIR delegation stats
curl -s "https://stat.ripe.net/data/rir-stats-country/data.json?resource=$IP" | jq '.data.located_resources'
# Every prefix the ASN announces, to see whether this /24 is an outlier
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS13335" | jq '.data.prefixes | length'

For a visual view, bgp.he.net shows the same ASN and prefix along with upstreams and peers. A small ASN with one or two transit providers that are hosting companies tells you a lot.

Step 4: reverse DNS

dig +short -x $IP

Step 5: two or three vendors, recorded side by side

# ip-api: free, no key, HTTP only
curl -s "http://ip-api.com/json/$IP?fields=status,countryCode,isp,org,as,reverse,mobile,proxy,hosting"
# IPinfo Lite: free with a token, country + ASN
curl -s "https://api.ipinfo.io/lite/$IP?token=$IPINFO_TOKEN"
# AbuseIPDB: free key, 1,000 checks/day
curl -sG https://api.abuseipdb.com/api/v2/check --data-urlencode "ipAddress=$IP" \
  -H "Key: $ABUSEIPDB_KEY" -H "Accept: application/json" | jq '.data | {usageType, isp, abuseConfidenceScore}'

Auditing a sample of exit IPs by prefix

For a pool rather than one IP, group the results by announced prefix. This script reads a file of IPs, uses ip-api's batch endpoint (up to 100 IPs per POST, 15 requests a minute on the free tier) and RIPEstat, and prints one line per prefix:

import json, sys, time, urllib.request
from collections import defaultdict

def get(url, data=None):
    req = urllib.request.Request(url, data=data, headers={
        "User-Agent": "ip-audit/1.0", "Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=20) as r:
        return json.load(r)

def ripestat(call, resource):
    return get(f"https://stat.ripe.net/data/{call}/data.json?resource={resource}")["data"]

ips = [l.strip() for l in open(sys.argv[1]) if l.strip()]

geo = {}
fields = "query,countryCode,isp,org,as,proxy,hosting,mobile"
for i in range(0, len(ips), 100):
    chunk = ips[i:i + 100]
    for row in get(f"http://ip-api.com/batch?fields={fields}", json.dumps(chunk).encode()):
        geo[row["query"]] = row
    time.sleep(4)  # stay under 15 batch requests/minute

by_prefix = defaultdict(list)
for ip in ips:
    net = ripestat("network-info", ip)
    reg = ripestat("rir-stats-country", ip)["located_resources"]
    reg_cc = reg[0]["location"] if reg else "?"
    by_prefix[(net["prefix"], ",".join(net["asns"]))].append((ip, reg_cc, geo.get(ip, {})))

for (prefix, asns), rows in sorted(by_prefix.items()):
    hosting = sum(1 for _, _, g in rows if g.get("hosting"))
    proxy = sum(1 for _, _, g in rows if g.get("proxy"))
    mismatch = sum(1 for _, cc, g in rows if g.get("countryCode") and cc != g["countryCode"])
    print(f"{prefix:<20} AS{asns:<8} n={len(rows):<3} hosting={hosting} proxy={proxy} "
          f"reg!=geo={mismatch}  isp={rows[0][2].get('isp', '?')}")

Run it as python3 audit.py exits.txt. For a large sample, add a short sleep between RIPEstat calls. The output usually tells the story right away. If the flagged IPs cluster in one or two prefixes, you have a prefix problem. If they're spread evenly across an ASN, the ASN is the problem. If they're scattered across many clean prefixes, it's behaviour: those IPs are known proxy exits.

How to read disagreement between vendors

When vendors disagree, work out which layer each one is reading before deciding who's "right". Usually one is reading registration and another is reading routing or behaviour.

• "ISP" in one, "hosting" in another. Registry versus routing. Check the announcing ASN. If it's a hosting company, the hosting verdict is the one sites will act on.
• Residential connection type plus a proxy flag. A real ISP address with observed proxy activity. Nothing about routing will fix it. It's a history problem.
• Clean everywhere except one vendor's fraud score. Usually recent abuse history or strictness settings. Check the vendor's abuse fields before writing the IP off.
• Different countries. Compare RIR country, geofeed and vendor geolocation. Vendors refresh at different speeds, so a recently moved block can disagree for a while.

What matters is which vendor the site you care about uses, and you usually can't know that. That's why one vendor's "clean" isn't enough evidence.

Signals at a glance

Vendors don't publish their weights. The "weight" column is our reading of their documentation and of how verdicts move during audits. Treat it as a guide, not a specification.

Static vs rotating residential vs mobile: what the audit means for your choice

Which product to buy depends on whether you need the same IP for a long time, and that decides how much an audit matters.

• Static / ISP IPs. You keep each IP for weeks, so audit before you commit. Run the prefix script on the IPs you're offered, reject flagged /24s and registry-geo mismatches, and ask which ASN announces them. This is where the audit pays off most.
• Rotating residential. Individual IPs come and go, so auditing one exit tells you little. Sample 100+ exits and look at the distribution of ASN types and hosting flags. A "residential" pool where many exits announce from hosting ASNs isn't residential.
• Mobile. Carrier ASNs and CGNAT make these the hardest to flag as hosting, but abuse history is shared with every real user behind the same address. Our mobile proxy guide covers the trade-offs, and residential vs datacenter vs mobile compares the three.

What this audit can't tell you

The audit explains why a vendor labels an IP the way it does. It doesn't predict whether a particular site will block you. Sites combine IP reputation with TLS, HTTP/2 and browser fingerprints, and with behaviour. A clean residential IP behind a datacenter-looking TLS fingerprint still gets challenged. The audit also can't see a vendor's private data, only the public layers that data is built on. Use it to reject bad IPs and to ask providers precise questions. Don't treat a clean result as a guarantee.