DEV Community: zihuama

IP Reputation Scores Disagree. We Tested 8 IPs on 4 Free APIs

zihuama — Thu, 08 Oct 2026 01:03:39 +0000

Tested 2026-10-08. Every number on this page was produced by a live request made the same day,
not pulled from a datasheet. You can re-run all of them — links and endpoints included.

Why we did this

People ask "what's the reputation of this IP?" expecting one answer. There isn't one.

We run a free IP check at PureIP, and the single most common misunderstanding
isn't "is the score right" — it's "what is the score even measuring." So we took 8 IPs
and asked 4 free, no-signup IP reputation services the same question on the same morning,
and wrote down what came back.

The 8 test IPs

We picked addresses where the "right" answer is not obvious, plus a few where it is:

IP	What it is
`8.8.8.8`	Google Public DNS
`1.1.1.1`	Cloudflare DNS
`9.9.9.9`	Quad9 DNS
`185.220.101.1`	A known Tor exit
`104.131.0.1`	DigitalOcean host
`23.94.7.1`	HostPapa host, flagged abuser
`45.83.220.1`	A host with a VPN flag
`45.155.205.233`	A host PureIP flags as abuser

Two reserved-documentation addresses (198.51.100.1, 203.0.113.5) returned
HTTP 400 from PureIP's own endpoint — a real behaviour worth knowing if you test with them.

The four APIs, and what each one returned

1. PureIP `/api/ip/health` — the "trust score"

GET https://pureip.app/api/ip/health?ip=8.8.8.8 — free, no key, no signup.

IP	score	status	datacenter	vpn	tor	abuser
`8.8.8.8`	63	moderate	✓
`1.1.1.1`	41	poor	✓
`9.9.9.9`	75	good	✓
`185.220.101.1`	40	poor			✓	✓
`104.131.0.1`	76	good	✓
`23.94.7.1`	35	poor	✓			✓
`45.83.220.1`	54	moderate	✓	✓
`45.155.205.233`	69	moderate	✓			✓

Important — this is not our own scoring. The number comes from our upstream data provider
ip.net.coffee as trust_score, and we pass it through unchanged.
Our codebase says so outright:

评分本身来自上游 trust_score（0-100），我们不重新算分——只解释它。
("The score comes from the upstream trust_score; we don't recompute it — we only explain it.")

We add the breakdown (network type, anonymity, reputation, ASN neighbourhood) so the number
is auditable rather than opaque. That distinction matters for the next section.

2. Scamalytics — the "fraud score"

Free per-IP page, no signup: https://scamalytics.com/ip/8.8.8.8

IP	fraud score	risk
`8.8.8.8`	0	Low
`1.1.1.1`	0	Low
`9.9.9.9`	0	Low
`185.220.101.1`	50	Medium
`104.131.0.1`	50	Medium
`23.94.7.1`	33	Medium
`45.83.220.1`	4	Low
`45.155.205.233`	0	Low

3. ip-api.com — the boolean flags

Free tier, no key: http://ip-api.com/json/8.8.8.8?fields=status,proxy,hosting

IP	proxy	hosting
`8.8.8.8`	true	true
`1.1.1.1`	false	true
`9.9.9.9`	false	true
`185.220.101.1`	true	true
`104.131.0.1`	false	true
`23.94.7.1`	false	true
`45.83.220.1`	true	true
`45.155.205.233`	false	true

4. ipwho.is — the one with no risk data at all

Free, no key: https://ipwho.is/8.8.8.8

Every one of the 8 IPs returned success: true with geolocation and ISP, and
vpn: null, proxy: null, tor: null for all of them.

That is not a bug in our test. The free tier of ipwho.is returns no risk fields at all.
If you built an "is this a proxy" check on it, you would get "no" for everything,
including the Tor exit.

The three disagreements

Disagreement 1: Is `8.8.8.8` a proxy?

ip-api.com: proxy: true
PureIP / Scamalytics: no proxy flag, fraud score 0

8.8.8.8 is Google's public DNS resolver. It is not a proxy in any sense a buyer of
fraud-detection cares about. We don't know why ip-api flags it — we only report that it does,
and that the other two don't. If you block on ip-api's proxy field you will block Google DNS.

Disagreement 2: `45.155.205.233` — clean or abuser?

Scamalytics: fraud score 0, risk Low
PureIP: score 69, status moderate, flagged abuser

One service calls it clean, the other flags it for abuse. We checked the upstream record directly:

GET https://ip.net.coffee/api/ip/lookup/45.155.205.233

The response carries is_abuser: true with an abuser_score label, alongside the trust_score.
So PureIP's flag is upstream data, not something we invented. But we can't tell you which
service is right — we can only show you that they disagree and tell you where each number
came from.

Disagreement 3: the scores aren't correlated at all

PureIP's trust score (higher = better) versus Scamalytics' fraud score (higher = worse),
across the 8 IPs:

IP	PureIP trust	Scamalytics fraud
`8.8.8.8`	63	0
`1.1.1.1`	41	0
`9.9.9.9`	75	0
`185.220.101.1`	40	50
`45.155.205.233`	69	0
`104.131.0.1`	76	50
`23.94.7.1`	35	33
`45.83.220.1`	54	4

Rank correlation (Spearman ρ) between the two: -0.05.

That is not a difference of opinion. That is two instruments measuring different things.
And it is exactly what you should expect: one is a trust score (would a normal person be
behind this IP), the other is a fraud score (has this IP been seen doing something bad).
A public DNS resolver scores poorly on trust-with-a-human-behind-it and perfectly on
never-committed-fraud. Both answers are correct answers to different questions.

We are not going to dress this up as "our score is better." It isn't a contest —
the number alone tells you nothing until you know which question it answers.
With n=8 this correlation is illustrative, not statistical. Re-run it yourself if you need more.

What to actually do about it

Before you block on a score, find out which question it answers.
Trust, fraud risk, proxy-detection, and abuse-history are four different axes.
A vendor that gives you one number without saying which is selling opacity.
Ask for the breakdown, not the number. The reason PureIP publishes
network type / anonymity / reputation / ASN neighbourhood alongside the score is that
the number is meaningless without them. Any vendor worth using will show you the components.
Test against IPs you already know the answer to. We knew 185.220.101.1 was a Tor
exit before we started. That's how you catch a service that returns "clean" for everything.
Never build a proxy check on a tier that returns null for risk fields.
ipwho.is gave us vpn: null 8 times out of 8. Absent data is not "no."

Re-run it yourself

Every endpoint here needs no account and no key:

# PureIP trust score + flags
curl "https://pureip.app/api/ip/health?ip=8.8.8.8"

# Upstream record PureIP's score comes from (includes ai_verdict)
curl "https://ip.net.coffee/api/ip/lookup/8.8.8.8"

# Scamalytics fraud score (HTML page)
curl "https://scamalytics.com/ip/8.8.8.8"

# ip-api boolean flags
curl "http://ip-api.com/json/8.8.8.8?fields=status,proxy,hosting"

# ipwho.is — check the risk fields before you trust them
curl "https://ipwho.is/8.8.8.8"

