Every IP intelligence vendor is asked the same question, and most of them answer it with a number. Spaw answers it with a sentence in its own documentation: residential proxies are not detectable with open data and are not claimed. This guide explains why that sentence is the honest one, what the answer says instead, and how to build a policy on evidence you actually hold.
What a residential proxy is
A residential proxy routes someone else's traffic through a real consumer connection. The address a server sees belongs to a home broadband line or a phone on a carrier network, allocated by an ordinary ISP to an ordinary subscriber, and it looks exactly like a person because, at the network level, it is a person's line. The subscriber is in the pool because an app on their device bundled a proxy SDK for a few cents, because a browser extension sold their bandwidth, because they were paid a little to install a peer, or because their device is infected and was never asked.
That is the whole difficulty. A datacenter address is infrastructure and says so: the cloud publishes its ranges, the operator's name says hosting, the address has no home to be in. A residential proxy is the opposite. Everything the network knows about the address is true — the ISP, the country, the city — and none of it says the request was relayed.
Why no open feed can name one
The signals the IP answer is built from are public, published lists: the clouds' range files, the VPN providers' server lists, Apple's relay egress list, the Tor Project's exit list, the registries' allocation statistics, the threat and attack-source lists. Every one of them is listed, with its terms and its size today, on the data sources pages. Each is published by someone with a reason to publish it, and each names infrastructure, operators or hosts seen doing something.
Nobody publishes a list of subscribers renting out their connection. The ISP does not know, because the traffic is ordinary traffic from an ordinary customer. The proxy seller will not say, because the pool is the product. The subscriber often does not know either. What exists instead is proprietary: vendors that run honeypots and traps, buy access to proxy pools and watch which addresses arrive, or analyse traffic at a scale that reveals a home line behaving like a hundred people. That data is sold under licences that forbid reselling it, it cannot be verified from outside, and it goes stale in days as pools rotate. An address in a rented pool this week is a plain home connection next week.
A "residential proxy score" derived from open data would therefore be a guess dressed as a measurement — and a guess about a person's home connection, which is the one place a false positive does real harm. So the field does not exist. When such a signal ships, it will be a separately labelled field with its own source named in sources, never folded into the weights that make up risk_score.
What the answer says instead
The address has to be a network the feeds know something about, and several fields carry evidence that a policy can weigh without pretending to know what it cannot.
Velocity. seen_by_you counts how many times your own account looked the address up in the last seven days, with the first sighting. A home address that hits your signup form forty times in an afternoon is a fact about your traffic, and it is yours: the count is kept under a keyed hash, never the address, and privacy: true skips it.
Your own lists. An address that already burned you goes on a deny list, and every later lookup answers account_list with denylisted at +100, whatever the feeds say. Office and partner ranges go on an allow list, which zeroes the score. Lists belong to the account and apply to every lookup it is billed for, including bulk runs and monitors.
A clock that disagrees. Send the browser's zone as browser_timezone and timezone_matches answers whether it keeps the same clock as the located zone. A device in one country routed through a home line in another produces a mismatch honestly, and the browser is the half that is hard to fake without noticing. It carries no weight, because travellers and unset laptops produce one too; it is a fact to weigh beside the others.
Outcomes. What you learn afterwards — a chargeback, a confirmed fraud, a scraper — can be reported. Your own reports add reported_abuse at +60 to your later lookups of the address, and once three or more accounts report the same address inside thirty days everyone's lookups carry reported_abuse_widely at +40. Reports are stored as salted hashes, and only the number of reporting accounts is ever read.
Attack-source lists. Some proxy peers are infected machines, and infected machines also scan and brute-force. The three attack-source lists synced hourly name hosts seen doing that in the last days, at +50, and the flag is a checked negative when the lists do not name the address.
What the network really is. connection_type reads mobile when the address belongs to a listed carrier, which means carrier-grade NAT and one address shared by many handsets; hostname_kind reads dynamic when a requested reverse DNS name says pool or DHCP. Both are positive-only, and neither says "proxy". They say what a home or mobile line looks like, which is the baseline everything else is measured against.
Consistency. The cross-signal endpoint compares the IP's country with the phone's numbering plan and the postal address, and says so when they disagree. It withholds the comparison when the address is a VPN exit, a relay or a datacenter egress, because that country is an operator's. A residential proxy passes that filter, which is the point: it is the one case where a plain country mismatch is meaningful, and the report names it as evidence rather than as a verdict.
Building the policy
Three rules fall out of all this.
Build on evidence you can audit. Every field above names its dataset and its date in sources, or is your own account's record. A vendor's proxy score names neither, and when it is wrong about a home connection you will not be able to say why.
Step up rather than block. A velocity spike, a clock mismatch and a country disagreement together are a reason to ask for a confirmed email or a second factor. Each alone is a reason to do nothing.
Keep the feedback loop closed. The reports you send are the one signal in the answer that describes what happened on your site rather than what a feed knows about the Internet. A policy that reports outcomes gets better at your traffic every week; a policy that buys a score does not.
The IP intelligence guide documents every field named here, and the datacenter guide covers the half of the problem that open data does answer.