Why clean hosting addresses still get CAPTCHAs, and what an operator can actually change
A customer complains that your addresses get challenged everywhere, you check the range and nothing comes back: the lists you queried do not carry the addresses you checked, no feed flags the addresses you spot-checked, and the registry and routing record holds nothing remarkable. The frustrating answer is often that the challenge was never about your record. Often, not always: lists and feeds lag, they cover what they cover, and none of them sees what a customer's traffic did this afternoon, so rule that out before you accept the category explanation. Hosting origin is treated as a category by parts of the web, quite separately from anything your range has done. Here is what the web side actually publishes about that, what you can publish back, and the ceiling on what publishing achieves. Every vendor page cited was read on 23 August 2026 and most carry no version, so re-check before acting.
Category, not verdict
Start by separating two things your support desk keeps receiving as one complaint. A blocklist listing is usually about behaviour, naming your range because of something that came from it, though not always: some lists describe what a range is for rather than what it did, and those are the proxy, VPN and Tor exit lists rather than hosting lists, which is why the hosting case below turns out not to be a blocklist problem at all. A hosting classification is about what kind of network you are, and it applies whether or not anything has ever come from the range. The clearest published example of the second is AWS's managed rule group for anonymous traffic, whose hosting rule is documented as inspecting for a list of addresses from web hosting and cloud providers, with a default action of Block, and the same entry says the list does not include AWS's own addresses. It is described in AWS's own words as less likely to source end-user traffic, with a default action of Block. That is the whole logic in one sentence: not that your addresses are bad, but that people are not usually browsing from them. Usually is doing the work in that sentence, and it cuts both ways: ordinary human browsing does arrive from infrastructure space, because platform relays and corporate egress put real users behind third-party ranges, so the category is coarse in both directions and a rule built on it holds up some of the people it was never aimed at. Nothing you clean up changes that premise, which is why the complaint feels unanswerable when you treat it as a reputation problem. Note also that a default action is a default: a customer can override it, so appearing in such a list does not mean a block at any particular site.
What the web side publishes
The published picture is patchier than the folklore. Google's Cloud Armor threat intelligence gives customers named lists to match on directly, among them one documented as matching addresses belonging to public clouds, with separate variants for the major cloud providers, alongside one documented as matching ranges used by low-reputation VPN providers and one for open anonymous proxies; that feature requires a Cloud Armor Enterprise subscription, and that documentation, printed as last updated 11 August 2026, gives no membership criteria, and we found no published correction path for a range that appears in one. Cloudflare is the interesting counterweight: on the two pages we read on 23 August 2026, its published managed IP lists are open proxies, anonymizers, VPNs, and malware and botnet command and control, with no hosting, datacenter or cloud category at all, and its bot score documentation names its detection engines without naming hosting origin, ASN or IP reputation among them. Do not read that as Cloudflare ignoring hosting origin, and do not read it as concealment; the accurate statement is that neither of those pages named it on that date, and Cloudflare did once publish an IP reputation signal, a threat score its own field reference now says is always zero. Google's reCAPTCHA is the same shape: the reason codes listed on its website assessment interpretation page, last updated 11 August 2026, name automation, an unexpected environment, too much traffic, unexpected usage patterns and low confidence, its API reference adds only an unspecified value and two deprecated fraud codes, and none of them names datacenter, hosting, proxy, VPN or IP reputation. The most useful fact for a support desk is smaller and more mundane: Cloudflare documents a rules language field carrying the AS number of the client address, available in custom rules. Some "our whole range is blocked" reports have no vendor scoring model behind them at all: any site owner can write a rule against your ASN with that field, and there is no list to appeal to, only the site. That is also the one place you have an argument rather than a form: a rule at AS number width reaches every uninvolved customer inside the space, most of whom the site owner has no quarrel with, and saying so with the sub-block detail to back it is worth more than any file you could publish.
Four different questions
Before you spend a week on remediation, work out which of four things you are actually fighting, because only one of them has a documented fix. Start with what the traffic is doing, because that is the question the vendors document: the reason codes quoted above describe the client rather than the address, so one tenant running automation can produce a range-wide complaint that no list will ever show you, and asking the complaining customer what their traffic looks like costs an hour and settles it. Then work out which of the remaining three you are actually fighting, because only one of them has a documented fix. Where a provider thinks the address is, meaning geolocation, has published correction paths. What a provider thinks the address is, meaning the hosting, VPN and proxy flags, mostly does not: MaxMind documents fields for whether an address belongs to a hosting provider, an anonymous VPN, a public proxy, a residential proxy or a Tor exit node, and while it publishes self-serve forms for location and for ISP or organisation name, for the anonymiser flags it directs anyone who believes an address is wrongly flagged to contact support so its data review team can investigate. Spur's documentation shows an infrastructure field carrying values such as datacenter, and as of 23 August 2026 we found no published correction or dispute page there. And the third question, whether a given site chose to act on either, is not a data question at all: it is a rule somebody wrote, and the only route is the site. Blocklists, for what it is worth, are mostly not your problem here: of the policy pages we read on that date, none makes hosting or datacenter status a listing criterion, and Spamhaus's do-not-route-or-peer policy page, which carries no version or date, says of that list that address space under the control of any legitimate network will never be listed. That is one list's statement about its own scope, not a promise about every list a range can appear on.
What you can publish about yourself
What an operator controls is the public description of its own space, and the aim is accuracy rather than appearance. Four things are worth getting right. Reverse DNS that says what the range is and forward-confirms: that pattern is documented as readable in at least two published programmes, Cloudflare's bot verification, which says addresses should have PTR records set correctly, and Google's crawler verification, which describes a reverse lookup that must resolve into its own domains followed by a forward lookup returning the original address. Both are programmes for bot and crawler operators rather than for hosting customers generally, so treat them as evidence that the field is read somewhere, not as a promise about your range. The registry record is the second: an accurate organisation, a netname that describes the space, an abuse contact that answers, and a customer sub-block registered where policy requires it, so a customer's own record exists rather than everything resolving to your aggregate. Third, a geofeed. RFC 8805 defines the file, a CSV of prefix, country, region, city and postal code, and RFC 9632 of August 2024, which obsoleted RFC 9092, defines how a consumer finds it from registry data, either from a dedicated geofeed attribute or from a case-sensitive remarks line, and requires that the most specific object carrying a reference be used. The RFC also notes that geofeed data may have finer granularity than the object referring to it, so on our reading a sub-range that already has its own registry object carrying a reference describes itself without the parent's record changing; creating that object is a separate registration step the RFC does not perform. RIPE NCC and APNIC both carry a geofeed attribute; ARIN has no dedicated field, and its documented route is a Geofeed line in the Public Comments on the network record; its community suggestion for a real field (ACSP suggestion 2024.10) was still open on 23 August 2026, and although RFC 9877 of 2025 defines an RDAP extension for geofeed data, ARIN's RDAP did not advertise it that day. Fourth, keep your PeeringDB record current, which earns its place for the contact and peering detail rather than for classification: its network type is self-declared, and the published options included no hosting or datacenter category as of 23 August 2026, so the field cannot describe hosting space accurately; no provider we checked documents reading it for classification.
The ceiling on all of this
Now the part most posts on this subject leave out. Publishing obliges nobody. RFC 8805 says consumers may treat published feed data as a hint only and may prefer other sources for any given prefix, and recommends, in the absence of other timing information, that they refresh feeds no less often than weekly. Where a vendor does document a process, it runs on release cycles: MaxMind tells network operators they should join its exchange and submit a geofeed, says geofeed submissions are imported and reviewed once per business day and one-off corrections typically within one to two business days, and that accepted corrections appear in the next database release. And here is the honest limit on the whole exercise: none of the providers we checked publishes any documented link between a correct geofeed and fewer challenges. Location data and the hosting flag are different fields, and fixing the first is not documented to move the second. So publish an accurate self description because it is true and because it makes you legible to the people who do read it, not because it is a lever on a CAPTCHA rate. What that legibility moves is narrower and slower than a challenge rate: it is how your space reads to a human who investigates it, an abuse report that reaches you, a customer sub-block that answers for itself instead of pointing at your aggregate, and a clean history that accumulates over time.
Look your own ranges up on the front page and read them the way an outsider does: the registered block the heading names and the enclosing blocks above it, which is where you see whether a customer sub-block resolves to itself or to your aggregate, the netname as published, the abuse contact it resolves to, which network announces the space and its RPKI state. Any confirmed tags sit on the announcing network or on a covering block rather than necessarily on your range, and no tag means nothing has been confirmed rather than that the range reads clean.