Method and limits

8 IPs, 4 services, all requests made 2026-10-08 from one machine.
n=8 is small. The disagreements are real and reproducible; the correlation is illustrative only. Do not quote ρ = -0.05 as a finding about these services generally.
Scamalytics figures were read from the public HTML page, not an API — a scraping artefact is possible, though the "Fraud Score: N" values are in the rendered page body.
ip-api's free tier is rate-limited (45/minute); we paced requests and got success on all 8.
We did not test paid tiers, and we did not test detection accuracy against a ground-truth set. This is a comparison of what each free tier returns, not of which one is more correct.

Built with PureIP — free IP, network and AI-platform checks,
no signup. Every number above is reproducible from the commands in this page.

My soft-404 bug was real. My 'Bing indexed zero pages' claim was not.

zihuama — Wed, 07 Oct 2026 06:38:59 +0000

Correction (originally published as "Bing indexed 0 pages of a 133-page site"). The bug I describe below is real and the fix is verified. The headline conclusion was wrong, and the diagnostic I recommended was invalid. Both are corrected here, in place, with the evidence.

What was actually broken

pureip.app is an IP diagnostics toolbox: Cloudflare Workers plus a single-page app. This line in wrangler.toml:

[assets]
not_found_handling = "single-page-application"

is the standard Workers SPA setting. It returns index.html with status 200 for any unmatched path. So:

/wp-admin                  → 200 (returns the homepage)
/this-page-does-not-exist  → 200 (returns the homepage)
/phpmyadmin                → 200 (returns the homepage)
/anything-you-type         → 200 (returns the homepage)

An unlimited supply of identical 200-status pages, from a crawler's point of view. That was a real defect and it is now fixed: those paths return 404. Verified against the live site, not from memory:

/wp-admin                   → 404
/phpmyadmin                 → 404
/this-does-not-exist-12345  → 404
/ip                         → 200
/guides                     → 200
/                           → 200

The fix is a top-level path allowlist in the Worker; anything not on it gets a real 404:

const KNOWN_TOP = new Set(["", "ai", "ai-check", "ai-unlock", "all", "api",
  "articles", "assets", "browser", "cdn", "claude", "compare", /* ... 45 segments */]);
if (!/\.[a-z0-9]{1,5}$/i.test(P) && !KNOWN_TOP.has(P.split("/")[1].toLowerCase())) {
  return new Response("Not found", { status: 404 });
}

The hard part is completing the allowlist. Miss one legitimate path and you de-index pages that were already indexed. I cross-checked five sources: the full sitemap (134 URLs across 8 sitemaps, all HTTP 200), the site's own /all index page, the App.tsx route table, legacyRoutes (22 entries), and the path prefixes the Worker handles itself. Then a two-way regression, re-run for this correction: 151 / 151 legitimate paths return 200 (the sitemap union plus the route table) and 19 / 19 junk paths return 404.

The conclusion that was wrong

I claimed Bing had indexed zero pages of 134, and that the soft 404 was why. Then I recommended a diagnostic for other people to use:

Run a Bing site: query. If it returns unrelated domains, that means no page from your domain is in the index at all.

That diagnostic is invalid, and I can prove it with a control I should have run the first time. Running site:cloudflare.com the same way returned pages from arsenal.com — a football club. Cloudflare is one of the most thoroughly indexed domains on the web. If the operator returns unrelated domains for site:cloudflare.com, then "unrelated domains came back" tells you nothing about any domain's indexing status.

The site: operator was returning filler, not a filter result. What I read as evidence of absence was evidence of a broken tool.

Repeated measurements made the failure mode clearer. The same query, minutes apart, returned three completely different things: unrelated domains, then a full page of results, then nothing at all. And the "nothing at all" state applied to control queries too — site:cloudflare.com and site:stripe.com both returned zero results at the same moment site:pureip.app did. When your control goes to zero, the measurement is broken, not the thing you are measuring.

What I actually know now

Via DuckDuckGo, which serves Bing's index, I got a clean reading once:

site:pureip.app → 7 results
  pureip.app/research/ip-audit-2026-09/en/
  pureip.app/research/vps-audit-2026-09/en/
  pureip.app
  pureip.app/ai-unlock
  pureip.app/guides/alibaba-cloud-ip-check
  pureip.app/guides/greencloudvps-ip-check
  pureip.app/guides/bandwagonhost-ip-check

So Bing had indexed this domain. Not zero. I could not repeat that measurement afterwards — every endpoint degraded into rate-limited empty responses — so I cannot tell you the number, and I am not going to guess it. The honest state of knowledge is: more than zero, less than everything, and I have no reliable instrument for the exact figure from this environment.

The genuinely useful takeaway is smaller and more boring than the original post implied. I found a real soft-404 defect, fixed it, and verified the fix on both sides. I did not establish that Bing was refusing the domain, and I should not have said I had.

Why this happens

Scraped search results are the worst possible instrument for an indexing decision, because the failure mode is silent and looks exactly like the answer you were hoping for.

A blocked or throttled endpoint returns an empty result set. Regex-counting a scraped SERP reports "0 indexed" whenever the HTML changes, the request is throttled, or a bot check appears. It never reports "I don't know."
site: is not a lookup, it is a query. It goes through ranking and can be ignored, substituted, or filled with unrelated results under load.
Datacenter IPs get a degraded internet. Google served this machine's requests a stripped page with no result count and no result titles. Bing served local shopping results for commercial queries and unrelated domains for site: queries.
Absence of evidence reads as evidence of absence when the thing you are measuring is a count that can legitimately be zero.

Always run a positive control. Query a domain you know is indexed, with the identical code path, in the same minute. If the control fails, you have measured nothing. I skipped this and published a number.

Reusable lessons

1. A control is not optional when the expected answer is zero. If your instrument can silently return "0", you cannot distinguish a real zero from a broken instrument without a known-positive comparison.

2. Never publish an indexing number you cannot reproduce. I had one reading and a large pile of unreliable ones. That is not a measurement, and the headline should not have carried it.

3. "All checks pass" is still a clue. robots.txt clean, sitemaps 200, crawler visiting daily, submission returning 200 — if those are all green and coverage looks bad, your measurement deserves re-checking before your infrastructure does.

4. Fix both directions. Verifying "junk now 404s" is not enough. Killing a legitimate page costs more than the junk was worth. 151 legitimate paths verified 200, zero collateral damage.

5. Wait for propagation. During edge rollout the same path alternates between 200 and 404. Do not conclude anything from a single probe.

Bugs fixed along the way

Legacy status pages were being killed. /gpt/status.html and /claude/status.html are legitimate old links in legacyRoutes that should 301 to /status/openai. Because they carry an .html extension, the earlier extension rule 404-ed them. After the fix the suite is 142 pass / 0 fail (re-run to confirm).

A brittle assertion. One test read tree.props.children[1].props.children[0].length. A later change added a <HomePageSearch /> component which took over children[1], shifting every index. The functionality was fine — the test was positional. Rewritten to find nodes by predicate, plus the missing negative case:

