Proxy Detection with an IP API: A Developer's Guide
Types of Proxies
Not all proxies are the same, and understanding the differences is essential for choosing the right detection strategy.
HTTP proxies are the simplest form: a server that forwards HTTP requests on behalf of a client. Many are open proxies — unintentionally misconfigured servers that anyone can use. They are easy to detect because they appear in open-proxy databases within hours of going online.
HTTPS / CONNECT proxies extend the HTTP proxy model to HTTPS traffic by using the CONNECT tunnelling method. From a detection perspective they are similar to HTTP proxies.
SOCKS4/5 proxies operate at a lower level than HTTP proxies and can tunnel any TCP traffic. SOCKS5 additionally supports UDP and authentication. They are commonly used by automated tools because they are protocol-agnostic.
Residential proxies are fundamentally different from datacenter proxies. A residential proxy network routes traffic through real consumer ISP connections (often via malware, browser extensions, or paid peer-to-peer networks). The exit IP looks like a genuine home user because it *is* a genuine home user's connection. This makes them significantly harder to detect and significantly more expensive to run, which means they are used for higher-value abuse operations.
Rotating / backconnect proxies cycle through a pool of exit IPs on each request or at a configured interval, defeating per-IP rate limiting. The exit IPs are often residential.
Why Proxies Are Used for Abuse
The common thread across proxy abuse patterns is concealment of the true source IP.
- Bot traffic and web scraping — Search engine scrapers, price monitors, and data harvesters use proxy pools to avoid IP-based blocking. Each request appears to come from a different source.
- Ad fraud — Fraudulent ad clicks and impressions are generated through proxy pools to bypass geolocation and fraud detection rules.
- Credential stuffing and account creation fraud — Attackers distribute login attempts or account registrations across proxy pools to defeat per-IP rate limiting.
- Geo-bypass — Users (and automated clients) use proxies to appear to be in a different country, bypassing geo-restricted content, pricing, or services.
How IP APIs Detect Proxies
BGP/ASN data is the most reliable source for datacenter and commercial proxy detection. When an IP address is routed through an ASN that is registered to a known proxy provider, or that shows the traffic patterns of a proxy network (many distinct source IPs, high volume, geographically dispersed customers), the ASN is flagged.
Known proxy range databases — Organisations like the Spamhaus Project, Project Honey Pot, and commercial providers publish and update lists of known open proxies and proxy networks. Predax aggregates these and updates them continuously.
Datacenter CIDR blocks — Cloud and hosting providers publish their IP ranges (AWS publishes ip-ranges.json, GCP publishes cloud.json, etc.). An IP in one of these ranges that is not associated with a legitimate cloud service is a strong proxy candidate.
Behavioural fingerprinting — Traffic patterns characteristic of proxy infrastructure (uniform user-agent strings, no browser fingerprint, TCP/IP stack anomalies) are flagged by heuristic analysis.
Residential Proxies: The Harder Problem
Residential proxy detection relies on confidence scoring rather than definitive flags. Because the exit IP is a real consumer ISP address, you cannot simply check it against a datacenter range list.
Detection approaches include:
- Velocity analysis — A residential IP that generates 50,000 requests per day across multiple Predax customers is almost certainly a residential proxy node, not a real user.
- Peer-to-peer network ASN fingerprinting — Some residential proxy providers (Luminati/Bright Data, Oxylabs, Smartproxy) have known ASN distributions that can be probabilistically identified.
- Community reputation aggregation — When multiple customers flag the same IP for abuse within a short window, confidence in proxy classification increases even without a definitive ASN match.
For residential proxies, use the classification.risk_score field alongside classification.is_proxy — a score above 60 on a residential-looking IP is a meaningful signal even if is_proxy is false.
Making the API Call
curl
curl -s -X POST "https://predax.io/api/v1/check/ip" \
-H "X-API-Key: prdx_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"ip": "91.108.4.1"}'Python
import httpx
def check_ip(ip: str) -> dict:
r = httpx.post(
"https://predax.io/api/v1/check/ip",
headers={"X-API-Key": "prdx_YOUR_KEY"},
json={"ip": ip},
timeout=2.0,
)
r.raise_for_status()
return r.json()
def is_proxy_risk(ip: str) -> bool:
result = check_ip(ip)
classification = result.get("classification", {})
# Hard proxy flag OR high risk residential
return classification.get("is_proxy") or classification.get("risk_score", 0) >= 60Legitimate Privacy Tools vs. Abuse
Not every proxy user is a bad actor. Privacy-conscious users, journalists, researchers, and people in countries with internet censorship have legitimate reasons to use proxies. Hard-blocking all proxy traffic will frustrate a meaningful portion of your user base.
A tiered response is more effective:
| Signal | Appropriate response |
|---|---|
| Datacenter proxy, high risk score | Block at login; block at checkout |
| Known open proxy | Block at login; hold order for review |
| Commercial VPN, moderate risk | Challenge with MFA at login; flag order |
| Residential proxy (probable) | Log and monitor; apply stricter rate limits |
| Low-risk VPN, no other signals | Allow; tag session for analytics |
Recommended Approach by Use Case
Login protection: Block datacenter proxies (open proxies + datacenter range, risk score 65+) outright. Challenge known commercial proxies/VPNs with MFA. This stops automated credential stuffing while allowing the small fraction of legitimate users who genuinely use a VPN.
Checkout fraud: Block datacenter proxies at payment. Flag and hold orders from commercial proxies for manual review. The asymmetry of fraud cost versus false-positive cost justifies a lower threshold here than at login.
API access: Block open proxies and Tor (high abuse potential). Rate-limit datacenter IPs more aggressively than residential IPs. Do not block commercial VPNs outright unless your terms of service prohibit them — many legitimate API consumers use corporate VPNs.
Content geo-restriction: Use classification.is_proxy: true OR classification.is_vpn: true as the primary signal, supplemented by classification.risk_score >= 40 for probable residential proxies. Accept a small false positive rate (legitimate travellers using VPNs) as unavoidable.
Related guides
- Residential vs datacenter proxies — the most important categorisation to get right when acting on proxy hits.
- How to detect VPN users — VPN is a proxy subtype; same API, different threshold guidance.
- Blocking Tor users — Tor exits are proxies too, but warrant their own policy.
- How IP risk scoring works — turning multiple proxy signals into a single score.
- ASN-based blocking explained — bulk-blocking proxy ASNs without per-IP overhead.
See pricing to start scoring proxies in production.
