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.orgis 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.
Top comments (0)