assert.equal(merged, 1,   "same IP should collapse to 1 card");
assert.equal(distinct, 2, "different IPs should produce 2 cards");

The old test only verified "same IP merges". It never verified "different IPs produce two cards", so if deduplication had swallowed everything it would still have passed. Mutation-tested after the rewrite: delete the dedupe line and the assertion fails immediately.

Tool: PureIP — check an IP before you buy a VPS: datacenter vs residential, blocklists, reverse DNS, AI-service reachability. Free, no signup.

Every figure in this post was re-measured against the live site and the local source tree on the date of this correction. The Bing indexing figure is the one thing I could not re-measure, and it is labelled as such rather than stated.

Two Chinese cloud providers have the same broken IP metadata. One is 6x more likely to be blacklisted.

zihuama — Wed, 07 Oct 2026 01:27:01 +0000

Tencent Cloud and Alibaba Cloud look identical on paper. Both assign IPs with essentially no reverse DNS — Tencent at 29/30 missing, Alibaba at 30/30. Neither publishes a registrant organisation in RDAP — every single Tencent IP in this sample (30/30) returns no registrant on record, the only provider of the twelve at 100%.

Their blocklist rates are not identical.

Provider	PTR missing	No registrant	On a blocklist
Tencent Cloud	29/30	30/30	6/30 (20%)
Alibaba Cloud	30/30	18/30	1/30 (3.3%)

Six times the listing rate, from two providers whose IP metadata is equally broken.

Metadata cannot tell them apart

Everything you can look up without querying a blocklist — PTR record, RDAP registrant, abuse contact — comes back equally empty for both. Tencent publishes an abuse role on 10/30 of its IPs, Alibaba on 12/30. Statistically indistinguishable.

If you were screening a VPS by checking its reverse DNS and WHOIS, you would have no way of telling the Tencent range from the Alibaba range. One carries six times the blocklist risk.

The listings are scattered, not network-wide

All six of Tencent's listed IPs appear on exactly one list — dnsbl.spfbl.net — the same single automated list that dominates the entire dataset (41 of 47 listed IPs across all 12 providers).

But unlike RackNerd, whose 25 listed IPs spread across 25 different /24 blocks look like one operator's policy applied network-wide, Tencent's six listings sit in six separate /24 ranges with no neighbours listed. That pattern reads as individual instances doing something that triggered one automated list, not a network-level decision.

The "Chinese IPs are dirty" assumption doesn't hold either

Pooling the two Chinese providers against the other ten:

	IPs	Listed	Rate
Tencent + Alibaba	60	7	11.7%
Other 10 providers	300	40	13.3%

The Chinese providers come in slightly cleaner than the rest of the sample. Whatever explains Tencent's 6/30, it is not the country.

What to actually check

Neither reverse DNS nor RDAP records will tell you whether an IP is clean. The only query that answers the question is the blocklist query itself.

Check the blocklists directly — all eight, not one. A single listing from dnsbl.spfbl.net means something different from a listing on SpamCop or UCEProtect.
Check how many lists. In this dataset no IP appears on more than one list — a single listing is the norm, and 87% of all listings trace back to SPFBL alone.
Ignore PTR and registrant as reputation signals. They describe how the provider provisions IPs, not how the IP has been used.

Method

360 IPs, 30 per provider, across 12 providers: RackNerd, BandwagonHost, Vultr, DigitalOcean, Linode, Hetzner, OVH, Contabo, Oracle Cloud, Alibaba Cloud, Tencent Cloud, and DMIT.

PTR looked up via direct DNS query, classified as named or none. Blocklists checked against 8 public DNSBLs: all.s5h.net, dnsbl-1.uceprotect.net, bl.spamcop.net, dnsbl.dronebl.org, dnsbl.spfbl.net, hostkarma.junkemailfilter.com, psbl.surriel.com, and bl.blocklist.de. RDAP queried against the relevant registry.

Full data: pureip.app/research/vps-audit-2026-09/en/

Blocklist check for any specific IP: pureip.app

161 of 360 VPS IPs have no reverse DNS. They're cleaner than the ones that do.

zihuama — Wed, 07 Oct 2026 00:59:35 +0000

Reverse DNS (PTR record) is the first thing most deliverability guides tell you to check. "No PTR = spammer" is treated as common knowledge.

I sampled 360 IPs across 12 VPS providers and checked both their PTR records and their presence on 8 public DNS blocklists. The assumption doesn't hold up.

The numbers

All 360 IPs, split by whether they had a PTR record at all:

	IPs	On a blocklist	Rate
No PTR record	161	16	9.9%
Has a PTR record	199	31	15.6%

IPs without reverse DNS are listed on fewer blocklists than IPs with it. The relationship runs the opposite direction from the conventional advice.

That doesn't mean PTR records cause listings. It means the absence of one is not evidence of anything.

Why the correlation inverts

The pattern becomes clear once you look at which providers sit on each side:

Alibaba Cloud: 30/30 IPs have no PTR (100%), but only 1/30 is on any blocklist (3.3%).
Tencent Cloud: 29/30 have no PTR (97%), and 6/30 are listed (20%).
BandwagonHost: 0/30 missing a PTR — every IP is set up — and only 1/30 is listed (3.3%).
DigitalOcean: 25/30 have no PTR, 1/30 listed.

The large cloud providers assign IPs in huge batches and never configure reverse DNS, because their customers spin up instances programmatically and PTR management isn't part of the default flow. Those batches are mostly clean — they're used for ordinary services.

The IPs most likely to have PTR records configured are the ones run by smaller hosting operations where someone sets things up by hand. Those same operations also host the cheap bulletproof-adjacent ranges that accumulate listings.

PTR configuration is a proxy for "how this provider operates," not for "how clean this IP is."

The blocklist detail

The 16 listings among the no-PTR IPs come from:

dnsbl.spfbl.net — 13
all.s5h.net — 1
hostkarma.junkemailfilter.com — 1
dnsbl.dronebl.org — 1

SPFBL dominates this group exactly as it dominates the full dataset: of all 47 listed IPs in the sample, 41 are on SPFBL alone, and not a single IP appears on more than one list. If you're checking an IP and it's listed, it's overwhelmingly likely to be exactly one list, and that list is SPFBL.

What this means for checking an IP

Checking PTR first is backwards. A missing PTR tells you the provider didn't configure it, which correlates with being a large cloud provider, which correlates with being cleaner.

The order that actually reflects risk:

Query the blocklists directly. This is the only step that measures the thing you care about.
Check RDAP for a registrant. 247/360 IPs in this sample (69%) return no registrant on record at all — which is a much stronger signal about who is accountable for the IP than PTR status.
Leave PTR for last. Useful context if you're debugging mail delivery specifically. Near-useless as a reputation signal.

Method

360 IPs, 30 per provider, across 12 providers: RackNerd, BandwagonHost, Vultr, DigitalOcean, Linode, Hetzner, OVH, Contabo, Oracle Cloud, Alibaba Cloud, Tencent Cloud, and DMIT.

Full data: pureip.app/research/vps-audit-2026-09/en/

