How to check if an IP address is a VPN, proxy, or Tor exit
A signup arrives, a checkout fires, a login lands from a new country, and something has to decide in a few hundred milliseconds whether the address behind it is a person at home or a rented exit hiding one. Here is what actually separates a VPN, a proxy, a Tor exit and a plain datacenter address, where each signal comes from, and why a single yes is worth less than it looks.
What "proxy" means to a risk engine
The question a fraud team is really asking is not academic. It is: can I attribute this session to a real person in a real place, or is the address in front of me a rented intermediary chosen precisely so that I cannot. Everything else is detail in service of that one decision.
The detail matters because the categories are not the same risk. A commercial VPN is used by millions of ordinary people for ordinary reasons, and blocking it wholesale blocks paying customers. A datacenter address is not a home, but plenty of legitimate automation runs from one. A backconnect proxy or a residential proxy exists mostly to make one session look like an unrelated person somewhere else, which is a much more specific thing to want. A Tor exit is none of the above and its own signal entirely. Collapsing all of these into "anonymised, block it" throws away the information that tells you which ones you can afford to allow.
The signals, and what each is worth
Six verdicts do most of the work, and they are not interchangeable.
| Verdict | What it means | How much to weigh it |
|---|---|---|
| VPN | Address belongs to a commercial VPN service. | Moderate. Common and often innocent; weigh it with what the session is trying to do. |
| Proxy | Address sells forward or backconnect proxy access. | High. The purpose is to disguise origin, which is rarely what a genuine customer needs. |
| Residential / mobile proxy | Home or mobile address resold as a rotating exit. | High, and the hardest to catch, because it looks residential by design. |
| Tor exit | Address published as a Tor exit relay. | High signal, objective, and cheaply verified against the public relay list. |
| Datacenter | Address lives in hosting rather than an access network. | Context, not a verdict. Suspicious for consumer traffic, normal for an API caller. |
| Abuser / blocklisted | Address is carried on abuse feeds or public blocklists. | Depends on which lists and how recently. A count and a date, not a yes. |
The residential proxy row is the one that keeps fraud teams up at night, because it is built to defeat exactly this check. The address is a real home connection, so it geolocates like a person and carries no datacenter signal. What gives it away is rarely the single address; it is the company behind it, the range it sits in, and the pattern of other addresses nearby that have been seen doing the same thing.
Where the answer comes from
There are two fundamentally different kinds of evidence, and it is worth knowing which one you are looking at.
Passive intelligence is what independent feeds have observed and classified: this address behaves like a VPN, this one scores high for fraud, this one appears on four blocklists. It is broad, it is fast, and it is an opinion, however well sourced. Different feeds reach it by different methods and will not always agree.
An active check is a measurement. Rather than ask what a feed thinks, it confirms directly whether the address is answering as a proxy right now. A confirmed proxy is not a classification anyone can argue with; it answered. A clean active result means the address was checked and nothing was found, which is a stronger statement than a feed having no opinion. The two belong side by side: the passive feeds are wide, the active check is certain, and a screening decision is better for having both.
Absence of a passive verdict is not evidence of innocence. Most feeds return the same empty answer for an address they have cleared and for an address they have simply never looked at. Treat "no verdict" as "unknown", not as "clean".
When feeds disagree
Ask several independent feeds about one address and they will sometimes contradict each other: one says VPN, another explicitly says not VPN. The wrong move is to take the first yes and move on, because that quietly turns one feed's guess into a settled fact.
The honest reading has three states, not two. A verdict two or more feeds agree on is solid. A verdict exactly one feed asserts, with none contradicting it, is a lead worth noting but not a conviction. A verdict one feed asserts and another explicitly denies is contested, and contested is information: it usually means the address sits on a boundary, or that the feeds are measuring different moments. A tool that shows you a single yes has hidden the most interesting part of the answer. Look up 1.1.1.1 and you can see the shape of this directly: it is a public resolver, and a feed ticking a VPN box on it while its risk sits at the floor is not a contradiction to panic over, it is the reason a single flag is never enough on its own.
A risk score is not a verdict
Most feeds also return a number, usually zero to a hundred. It is useful and it is routinely misread. A score is a summary of many inputs, so it moves for reasons that have nothing to do with the yes or no you asked about, and two feeds that agree an address is a VPN can score it thirty points apart because they weigh that fact differently.
Keep the verdict and the score as separate columns. A legitimate corporate VPN can be a confident yes on "VPN" and a low number on risk, and both are correct. Use the boolean verdicts to decide what the address is, and use the score to decide how hard to lean on a borderline case, not the other way round.
The address versus the range around it
A single address is a thin piece of evidence. The block it lives in is a much richer one, and it is where the residential proxy operators give themselves away.
If you check one address and it comes back quiet, that tells you about one address. If you check a spread of addresses across the surrounding /24 and six of nineteen come back as proxies at the top of the risk scale, from more than one feed, you have learned something the single lookup could never show you: this is dense, not incidental. Density across addresses picked at random is the signal. One flagged host in a /16 is noise. The same six-in-nineteen pattern is a range you should treat as hostile regardless of what any individual address says this second.
This is also why the operator behind the address matters as much as the address. A range announced by a network whose entire business is selling proxy access is a different risk from the same verdict on a home connection inside a mainstream ISP, even when the two addresses score identically today.
Checking one address, and checking at scale
For a one-off, the front page answers the question: enter the address and read the verdicts, the per feed agreement, the risk, and whether an active check has confirmed a proxy. Every reading carries the date it was taken, so an address that was quiet in March and flagged in July shows both rather than only this morning's answer.
For a risk engine that has to decide in real time, the same report is one HTTP call, and the fields you want are stable. The verdict booleans, the agreement breakdown, the risk score and the confirmed proxy result all arrive in a single JSON response you can key a rule on. Two practical notes: the first lookup of an address the service has never seen is the slow one, and every repeat is served from cache, so screening a stream of returning addresses is fast; and the response tells you plainly when a dataset was still loading, so a rule can wait for certainty rather than act on a half-formed answer.
What a clean result does and does not mean
A clean result narrows risk. It does not remove it, and honest tooling is specific about the difference.
It cannot see private lists. The deny list inside one large retailer, the fraud model trained on a checkout's own eighteen months of traffic, are the ones that matter most to that business and the ones nobody publishes. A public check will never show them.
It is a reading of now, backed by whatever history exists. An address becomes a proxy the day someone points proxy software at it, and it stops being one the day they stop. Reputation lags behavior in both directions, which is the whole reason the date on each reading is part of the answer and not a footnote.
And it is a statement about the address, not the person. It tells you whether the session is arriving through an intermediary built to hide its origin. Whether that matters is your policy to set. What the data can do is make sure the policy is applied to what the address actually is, rather than to a single yes that happened to come back first.
Every address mentioned here can be looked up on the front page. The report shows the date and the source behind each verdict, keeps the feeds that disagree side by side, and says plainly when nobody has checked something.