Detect VPN and proxy
Check one IP and learn whether it sits in a datacenter or hosting range instead of a home or mobile connection, the infrastructure most commercial VPNs, proxies and bots rent. Pay per use, no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
Not every visitor is who their IP suggests, and telling a home or mobile connection apart from a rented datacenter address changes how you should treat that request.
Why a server address matters
Homes and phones get their addresses from residential and mobile internet providers. Servers get theirs from hosting companies and cloud providers. Real browsers rarely run from a rented server, but scrapers, automated tools and most commercial VPNs and proxies do exactly that. So when a visitor who looks like an ordinary shopper arrives from a hosting range, that mismatch is worth knowing. The check reads how the address block is registered and which operator holds it, and tells you whether it belongs to that kind of server infrastructure. It looks at the connection only, not at the content of a message or a page.
How to use the answer sensibly
Treat it as one signal, not a verdict on the person. Plenty of honest traffic comes through datacenter addresses for privacy or company network policy. Use it to add a step, such as extra verification at signup, to flag repeated coupon signups, to decide how strictly to apply location rules, or to rank orders for manual review alongside other signals. Keep in mind that it classifies the infrastructure: it does not name a specific VPN service, and it is not a reputation list of bad addresses.
What the check tells you
The response indicates whether the IP belongs to a known datacenter, hosting or cloud range, based on how that particular block is registered and the operator that holds it. Plenty of legitimate traffic comes through datacenter IPs for entirely ordinary reasons like privacy or corporate network policy.
Why datacenter ranges get flagged at all
Residential and mobile ISPs allocate addresses to homes and phones; hosting providers and cloud platforms allocate addresses to servers instead. Traffic claiming to be an individual shopper but originating from a hosting range is a mismatch worth knowing about, since real browsers rarely run from server infrastructure — automated tools, scrapers, and the VPNs and proxies that ride on rented servers often do exactly that.
What you can do with it
Signup abuse prevention
Add friction or extra verification to account creation attempts coming from datacenter or hosting ranges known for automated abuse.
Promo and coupon integrity
Reduce coupon farming by flagging repeated signups routed through datacenter or hosting infrastructure.
Content licensing enforcement
Spot when a request arrives from a datacenter range rather than a home connection — where most commercial VPNs exit — informing how strictly to enforce location-based rules.
Checkout risk layering
Combine the datacenter and hosting signal with other signals to prioritize which orders get manual review.
FAQ
How does this vpn detection api actually work?
It checks the IP behind a request against known datacenter, hosting and cloud address ranges, identified by the operator that holds each block, and returns whether it's a server range rather than a residential or mobile connection. It does not label a specific VPN service, proxy, or Tor node by name.
Does it detect every VPN, proxy or Tor node?
No. It flags datacenter and hosting ranges, which is where most commercial VPNs and proxies are hosted, so it catches many of them indirectly. But it doesn't identify VPN or proxy services by name, and a VPN on a residential IP, a residential proxy, or Tor traffic exiting through a non-datacenter range can appear as ordinary residential traffic.
Is datacenter traffic always bad?
No. Plenty of legitimate users route through datacenter IPs — VPNs for privacy, corporate networks — so this signal is meant to inform a decision, not replace one; most teams combine it with other risk signals instead of blocking outright.
Is it free to use?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
Is my data retained after the check?
No, results are deleted once the retention window closes and are never used for training.
What if a check fails?
It retries automatically up to three times before returning a clear error, and failed requests are never billed.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/verify/ip-vpn \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"ip":"8.8.8.8"}'const res = await fetch("https://api.kit.forhosting.com/verify/ip-vpn", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"ip": "8.8.8.8"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/verify/ip-vpn",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"ip": "8.8.8.8"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/ip-vpn", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"ip":"8.8.8.8"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"ip":"8.8.8.8"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/ip-vpn", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"ip": "8.8.8.8"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "verify.ip_vpn",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This endpoint flags whether the IP behind a request belongs to a datacenter or hosting range — the kind of infrastructure real browsers rarely use, but bots, scrapers and most commercial VPNs and proxies run on — so you can apply different rules to different kinds of traffic without guessing.
The gap between an IP and the person using it
A commercial VPN, a proxy service or an automated bot typically runs on rented server infrastructure, which means a request arriving from a datacenter or hosting range often has nothing to do with a person browsing from home, what device they're using, or which network they normally connect from. That gap is normal and often entirely legitimate — but for signup, checkout or content decisions, simply knowing the request came from server infrastructure rather than a residential or mobile connection changes what you should reasonably do next.
What the check tells you
It's a classification of the infrastructure the request came from — a server range versus a residential or mobile ISP — not a judgment about the person behind it, and not a per-service label naming a specific VPN, proxy or Tor node.
A layer, not a verdict
This kind of signal has grown alongside the anonymization tools themselves: as VPNs and proxies became mainstream for everyday privacy, and as most of them came to run on rented datacenter IPs, services that classify IP infrastructure became a standard input for fraud and abuse systems, sitting alongside other signals like device fingerprints and account history rather than replacing them outright.
How it plugs into a decision pipeline
Most integrations combine it with account history or behavioral signals rather than blocking on it alone, since a datacenter or hosting flag by itself is rarely enough to justify a hard rejection of an otherwise normal request. Send the IP, get a task_id, and receive the classification via your signed webhook or a signed link valid for 24 hours, whichever suits your setup.
Technical questions
Can I check IPs in bulk?
Each call classifies one IP; for higher volume, send one request per IP and let the async queue process them in parallel.
How fast do I get results?
A task_id returns immediately, and the classification arrives via your signed webhook or a signed link valid for 24 hours.