Blocklist check for any specific IP: pureip.app

47 of 360 VPS IPs are blacklisted. All 47 are on exactly one list — and 87% of them on the same one.

zihuama — Tue, 06 Oct 2026 00:08:06 +0000

47 of 360 VPS IPs are blacklisted. All 47 are on exactly one list — and 87% of them on the same one.

Checking an IP against a DNSBL and seeing "listed" feels like a verdict. Across 360 IPs sampled from 12 VPS providers, 47 came back listed — 13.1%. That number on its own would make you avoid datacenter IPs entirely.

It shouldn't. Every single one of the 47 appears on exactly one list. Not one IP in the sample is listed by two or more providers.

The eight lists

Eight public DNSBLs, 360 IPs each:

Blocklist	Hits
dnsbl.spfbl.net	41
all.s5h.net	3
hostkarma.junkemailfilter.com	2
dnsbl.dronebl.org	1
bl.blocklist.de	0
bl.spamcop.net	0
dnsbl-1.uceprotect.net	0
psbl.surriel.com	0

Four of the eight lists returned zero hits across the entire sample. SpamCop, UCEProtect, blocklist.de and PSBL — the names people actually recognise — listed nothing.

One list is doing most of the work

41 of the 47 hits — 87% — come from a single list, dnsbl.spfbl.net. That matters because SPFBL is an aggressive, largely automated service with a low bar for inclusion. A listing there is not the same signal as a listing from an established operator, and the two should not be read as equivalent.

Take RackNerd: 25 of its 30 IPs are listed, all on SPFBL, spread across 25 different /24 blocks. Read alone, "25/30 blacklisted" sounds damning. Read against the table above, it means one list operator has decided to list most of a network that four other major operators have never touched.

At the other end, Contabo is 0/30 across all eight lists.

What this means when you check your own IP

If you run an IP reputation check and see a single listing from an automated list you don't recognise, while the established names come back clean, the correct reading is probably "one list operator's policy", not "this IP is dirty". Cross-check against several established lists before acting on it.

Method

360 IPs, 12 providers, 30 IPs each, sampled from each provider's announced BGP prefixes at /24 granularity. Same seed (20260928), reproducible. All 360 had a BGP origin ASN equal to the target provider.

The 360 raw records and the sampler are public: data vps-audit-2026-09.json (CC BY 4.0), method and per-IP detail at the full audit page.

I built PureIP — an IP lookup and network diagnostics toolbox — these 360 records are a byproduct of it.

I sampled 360 IPs from 12 VPS providers. Reverse DNS ranged from 0% to 100%, and the blocklist number needs unpacking.

zihuama — Sat, 03 Oct 2026 07:39:23 +0000

I sampled 360 IPs from 12 VPS providers. Reverse DNS ranged from 0% to 100%, and the blocklist number needs unpacking.

After my last post on cloud provider IP ranges, a few people asked the obvious follow-up: fine, but which VPS provider should I actually buy from? Those are the names people agonise over when picking a $20 box.

Fair. So this round sampled the providers people actually compare — 12 of them, 30 IPs each, 360 total, same seed (20260928), reproducible.

The method, because this round had more traps than the last one

For the provider → ASN mapping I didn't trust memory. Every row has evidence:

The announced prefix came from each AS's actual BGP announcements via RIPEstat, sampled at /24 granularity. Every IP in the sample really is advertised by that AS — I verified 360/360 have a BGP origin ASN equal to the target.
rDNS is a live PTR lookup, not a cache.
Blocklist status is 8 public DNSBLs.
RDAP gives the registrant and abuse contacts.

Finding 1: default reverse DNS is a policy choice, not a probability

199 of 360 have rDNS — 55.3% overall. But the per-provider spread is the story:

Provider	PTR present
BandwagonHost	30/30
DMIT	29/30
Hetzner	29/30
Contabo	28/30
RackNerd	25/30
OVH	17/30
Vultr	16/30
Linode	14/30
DigitalOcean	5/30
Oracle Cloud	5/30
Tencent Cloud	1/30
Alibaba Cloud	0/30

Alibaba Cloud has zero PTR records across the entire sample. BandwagonHost has all 30. If you are planning to send email, that gap is the single most predictive number in this whole dataset — because a missing PTR is treated as a spam signal by most receivers, before any content check runs.

Finding 2: the blocklist number is misleading until you unpack it

47 of 360 hit at least one list — 13.1%. By provider:

Provider	Blocklist hits
Contabo	0/30
BandwagonHost	1/30
DigitalOcean	1/30
Alibaba Cloud	1/30
Linode	1/30
Hetzner	2/30
Vultr	2/30
Oracle Cloud	2/30
DMIT	3/30
OVH	3/30
Tencent Cloud	6/30
RackNerd	25/30

Here is the part that needs unpacking. Every single one of the 47 hits is on one list only. And 41 of the 47 — 87% — come from a single list: dnsbl.spfbl.net.

That matters because SPFBL is an aggressive, largely automated listing service with a low bar for inclusion. It is not the same signal as a Spamhaus listing. If I had reported only the headline "13.1% are blacklisted", a reader would picture something far worse than the underlying data supports.

And then there is RackNerd. 25 of 30 IPs listed, all on dnsbl.spfbl.net, spread across 25 different /24 blocks. When the hits scatter across many /24s like that, it is not a few dirty IPs — the whole network is being judged. Moving to another IP in the same range will not help you. At the other end, Contabo is 0/30.

Finding 3: the PTR name, the registrant, and the announcer can be three different companies

A RackNerd IP resolves to something ending quadranet.com. A Vultr IP resolves to constant.com. A handful of Oracle IPs point at unifiedlayer.com. Three names, three different companies.

The interesting ones are the third-party datacenter domains: quadranet.com shows up in RackNerd's sample and in Vultr's. Your reverse DNS can name a facility you have never heard of, run by a company you did not buy from — because the address space was assigned, reassigned, or sits inside a larger block someone else still administers.

Finding 4: you buy from the brand, someone else holds the addresses

RDAP tells you who is on record as holding the block. 235 of 360 — 65% — return no registrant organisation at all. Of the 125 that do return one, every one names the provider you bought from.

So the more common case is not misattribution, it is absence. Two thirds of VPS IPs have no registrant on record. If you have ever run an IP lookup and seen a blank organisation field, that is normal — not a broken query and not evidence the address is suspicious.

One metric I threw away

I had computed "share of IPs whose RDAP discloses an abuse role" and got a suspiciously high number. I rechecked ten of them with a strict test and the number collapsed. The gap: my first check was matching the string "abuse" anywhere in the RDAP payload — in remarks, in email addresses, in IRT reference names. It does not mean "an entity is labelled with the abuse role". The number was fabricated by my own parser, so the metric is gone.

I'm keeping this in the post because it's the fairest example of how this whole exercise can mislead you. Every other number here survived the same scrutiny; this one didn't.

What I did not measure

A clean blocklist does not mean ChatGPT will load. AI services maintain their own IP reputation that public DNSBLs do not measure. That is a separate test.
30 IPs per provider is a sample of the ranges, not a census. A provider with a large network has far more space than 30 addresses can represent.
Blocklists are dynamic. This snapshot is September 2026.

