When a web application receives a request, the IP address is often one of the first pieces of information available to the server.
It is tempting to treat that address as the identity of the client.
In real-world applications, things are rarely that simple.
A request may pass through a CDN, reverse proxy, VPN, corporate gateway, residential proxy, or another intermediary before reaching your application. The IP address visible to your server may therefore represent an intermediary rather than the original user.
This creates an important engineering problem.
How do you determine whether an IP belongs to a normal network, a VPN, a proxy, a residential proxy, a cloud provider, or another type of intermediary?
And more importantly, what should your application actually do with that information?
This article walks through the problem and looks at practical approaches for using IP intelligence in web applications.
What is a proxy IP?
A proxy server sits between a client and the destination server.
A direct connection looks roughly like this:
Client → Your Server
A proxied connection looks more like this:
Client → Proxy → Your Server
Your application sees the proxy's IP address.
That does not automatically make the request malicious.
Proxies have many legitimate uses. Companies may route traffic through centralized gateways. Developers may use proxies for testing. Privacy tools may hide the originating network. Security products may inspect traffic before forwarding it.
At the same time, proxy networks are also commonly used for automated traffic, scraping, account abuse, and other activities that a security team may want to investigate.
That is why detecting a proxy should usually be treated as an intelligence problem rather than a simple block-or-allow rule.
Proxy, VPN, CDN, and corporate gateway are different
One of the first mistakes when working with IP intelligence is putting every intermediary into the same category.
Consider these examples:
| Network type | Typical purpose | What your application may see |
|---|---|---|
| Residential proxy | Route traffic through residential IP addresses | Residential-looking exit IP |
| Datacenter proxy | Route traffic through hosting infrastructure | Datacenter IP |
| VPN | Provide an encrypted or private connection | VPN server IP |
| CDN | Deliver content from distributed infrastructure | CDN edge IP |
| Corporate gateway | Centralize enterprise traffic | Shared corporate egress IP |
These categories can overlap from the perspective of a basic IP lookup, but they are not interchangeable.
A corporate gateway, for example, may represent hundreds or thousands of legitimate employees.
Blocking every address associated with a gateway could therefore cause problems for an otherwise legitimate customer.
Why checking the ASN is not enough
An Autonomous System Number, or ASN, identifies a network on the internet.
ASN information can be extremely useful.
For example, if an IP belongs to a cloud or hosting organization, that can provide context about the type of connection.
But ASN ownership does not tell you exactly how an IP is being used.
A cloud provider can host:
- A public website
- An API
- A monitoring service
- A legitimate business application
- A crawler
- A proxy service
The same network can therefore contain very different types of traffic.
This is why ASN information works better as one signal in a larger IP intelligence system.
The IPGeolocation API documentation includes ASN and network information alongside geolocation and other IP intelligence data.
Residential proxies make detection harder
Residential proxies are particularly difficult to identify using basic network ownership checks.
A simplified setup looks like this:
Automated Client
|
v
Proxy Provider
|
v
Residential Exit IP
|
v
Your Website
Your application sees the residential exit address.
If your detection system only checks whether an IP belongs to a hosting provider, the request may look like ordinary residential traffic.
This is one reason proxy detection needs signals beyond ASN classification.
The current IP Security API can identify proxy and residential proxy signals and can return proxy confidence information and provider names when available.
Look at multiple signals
A better approach is to combine several pieces of information.
For example:
┌── ASN information
│
├── Proxy detection
│
Incoming IP ────────┼── VPN detection
│
├── Bot information
│
├── Abuse information
│
└── Network ownership
Each signal answers a different question.
ASN information can help identify the network that routes the address.
Proxy detection can indicate whether the address is associated with proxy infrastructure.
VPN detection can identify known VPN networks.
Bot signals can provide additional context about automated traffic.
Threat intelligence can indicate whether the address has been associated with suspicious activity.
The result is much more useful than a single boolean such as:
{
"is_proxy": true
}
What about X-Forwarded-For?
There is another problem that developers encounter when implementing IP detection.
Your application may not directly receive the client's connection.
For example:
Internet
|
v
Load Balancer
|
v
Reverse Proxy
|
v
Application
The application server may see the reverse proxy's IP instead of the original client IP.
Infrastructure may therefore add forwarding information such as:
X-Forwarded-For: 203.0.113.42
This can be useful, but it should not be blindly trusted.
A client can potentially send its own X-Forwarded-For header.
For example:
X-Forwarded-For: 1.2.3.4
That does not prove that the request originated from 1.2.3.4.
The safer approach is to trust forwarded IP information only from infrastructure that you control or explicitly trust.
Trusted proxy configuration matters
Consider this architecture:
Internet
|
v
Trusted Load Balancer
|
v
Reverse Proxy
|
v
Application
Your application can be configured to recognize the load balancer and reverse proxy as trusted intermediaries.
Only then should forwarding headers be used to determine the client IP.
This is an infrastructure concern as much as it is an application concern.
If the trust boundary is configured incorrectly, an application may make security decisions based on an IP address supplied by the requester.
Do not make proxy detection a binary security rule
Suppose a login system has this rule:
if proxy:
deny
It looks simple.
It is also likely to create legitimate problems.
A user might be connected through a corporate network.
Another user might use a privacy service.
A business customer might route all employees through a shared security gateway.
A proxy signal alone does not tell you why the proxy is being used.
A more flexible architecture looks like this:
IP Intelligence
+
Account History
+
Request Behavior
+
Authentication Signals
+
Rate Limiting
↓
Risk Assessment
The IP classification becomes one input rather than the entire decision.
Using a threat score
A threat score can make this approach easier to implement.
Instead of receiving only:
{
"is_proxy": true
}
a security API can provide additional context.
The IPGeolocation IP Security API provides a threat score from 0 to 100 along with individual security signals such as VPN, proxy, residential proxy, Tor, bot, spam, known attacker, and cloud provider indicators.
A response can therefore be evaluated using multiple fields:
{
"security": {
"threat_score": 72,
"is_proxy": true,
"is_vpn": false,
"is_tor": false,
"is_known_attacker": false
}
}
Your application can then define its own response to those signals.
For example, it might flag an account for additional verification instead of immediately blocking it.
The appropriate threshold depends on the application and the consequences of a false positive.
Rate limiting is another useful example
Consider an API that limits requests by IP address.
A basic implementation might maintain:
203.0.113.10 → 100 requests/minute
This works reasonably well when each client has its own public IP.
Now consider a corporate gateway:
User A ─┐
User B ─┤
User C ─┼── Corporate Gateway ──→ API
User D ─┤
User E ─┘
All five users may appear to originate from the same IP.
If you blindly apply a per-IP limit, one customer could consume the entire quota for everyone behind that gateway.
The opposite problem can occur with rotating proxies.
An automated client can potentially change its apparent IP address frequently, making a simple per-IP rate limit less effective.
IP classification can therefore help your application understand the network context before applying a rate-limiting strategy.
IP intelligence can improve observability
Proxy detection is not only useful for blocking traffic.
It can also make application logs more useful.
Imagine your analytics system suddenly reports a large increase in traffic from a particular country.
That does not necessarily mean there are suddenly more real users from that location.
The traffic could be coming from:
- A crawler
- A proxy network
- A security scanner
- A cloud workload
- A monitoring service
- A CDN
Adding network classification to your logs provides additional context.
For example:
timestamp
ip
country
asn
organization
network_type
proxy_status
vpn_status
bot_status
request_path
user_agent
When an unusual traffic pattern appears, those fields can help explain what happened.
Using an IP security API
If maintaining your own IP intelligence database is not practical, an API can provide the classification data as part of your application's request flow.
For example, the IP Security API documentation provides a dedicated /v3/security endpoint for security lookups. It supports individual IP lookups as well as bulk lookups.
A simplified architecture looks like this:
Incoming Request
|
v
Extract Client IP
|
v
IP Security Lookup
|
+---- Proxy
|
+---- VPN
|
+---- Tor
|
+---- Bot
|
+---- Threat Score
|
v
Application Rules
The API response should not automatically determine the final action.
Your application should decide what those signals mean in the context of the particular workflow.
Combine geolocation and security data when needed
Security information is often more useful when combined with location and network information.
For example, an application might need to know:
Where is this IP registered?
Who operates the network?
Is it a proxy?
Is it a VPN?
Is it a cloud provider?
Is it associated with suspicious activity?
The IP Geolocation API can provide location information for IPv4 and IPv6 addresses, while security information can be requested when the application needs additional risk signals.
This allows an application to keep the data it needs in a single IP intelligence workflow.
For example:
IP
|
+-- Location
| +-- Country
| +-- City
| +-- Coordinates
|
+-- Network
| +-- ASN
| +-- Organization
|
+-- Security
+-- Proxy
+-- VPN
+-- Bot
+-- Threat Score
Cache results where appropriate
There is another practical consideration when using an external API.
You may not need to perform a fresh lookup every time the same IP appears.
Imagine your application receives:
10,000 requests
from the same IP within a short period.
Making 10,000 identical intelligence requests may add unnecessary latency and API usage.
A cache can change the flow:
Incoming IP
|
v
Cache Lookup
|
Found
|
v
Use Cached Data
If the IP is not cached:
Incoming IP
|
v
Cache Lookup
|
Not Found
|
v
API Lookup
|
v
Store Result
|
v
Use Result
The appropriate cache duration depends on the application.
A security-sensitive workflow may require fresher information than an analytics dashboard.
Do not assume every classification is permanent
IP ownership and network behavior can change.
An address can move between providers.
A network can change how it is used.
A proxy service can add or remove addresses.
A previously ordinary address can later become part of infrastructure used for automated traffic.
For this reason, IP intelligence should be treated as time-sensitive information rather than permanent identity data.
Some security systems provide last-seen information for proxy and VPN signals. IPGeolocation's security response, for example, includes fields such as proxy_last_seen and vpn_last_seen when that information is available.
That context can be useful when investigating an IP that changes classification over time.
False positives are unavoidable
No IP classification system should be treated as perfect.
A legitimate user can be behind a VPN.
A corporate gateway can represent hundreds of employees.
A cloud provider can host completely legitimate applications.
A residential network can be involved in proxy infrastructure.
This is why a system that immediately blocks every IP matching one signal can create unnecessary friction.
A better design is to define actions around the confidence and context of the detection.
For example:
Low concern
↓
Allow
Some risk
↓
Monitor / rate limit
Higher risk
↓
Additional verification
Confirmed abuse
↓
Block / investigate
The exact rules should be based on the application's risk tolerance.
IP addresses are not user identities
This is perhaps the most important concept when building IP-based security systems.
An IP address can represent:
- One device
- Multiple devices
- An entire office
- A mobile network
- A cloud server
- A VPN endpoint
- A proxy exit node
- A CDN edge
- A corporate gateway
Two users can share an IP.
One user can appear behind several IP addresses.
An IP address can also change over time.
Therefore, IP intelligence is most useful as a signal about a connection or network, not as a permanent identity for a person.
A practical architecture
For an application that needs IP intelligence, the architecture can remain relatively simple:
Incoming Request
|
v
Trusted Proxy Check
|
v
Extract Client IP
|
v
IP Intelligence
|
┌──────────────┼──────────────┐
| | |
v v v
Location Network Security
| | |
└──────────────┼──────────────┘
|
v
Application Rules
|
v
Logging
The important design choice is keeping IP intelligence separate from application rules.
Your application can then change its policy without replacing the underlying IP intelligence system.
For example, the same data could initially be used for analytics and rate limiting. Later, it could become one signal in a fraud detection workflow.
When should you use a dedicated security lookup?
A dedicated security lookup makes sense when the application primarily needs threat intelligence.
For example:
Is this IP a proxy?
Is this IP a VPN?
Is this IP a Tor exit node?
Is this IP associated with a bot?
Is this IP a known attacker?
What is its threat score?
The dedicated IP Security API is designed around these types of questions.
If your application also needs location, ASN, company, timezone, or other IP information, the broader IP Geolocation API can provide those additional modules.
There is also a Real-Time Proxy and VPN Detection API designed for client-side detection at points such as signup, login, and checkout. Its response separates public IP information from the live VPN or proxy verdict and can include additional information about the visitor's actual location.
Final thoughts
Detecting proxy IPs is more complicated than checking whether an address belongs to a hosting provider.
Modern web traffic can pass through several layers before reaching an application.
CDNs, reverse proxies, VPNs, corporate gateways, cloud infrastructure, and residential proxy networks can all change what your server sees.
A practical implementation therefore starts with a few principles:
- Understand your proxy and forwarding architecture.
- Trust forwarding headers only from known infrastructure.
- Use ASN ownership as a signal rather than a final conclusion.
- Distinguish proxies, VPNs, corporate gateways, and cloud networks.
- Combine IP intelligence with application-level signals.
- Cache results when the use case allows it.
- Consider confidence and freshness when making decisions.
- Avoid treating an IP address as a user identity.
The goal is not to determine whether every IP is "good" or "bad."
The goal is to understand the network behind a request well enough to make a better application decision.
That distinction becomes increasingly important as more legitimate users and automated systems operate through intermediary networks.
Top comments (0)