VPN and proxy detection is inference, not lookup. No API can see inside a connection and confirm that a tunnel exists. What it can do is check what an address is registered as, what has been observed coming out of it, and how recently. The flag you get back is a conclusion drawn from that evidence, and it inherits every weakness the evidence has.
Most integrations skip past this. They read one boolean, branch on true or false, and ship. Then the support tickets start: a customer on a mobile network gets blocked at checkout, a contractor on a corporate laptop cannot reach the admin panel, and someone running a residential proxy walks through untouched.
This covers where detection signals come from, why they fail in both directions, and how to weight a result instead of trusting it.
How does an API detect if an IP is a VPN or proxy?
A proxy detection API combines four kinds of evidence: network registration data showing who owns the address block, reverse DNS naming, active probing for open proxy services, and lists of known exit nodes that are either published or bought. None of it observes your user’s traffic. Every signal describes the address, not the session.
Registration and routing data. Every block of addresses is allocated to an autonomous system and recorded with a regional internet registry. A block registered to a hosting company behaves nothing like one registered to a residential broadband ISP. Commercial VPN providers rent capacity from hosting companies, so their exit addresses sit inside hosting networks. This is the most durable signal available, because renumbering is expensive and registry records move slowly.
Reverse DNS. PTR records often expose the operator directly. Naming patterns that follow a datacentre allocation scheme are weak alone and useful as corroboration.
Active probing. Scanners open connections to common proxy ports and see what answers. An HTTP proxy on 3128 or 8080, or a SOCKS listener on 1080, gives itself away by protocol behaviour. This is what allows a proxy to be classified by type rather than only flagged.
Published and purchased lists. Tor is the outlier here. The network publishes its consensus, so exit nodes are known rather than guessed at. Commercial VPN exits get catalogued the slow way, by subscribing to the services and recording the addresses they hand out. That works, and it always trails provider rotation by some margin.
A fifth signal, concentration, comes from watching volume rather than configuration. An address carrying thousands of unrelated sessions is doing something other than serving one household.
What the IPstack security object returns
IPstack returns detection signals in a security object appended to the standard geolocation response, enabled by adding security=1 to the request. The object separates three things that matter separately: the finding, the classification, and the recency. That structure is the useful part.
curl "https://api.ipstack.com/103.3.61.114?access_key=YOUR_ACCESS_KEY&security=1"
The security object is gated to a paid tier (details below), so a free key will not receive the block that follows. This is the documented response for 103.3.61.114, an address used by the Tor system:
"security": {
"is_proxy": false,
"proxy_type": null,
"is_crawler": false,
"crawler_name": null,
"crawler_type": null,
"is_tor": true,
"threat_level": "high",
"threat_types": [
"tor"
],
"proxy_last_detected": null,
"proxy_level": null,
"vpn_service": null,
"anonymizer_status": null,
"hosting_facility": false
}
Look at the first two lines. is_proxy is false and is_tor is true. Any integration that branches only on is_proxy passes a Tor exit node straight through to checkout. One documented response is enough to kill the single-boolean approach.
Here is what each field is actually derived from, and how much a detection decision should lean on it:
|
Field |
Derived from |
Weight it carries |
|
is_tor |
Tor’s published consensus of exit nodes |
High. This is a list, not an estimate |
|
hosting_facility |
Registry and routing records for the address block |
High as a fact, low as intent. Says where, not why |
|
is_proxy |
Active probing and observed behaviour |
Medium. Accurate when it fires, silent on private setups |
|
proxy_type |
Protocol response during probing |
Medium. Only populated when is_proxy is true |
|
vpn_service |
Enumeration of commercial VPN provider exits |
Medium. Names the provider, trails rotation |
|
anonymizer_status |
Age and category of the last positive proxy test |
Medium. This is the recency dimension |
|
proxy_last_detected |
Date of the last confirmed observation |
High for decay logic. A stale date is a weak flag |
|
proxy_level |
Degree of concealment offered by the proxy |
Medium. Useful for separating deliberate hiding from ordinary routing |
|
threat_level, threat_types |
Aggregate of the above plus abuse reporting |
Medium. A summary, not a primary input |
|
is_crawler, crawler_name, crawler_type |
Bot fingerprinting |
High for traffic classification, separate from anonymity |
Before comparing proxy_type, proxy_level or anonymizer_status as strings, check the permitted values in the Response Objects section of the IPstack API documentation. A mistyped string comparison never throws. It silently scores zero, a failure mode you will not catch in testing.
Which plan exposes these fields
The Security Module is plan-gated. The IPstack documentation states it is available to customers on the Professional Plus plan, the 2,000,000 requests per month tier on the ipstack.com pricing page. The same tier is listed as Enterprise on the IPstack product page, so confirm against your own dashboard rather than the plan name. Lower tiers do not return the security object at all.
The free tier is capped at 100 requests and covers location data only. Requesting a module your plan does not include returns error 301, and so does expecting security fields without setting security=1. Keep test scripts to single lookups on a small quota. A loop over a list of addresses exhausts 100 requests in seconds.
IPstack sits on the APILayer suite, so one account, one API key, one dashboard and one invoice also cover the other APIs in the suite.
Why VPN detection produces false positives
False positives happen because ordinary network architecture looks identical to deliberate concealment from outside the connection. Carrier-grade NAT, corporate gateways, default-on privacy relays and reassigned hosting ranges produce the same evidence a commercial VPN does.
Carrier-grade NAT. Mobile operators put thousands of subscribers behind a small pool of public addresses. To a detector watching concentration, that is indistinguishable from a shared proxy. Every one is a real customer on a normal phone.
Corporate egress. Company traffic routed through a central gateway, a SASE platform or a zero trust broker leaves from a hosting network. The tunnel is real and the intent is legitimate. A remote employee opening your dashboard trips the same signals a fraud ring does.
Privacy relays. Consumer operating systems now ship relay features enabled by default. The user did not choose to hide anything and often does not know the feature exists.
Recycled address space. Hosting ranges get reassigned constantly. A block that hosted VPN exits eight months ago may now serve an ordinary business. That is what proxy_last_detected is for. A detection from last week and a detection from two years ago should not produce the same decision, and if you ignore the date they will.
Why detection misses real VPNs
False negatives happen because some concealment leaves no signature at the IP layer at all.
Residential proxies. These route traffic through real consumer connections, usually recruited through SDKs bundled into free apps. The exit address belongs to a genuine broadband ISP with genuine residential registration. There is nothing at the address level to find, which is precisely why this market exists.
Self-hosted tunnels. One person running WireGuard on a rented server is on a hosting network but on nobody’s commercial VPN list. hosting_facility will usually catch the range. vpn_service will not, because there is no service to name.
Fresh rotation. Providers add capacity faster than enumeration confirms it. New exit addresses stay clean for a window that varies by provider.
So the honest answer is no. Any tool that sets out to detect VPN by IP is reading registration and observation data, never traffic, and that ceiling is structural rather than a gap a vendor will close.
Weighting a result instead of trusting it
Treat the response as evidence with different strengths, then decide. The pattern below scores rather than branches, which is the only structure that survives contact with real traffic.
import os
import requests
ACCESS_KEY = os.environ["IPSTACK_ACCESS_KEY"]
def fetch_security(ip):
response = requests.get(
f"https://api.ipstack.com/{ip}",
params={"access_key": ACCESS_KEY, "security": 1, "fields": "ip,security"},
timeout=5,
)
response.raise_for_status()
payload = response.json()
if payload.get("success") is False:
error = payload["error"]
raise RuntimeError(f"ipstack {error['code']}: {error['info']}")
return payload.get("security") or {}
def risk_score(security):
score = 0
if security.get("is_tor"):
score += 60
if security.get("is_proxy"):
score += 30
if security.get("vpn_service"):
score += 25
if security.get("anonymizer_status"):
score += 15
if security.get("hosting_facility"):
score += 15
if security.get("threat_level") == "high":
score += 20
return min(score, 100)
The weights are a starting point, not a recommendation. Tune them against your own confirmed fraud outcomes, because the right value depends on what you are protecting.
Three rules make the difference between a score that works and one that generates tickets.
Decay old detections. Read proxy_last_detected and reduce the contribution as the date recedes. Confirm the date format from a live response on your plan before parsing it.
Never let one signal reach a blocking threshold on its own. hosting_facility alone means the address is in a datacentre, which describes a large share of legitimate corporate traffic. Require corroboration.
Match the action to the score. Low scores pass. Middle scores get friction: a second factor, a delayed payout, a review queue. Only the top band blocks. ip address threat detection is worth far more as a routing input than as a gate, because friction on a false positive costs a few seconds while a block costs the customer.
Start detecting VPNs and proxies with IPstack
Detection is only as good as the reading you give it. IPstack returns the finding, the classification and the recency as separate fields so you can weight them, and the integrations that hold up in production use all three.
Create your account at https://apilayer.com/products/ipstack/
Frequently asked questions
Why does VPN detection produce false positives?
Because legitimate traffic and deliberate concealment look the same from outside the connection. Carrier-grade NAT on mobile networks, corporate VPN gateways, default-on privacy relays, and reassigned hosting ranges all produce the same signals a commercial VPN does. The detector is reading the address, not the intent behind it.
Can you reliably detect all VPNs by IP address?
No. Residential proxies exit through genuine consumer broadband connections and leave no signature at the address level. Self-hosted tunnels on rented servers appear on hosting networks but on no provider list. Newly rotated exit addresses stay unlisted until enumeration catches up. Address-level detection is a strong signal, never a complete one.
What is the difference between proxy detection and VPN detection?
A proxy forwards application traffic at a specific protocol, so it can be probed directly and classified by type. A VPN carries traffic at the network layer and answers nothing on a proxy port, so it is identified through registration data and provider enumeration instead. IPstack reflects the split with is_proxy and proxy_type on one side and vpn_service on the other.
How accurate is IP-based threat detection?
Accuracy varies by signal, not by vendor. Tor detection is close to exact because the network publishes its exit list. Hosting network identification is highly reliable about the fact and says nothing about intent. Commercial VPN identification is good and always slightly behind rotation. Residential proxy detection is the weakest case. Judge a result by which signal produced it.
Which IPstack plan includes VPN and proxy detection?
The Security Module requires the Professional Plus plan, the 2,000,000 requests per month tier. Free, Basic and Professional keys do not return the security object and will receive error 301 if they request it. Current tiers and limits are on the pricing page.
Try ipstack free
IP-to-location, ASN, ISP, time zone and threat data from one endpoint. Get a key and make your first call in under a minute.