The 360 raw records and the sampler are public: data vps-audit-2026-09.json (CC BY 4.0), method and per-IP detail at the full audit page.

I built PureIP — an IP lookup and network diagnostics toolbox — these 360 records are a byproduct of it.

How to check whether your VPS IP is blocked by ChatGPT

zihuama — Fri, 02 Oct 2026 14:55:02 +0000

You bought the VPS. You opened a browser on it. ChatGPT gave you a Cloudflare challenge that spins forever.

The first thing everyone does is run the IP through a reputation checker, get a clean score, and conclude the problem must be something else. I have watched this happen dozens of times, and I built an IP reputation tool, so I am exactly the person whose product fails them here. The score is not lying to you. It is answering a different question than the one you are asking.

So here is how you actually determine whether your address is blocked, and how to do it in a way that does not depend on trusting any tool — including mine.

Step 1: Establish what kind of address you actually have

Before testing anything, get the classification. This is the single most predictive piece of information, and it is free.

curl -s https://ipinfo.io/<your-ip>/json

Look at the org field. If it reads AS14061 DigitalOcean, LLC or AS20473 Vultr Holdings, LLC, then the address is identifiable as a datacenter range by anyone who cares to look. This is not a secret and not a misclassification — you are, in fact, in a datacenter. Risk engines know these ASNs by number.

Now check whether it is flagged as something narrower:

curl -s https://ipinfo.io/<your-ip>/json | grep -E '"privacy"|"hosting"|"vpn"|"proxy"'

If hosting: true and vpn: false, you have a plain datacenter address. That is the most common case and the hardest one to fix, because nothing is wrong with it — it is simply the wrong category of address for services that want residential traffic.

This step matters because it tells you whether you are chasing a defect or fighting a classification. Those have completely different remedies, and people waste weeks fixing the wrong one.

Step 2: Check the blocklists — and read them correctly

Query a few public DNS blocklists. The reason to do this is not that a clean result means you are fine. It does not. The reason is that a dirty result tells you something concrete and actionable.

A DNSBL lookup is just a reversed-IP DNS query — no tool required, and dig is not always installed. Python is, and it is one line:

import socket
ip = "your.ip.here"
reversed_ip = ".".join(reversed(ip.split(".")))
for lst in ["all.s5h.net", "bl.spamcop.net", "dnsbl-1.uceprotect.net", "dnsbl.dronebl.org"]:
    try:
        socket.gethostbyname(f"{reversed_ip}.{lst}")
        print(f"{lst}: LISTED")
    except socket.gaierror:
        print(f"{lst}: not listed")

Any LISTED result means a listing. Here is the part most guides skip: interpret which list fired.

A listing on dnsbl.spfbl.net spread across a whole /24, where every address you sample in the ASN returns the same hit, describes a policy about the ASN — not a complaint about your machine. A listing on bl.spamcop.org tied to your specific address, with nothing else in your /24 flagged, describes actual spam from that address.

The first one is a property of the provider's space and you cannot personally fix it. The second is a property of the address, and it is worth contacting the list about. Knowing which one you have saves you from disputing the wrong thing.

I sampled 360 addresses across 12 providers recently and 41 of 47 total hits came from a single list, dnsbl.spfbl.net, with 25 of them spread one-each across 25 different /24 blocks in one ASN. That is the blanket-judgement signature. It looks alarming in aggregate and tells you almost nothing about the specific box you would rent.

Step 3: Test the actual service

This is the step that answers your question, and most people skip it because a reputation score felt like an answer.

You do not need a tool for this. From the VPS itself:

curl -sI https://chatgpt.com/ | head -5
curl -sI https://claude.ai/ | head -5

What you are looking for is not the status code alone — it is whether you get the challenge page. A 403 with cf-mitigated: challenge or a body containing Just a moment means Cloudflare's risk system flagged the address. A 200 means the front page loaded. Neither tells you whether you can log in, because login is a separate gate with separate signals — but the front page is the first wall, and it is the one you can test without an account.

Test more than one service. They do not share risk data, and I have seen addresses pass one and fail another:

for url in https://chatgpt.com/ https://claude.ai/ https://gemini.google.com/ https://grok.com/ https://www.perplexity.ai/; do
  echo "$url → $(curl -sI -o /dev/null -w '%{http_code}' $url)"
done

Do this from the VPS, not from your home machine. The result only means something for the address that made the request.

Step 4: Check who held the address before you

whois <your-ip>

Look at the netname and the registrant. If they do not match your provider, the block was previously held by someone else, and you inherited whatever reputation that block accumulated.

This is more common than it sounds. In that 360-address sample I mentioned, Oracle's space contained addresses still registered to HostGator, and Vultr's contained a block registered to a different company than the one that announces it. Those providers did nothing wrong — they acquired or rent space with history attached.

If the previous holder was a bulk mail operation or a known proxy network, that history is in risk databases that no blocklist query surfaces, and no amount of clean behaviour on your part erases it quickly.

Step 5: Test before you buy, at the /24 level

The cheapest mistake is renting a box and discovering the problem afterwards. Providers do not give you this information, but you can take it.

Pick any address already in the provider's announced space — they publish their prefixes, and you can enumerate them from BGP. Check that address the way you just checked yours. If the /24 you are about to land in is flagged, move to a different region or a different provider.

Do this at the /24 level, not the provider level. In that same sample, one provider had three hits scattered across three different /24 blocks while the specific block our own server sits in was completely clean. Same ASN, same provider, materially different outcome. A provider-level average would have told you nothing useful.

What to do when it is blocked

Roughly in order of cost:

Change region within the provider. Providers have different address blocks in different datacenters, and they are not equally seasoned. This is the cheapest fix and often works. Check the new block before committing.

Change provider. If most of a provider's space is flagged, no region helps. The blocklist data above is a reasonable triage signal at that point — if one ASN is blanket-listed, move.

Use a residential proxy. Expensive, and the only reliable answer if the service genuinely wants residential traffic. Metered plans let you test cheaply first. Do not commit to a large plan before confirming it actually changes the outcome.

Appeal the listing. Only applies if you found a specific-address listing rather than an ASN-wide one. Find the list's delisting process and follow it. This does not work for datacenter classification, because there is nothing to appeal — the address is correctly classified.

A note on the limits of all of this

I want to be clear about what I cannot tell you.

I cannot give you a formula that predicts risk-engine behaviour. The steps above are the best available triangulation — ASN identity, blocklist signature, direct testing, registration history. They will tell you a lot. None of them will tell you with certainty whether ChatGPT loads, because the final decision is made by a system whose inputs are not public.

A clean result on every check is not a guarantee. I have a server that scores 85/100, classifies as residential rather than datacenter, appears on zero of eight blocklists I query, has no VPN or proxy flags — and still gets a Cloudflare challenge on ChatGPT, Claude and Perplexity. Every signal says clean. Three of six front pages still return 403. I do not have an explanation for that gap, and I am not going to manufacture one.

The honest version of this whole guide is: check the things you can check, test the thing you actually want to know, and do not accept a proxy measurement as the answer.

The data

The 360-address sample referenced above is public: vps-audit-2026-09.json (CC BY 4.0). GitHub: mazihua-lgtm/vps-ip-audit-2026-09. Seed fixed, re-running reproduces it.

The tool I mentioned that does some of these checks: pureip.app/ip. It does reputation, blocklists, ASN and RDAP on one page, and it checks AI-service reachability for the address you are browsing from. It cannot check an arbitrary address for AI reachability — only the one you are on — which is precisely why this guide is written so you do not need it.

Disclosure: I build and maintain pureip.app. The 360-record dataset is a byproduct of it. The guide above deliberately works without my tool or anyone else's, because I would rather you verify this yourself than take my word for it.

Your VPS IP is not on any blocklist. ChatGPT still blocks it.

zihuama — Fri, 02 Oct 2026 14:16:34 +0000

You ran the checks. AbuseIPDB says zero reports. IPQS gives a fraud score of 1. Scamalytics calls it clean. Everything you were told to check says this IP is fine.

Then you point it at ChatGPT and get a Cloudflare challenge that never finishes.

This is not a contradiction, and it is not your checking methodology failing. The blocklists those tools query and the IP risk system Cloudflare runs for OpenAI are two different products built for two different customers. The first one answers "has this address sent spam." The second one answers "does this address look like a machine in a datacenter, and what has it been used for." An address can score perfectly on the first and fail the second.

I run an IP reputation tool, so I hit this constantly. Rather than argue about it, I took a sample.

The sample

12 VPS providers, 30 IPv4 addresses each, 360 total. Each address sampled from the /24 blocks that provider's ASN actually announces — not from their marketing page, from BGP. Every sampled IP was checked to confirm its origin ASN matches the provider before being kept. Seed fixed at 20260928, so re-running gives you the same set. The full 360 records are public (CC BY 4.0).

What I measured: reverse DNS, 8 public DNS blocklists, RDAP registration, BGP origin.

What I did not measure: whether ChatGPT actually loads on any of these. I will get to why that gap matters, and why I am not going to paper over it.

What the blocklists said

47 of 360 addresses — 13.1% — hit at least one list. By provider:

Provider	Hits	Rate	Which lists
RackNerd	25/30	83.3%	`dnsbl.spfbl.net` ×25
Tencent Cloud	6/30	20.0%	`dnsbl.spfbl.net` ×6
DMIT	3/30	10.0%	`all.s5h.net` ×1, `dnsbl.spfbl.net` ×2
OVH	3/30	10.0%	`dnsbl.spfbl.net` ×2, `hostkarma.junkemailfilter.com` ×1
Hetzner	2/30	6.7%	`all.s5h.net` ×1, `dnsbl.spfbl.net` ×1
Oracle Cloud	2/30	6.7%	`hostkarma.junkemailfilter.com` ×1, `dnsbl.spfbl.net` ×1
Vultr	2/30	6.7%	`dnsbl.spfbl.net` ×2
BandwagonHost	1/30	3.3%	`dnsbl.spfbl.net`
DigitalOcean	1/30	3.3%	`all.s5h.net`
Linode	1/30	3.3%	`dnsbl.spfbl.net`
Alibaba Cloud	1/30	3.3%	`dnsbl.dronebl.org`
Contabo	0/30	0.0%	—

Across all 360, the lists fired 47 times total: dnsbl.spfbl.net 41, all.s5h.net 3, hostkarma.junkemailfilter.com 2, dnsbl.dronebl.org 1.

87% of all hits come from one list. And RackNerd's 25 hits are spread across 25 different /24 blocks, exactly one each.

That is not a pattern that describes 25 spammy machines. That is a pattern that describes one list making a blanket judgement about an entire AS — sample anywhere in it, you are listed. Whether that policy is defensible is not something I can determine from outside. But the practical reading is clear: a hit here tells you about the list's coverage of the ASN, not about the specific box you would be renting.

So the headline "13.1% of VPS IPs are listed" is close to meaningless as a buying signal. The honest version: one aggressive list accounts for almost all of it, and outside of RackNerd's territory the rates are in the low single digits.

The part the blocklists cannot see

Now the finding that actually matters, and it is not in any of the 47 hits.

Our own server runs on DMIT, address 154.21.82.31. The sample happened to draw a different address from the same /24 — 154.21.82.51, zero hits, PTR Host-By.DMIT.com. Clean block.

I then ran our server's own address through the reputation check. This is the actual output, not a hypothetical:

IP:     154.21.82.31
Score:  85 / 100  (status: "good")
Flags:  residential: true,  datacenter: false,  vpn: false,
        proxy: false,  tor: false,  crawler: false,  abuser: false

Read that carefully. Every signal available says this address is clean — and it is not even classified as a datacenter. It comes back as residential. That is the strongest hand you can possibly hold. Eight DNSBLs return nothing. It is not a VPN, not a proxy, not flagged for abuse, and the classifier thinks it is a home connection.

So I tested it against the services people actually want to reach. Plain HTTP GET, no login, no credentials — just opening the front page:

Service	HTTP	Result
ChatGPT	403	Cloudflare challenge
Claude	403	Cloudflare "Just a moment"
Perplexity	403	Cloudflare "Just a moment"
Gemini	200	reachable
Grok	200	reachable
Google Search	200	reachable

Three of six blocked, every one of them by Cloudflare. Same address that scores 85/100, classifies as residential, and appears on zero of eight blocklists.

That is the whole argument in one table. If the cleanest possible address — residential classification, no flags, zero blocklist presence — still gets a 403 from the front page of ChatGPT, then the gap between "blocklist-clean" and "works with ChatGPT" is not a data problem you can check your way out of. There is no blocklist query that would have predicted this, because the risk engine is not running a blocklist query. It is doing something else, with data you cannot see, and the answer it produces is not derivable from the eight lists I measured.

Note also what the DMIT numbers say: 3/30, 10.0%. Middling, not clean — and the hits are scattered one-each across three unrelated /24 blocks (154.17.227.0/24, 64.186.252.0/24, 64.186.239.0/24), the same signature as RackNerd's. Meanwhile the /24 we actually sit in came back at zero. Same provider, same ASN, materially different result depending on which block you land in. If you are picking a provider based on a provider-level score, you are picking at the wrong granularity. The block is the unit that matters, and provider-level averages hide it.

Three signals that carry more weight than a blocklist

From this dataset, three things stand out. To be precise about what I am claiming: these are patterns I observed across 360 samples. I did not run a controlled experiment, and I have no data whatsoever on how any risk engine actually scores.

Reverse DNS, and specifically whether it looks operator-maintained. 199 of 360 have PTR records — 55.3%. The rate varies enormously by provider:

Provider	Has PTR	Rate
BandwagonHost	30/30	100.0%
Hetzner	29/30	96.7%
DMIT	29/30	96.7%
Contabo	28/30	93.3%
RackNerd	25/30	83.3%
OVH	17/30	56.7%
Vultr	16/30	53.3%
Linode	14/30	46.7%
Oracle Cloud	5/30	16.7%
DigitalOcean	5/30	16.7%
Tencent Cloud	1/30	3.3%
Alibaba Cloud	0/30	0.0%

But the rate is not the interesting part — the naming is. BandwagonHost templates all 30 as X.Y.Z.W.16clouds.com. Hetzner's read static.X.Y.Z.W.clients.your-server.de. Those are infrastructural; they announce "datacenter" rather than hide it. What stands out is the handful that look like a real operator on a real domain. DigitalOcean's five PTR records are all customer-set (prod-db1.do.fr, crm.desata.app, do.mtv3.org, 1399717.cloudwaysapps.com, mitoo-qa.vms) — DO does not set rDNS by default, so every one of those was configured by hand. A PTR that reads as deliberately maintained is a signal. A provider template is the absence of one.

ASN identity itself. The risk engines know AS20473 is Vultr and AS14061 is DigitalOcean. That is public, trivially queryable, and no amount of clean history changes it. If the classification is "datacenter," the classification is correct — you are in a datacenter. This is not a misclassification you can appeal.

Registrant fragmentation. Within RackNerd's 30 addresses, RDAP registrant is HostPapa ×5, RackNerd LLC ×6, and 19 with no registrant entity. Within Oracle Cloud's 30: Oracle Corporation ×5, but also HostGator.com LLC ×1 and Newfold Digital ×1, with 20 carrying no registrant at all. A block previously held by another company carries that company's history whether or not the current holder did anything. Oracle's space still carrying HostGator registrations is the live example.

What I would actually do with a VPS IP

Given all of the above, and given that I cannot predict risk-engine behaviour from outside:

Check PTR and set your own if the provider allows. If you are on Alibaba (0/30), Tencent (1/30), Oracle (5/30) or DigitalOcean (5/30), the default is nothing. Set it in the panel with your own domain. This is the one signal you control entirely.

Check RDAP for who held the block before you. Thirty seconds of work. If the registrant is not your provider, you have inherited a reputation you did not build, and your abuse escalation path is one layer longer than you assumed.

Do not treat a clean blocklist result as a green light. It means nobody reported spam. It says nothing about AI-service reachability — my own server is the proof, at 85/100 residential with zero listings and still getting challenged. If the tool you are using can check the AI services directly, that is the check that matters for this use case. And yes, that is what my own tool does, so apply whatever discount you think is fair to my enthusiasm for it.

Test before you commit, and test at the /24 level. Provider-level averages hide enormous within-provider variance — DMIT ranges from 0/30 in one block to a hit in another, in the same AS. Rent nothing until you have checked an address in the specific block you are about to buy from.

What this data cannot tell you

I want to be direct about the boundary, because this is exactly where content like this usually starts lying.

I did not measure ChatGPT, Claude, or any service actually loading. Every claim above about risk engines is structural reasoning from ASN/PTR/RDAP patterns plus one measured data point about my own server. It is informed. It is not a controlled measurement, and you should weight it accordingly.
Blocklist data is a snapshot. I re-ran the same sample earlier with a different provider ordering and OVH moved 0→3, RackNerd 24→25, DigitalOcean 4→1. These lists update continuously. Every number here is "as of 2026-10-01."
zen.spamhaus.org is not in the data. It refuses queries from public resolvers. It is one of the highest-weighted lists in mail filtering, so its absence is a real gap. I am not going to pad it with other lists and claim coverage.
This is announced space, not customer machines. It includes blocks not yet assigned to anyone. So the PTR rates are "how much of this AS's space carries rDNS," not "your odds of getting rDNS when you buy."
/24 is an approximation of the granularity customers actually receive. It is not exactly what you get.

The data

360 records, the sampler, and the seed: vps-audit-2026-09.json (CC BY 4.0). GitHub: mazihua-lgtm/vps-ip-audit-2026-09. Re-running the script reproduces the same sample.

I normally run these checks in my own tool: pureip.app/ip — reputation lookup with PTR, blocklists, ASN, RDAP, and per-provider AI-service availability on one page. The 360-IP sample is a byproduct of it.

Disclosure: I build and maintain pureip.app, an IP lookup and network diagnostics toolbox. This sample is a byproduct of it, the data is real, and the tool is mine — saying so up front seemed better than letting you find out.

I checked 288 cloud provider IPs against public records. A few numbers surprised me.

zihuama — Mon, 28 Sep 2026 09:55:56 +0000

Someone asked me to pick a VPS for them and then asked the obvious question: is this IP clean? I didn't know, so I looked it up. And while looking, I noticed something: everyone publishes how to check one IP, nobody publishes what the distribution actually looks like when you grab a bunch of IPs at random from AWS, GCP and Cloudflare ranges.

So I grabbed a bunch. 288 IPs, all sampled from the ranges the providers publish themselves (AWS ip-ranges.json filtered to service=EC2, GCP cloud.json, Cloudflare ips-v4), randomized per region, seed hardcoded in the script so anyone can reproduce the exact same list.

Four things measured, all from public sources, no accounts, no API keys: reverse DNS (PTR), eight public mail blocklists, who actually announces the IP in BGP, and the RDAP registration record.

1. Reverse DNS: three providers, three completely different attitudes

Group	Sample	Has PTR
GCP us-central1	50	100%
GCP asia-southeast1	43	100%
GCP asia-east1	30	100%
AWS ap-northeast-1	50	52%
AWS ap-southeast-1	50	48%
AWS us-east-1	50	42%
Cloudflare	15	6.7%

All 123 GCP IPs had one, uniformly formatted as xxx.xxx.xxx.xxx.bc.googleusercontent.com.

About half of AWS did, looking like ec2-15-181-82-64.compute-1.amazonaws.com. The rest are customer-configured — I hit EC2 addresses whose PTR points at nywebpage.net, mrsparkman.com, panoag.com, and one where somebody set it to ip-99-77-244-82.ec2.ap-northeast-1.vc.chime.aws.

Of the 15 Cloudflare IPs, exactly one had a PTR, and it was gina.ns.cloudflare.com — an anycast authoritative DNS node. Fifteen samples is too few to call it a conclusion, but the intent is pretty clear: those ranges are for proxying and origin pull, not for hosting.

Why this matters in practice: Google's bulk sender guidelines require sending domains or IPs to have valid forward and reverse DNS. Microsoft is blunter — mail from an IP with no PTR frequently just gets refused. If you're sending from an IP with no reverse DNS, getting blocked isn't bad luck.

2. 4.5% hit a blocklist, and nearly all of them on the same list

13 of 288 IPs showed up on at least one list — 4.5%. Twelve of those were on dnsbl.spfbl.net, one on all.s5h.net.

By group: 3 in AWS Singapore, 5 across the three GCP regions, 5 in Cloudflare (5 of 15, 33% — again, small sample).

One limitation I have to state: Spamhaus' zen refuses queries from public resolvers, so I could not query it over DoH at all. The most authoritative list is therefore not in these numbers. The real hit rate can only be higher than 4.5%.

My read: the big providers' ranges are mostly clean. 4.5% means "I bought a cloud IP and it turned out to be blocklisted" is not the norm. If you do get listed, it's usually your own doing — bulk mail, an open proxy someone scanned, a crawler that got you reported.

3. Some IPs inside cloud ranges belong to somebody else

RIPEstat found a BGP announcement for 96.5% of the IPs. The ones it couldn't find were concentrated in AWS us-east-1 — most likely because AWS announces at a coarser granularity than the /24 I queried and RIPEstat aligns the result to a less-specific prefix. That does not mean the range is unannounced.

The interesting ones are these:

155.146.3.47      AWS us-east-1   → AS6167  Verizon Business
155.146.227.88    AWS us-east-1   → AS6167  Verizon Business
192.157.36.235    AWS us-east-1   → ASN-BYO-DEMO (Amazon's own BYOIP demo)
34.0.225.187      GCP us-central1 → AS43515 YOUTUBE, Google Ireland
35.206.64.222     GCP us-central1 → AS43515 YOUTUBE, Google Ireland

"Inside an AWS published range" does not mean "inside AWS's AS". Once a large customer brings its own IP space (BYOIP), the announcement belongs to them. If your heuristic for IP ownership is the ASN, this is where it breaks.

4. The registration record is not what you think it is

286 of 288 had an RDAP handle and 285 disclosed an abuse role — essentially all of them. Registrants were entirely these:

Google LLC                          123
Amazon.com, Inc.                     59
Amazon Technologies Inc.             37
Amazon Data Services Northern Va.    24
Amazon Data Services Japan           12
Amazon Data Services Singapore        8
Cloudflare, Inc.                      7

A lot of people read the RDAP country field as "where this IP is located". It isn't. It's where the registrant registered. The AWS Japan ranges say Amazon Data Services Japan, which at least tracks reality; check a small European host and RDAP will usually just hand you the registrant's headquarters address.

Do not judge location from registration data alone.

Data and method

Sample: 288 IPs. AWS 150 (us-east-1 / ap-northeast-1 / ap-southeast-1, 50 each), GCP 123 (us-central1 50, asia-southeast1 43, asia-east1 30), Cloudflare 15
Sampling: random within the published ranges, per region, seed 20260928
PTR and blocklists: queried over DoH (dns.google) against <reversed-ip>.in-addr.arpa and eight lists; six samples re-checked against Cloudflare DoH, all matching
Blocklists were self-tested first: queried each with the guaranteed-hit address 127.0.0.2 and kept only those that actually answer. Final eight: all.s5h.net, dnsbl-1.uceprotect.net, bl.spamcop.net, dnsbl.dronebl.org, dnsbl.spfbl.net, hostkarma.junkemailfilter.com, psbl.surriel.com, bl.blocklist.de (zen.spamhaus.org refuses public resolvers and was dropped)
BGP: RIPEstat prefix-overview
Registration: RDAP (rdap.org first, then the RIR endpoints directly once it rate-limited me)

Raw 288 records: https://pureip.app/ip-audit-2026-09.json (CC BY 4.0). Data and sampler also on GitHub: https://github.com/mazihua-lgtm/ip-audit-2026-09 — reproducible, corrections welcome, mail agent@pureip.app if you want another provider's ranges covered (Alibaba Cloud, Oracle, Vultr).

One thing I did not measure

This post does not tell you which IPs can access ChatGPT or Claude. Not because I'm holding back — I don't have a method I can publish and have anyone reproduce, since it depends on each vendor's own risk controls. A number I can't reproduce is worse than no number.

What the public data does tell you: whether an IP has reverse DNS, whether it's on a blocklist, who actually announces it, and who registered it. The rest is your call.

Disclosure: I build and maintain pureip.app, an IP lookup and network diagnostics toolbox — these 288 records are a byproduct of it. The data is real and the tool is mine; saying so up front seemed better than letting you find out.

DEV Community: zihuama

IP Reputation Scores Disagree. We Tested 8 IPs on 4 Free APIs

Why we did this

The 8 test IPs

The four APIs, and what each one returned

1. PureIP /api/ip/health — the "trust score"

2. Scamalytics — the "fraud score"

3. ip-api.com — the boolean flags

4. ipwho.is — the one with no risk data at all

The three disagreements

Disagreement 1: Is 8.8.8.8 a proxy?

Disagreement 2: 45.155.205.233 — clean or abuser?

Disagreement 3: the scores aren't correlated at all

What to actually do about it

Re-run it yourself

Method and limits

My soft-404 bug was real. My 'Bing indexed zero pages' claim was not.

What was actually broken

The conclusion that was wrong

What I actually know now

Why this happens

Reusable lessons

Bugs fixed along the way

Two Chinese cloud providers have the same broken IP metadata. One is 6x more likely to be blacklisted.

Metadata cannot tell them apart

The listings are scattered, not network-wide

The "Chinese IPs are dirty" assumption doesn't hold either

What to actually check

Method

161 of 360 VPS IPs have no reverse DNS. They're cleaner than the ones that do.

The numbers

Why the correlation inverts

The blocklist detail

What this means for checking an IP

Method

47 of 360 VPS IPs are blacklisted. All 47 are on exactly one list — and 87% of them on the same one.

47 of 360 VPS IPs are blacklisted. All 47 are on exactly one list — and 87% of them on the same one.

The eight lists

One list is doing most of the work

What this means when you check your own IP

Method

I sampled 360 IPs from 12 VPS providers. Reverse DNS ranged from 0% to 100%, and the blocklist number needs unpacking.

I sampled 360 IPs from 12 VPS providers. Reverse DNS ranged from 0% to 100%, and the blocklist number needs unpacking.

The method, because this round had more traps than the last one

Finding 1: default reverse DNS is a policy choice, not a probability

Finding 2: the blocklist number is misleading until you unpack it

Finding 3: the PTR name, the registrant, and the announcer can be three different companies

Finding 4: you buy from the brand, someone else holds the addresses

One metric I threw away

What I did not measure

How to check whether your VPS IP is blocked by ChatGPT

Step 1: Establish what kind of address you actually have

Step 2: Check the blocklists — and read them correctly

Step 3: Test the actual service

Step 4: Check who held the address before you

Step 5: Test before you buy, at the /24 level

What to do when it is blocked

A note on the limits of all of this

The data

Your VPS IP is not on any blocklist. ChatGPT still blocks it.

The sample

What the blocklists said

The part the blocklists cannot see

Three signals that carry more weight than a blocklist

What I would actually do with a VPS IP

What this data cannot tell you

The data

I checked 288 cloud provider IPs against public records. A few numbers surprised me.

1. Reverse DNS: three providers, three completely different attitudes

2. 4.5% hit a blocklist, and nearly all of them on the same list

3. Some IPs inside cloud ranges belong to somebody else

4. The registration record is not what you think it is

Data and method

One thing I did not measure

1. PureIP `/api/ip/health` — the "trust score"

Disagreement 1: Is `8.8.8.8` a proxy?

Disagreement 2: `45.155.205.233` — clean or abuser?