How to Interpret IPinfo's VPN and Hosting Signals: A Classification Framework

This framework started as a customer conversation. While helping a client interpret IPinfo’s VPN, I realized something: many teams face the same challenge. They see VPN or hosting flags in their data, but aren’t sure how to translate them into meaningful, context-aware actions. This thought evolved into the framework below.

When it comes to classifying traffic, binary decisions rarely work. Block all VPNs, and you’ll frustrate remote employees and privacy-conscious users. Allow everything that isn’t datacenter-based, and sophisticated VPN or automation traffic will slip through.

The goal of this framework isn’t to decide between “block all” or “allow all.” It’s to understand what the signals are actually telling you, so you can make decisions that reflect your business context, user base, and risk tolerance.

Important note: Every organization’s situation is different. What follows is a guiding framework, not a prescription. It’s designed to help you interpret IPinfo’s signals in a structured way, then adapt them to your own use case.

IPinfo's Plus provides three key signals that, when combined, create a nuanced picture of traffic origins:

• is_hosting: Is this IP from a datacenter or hosting provider?
• anonymous.is_vpn: Do we detect VPN protocols or behavior on this IP?
• anonymous.name: Can we identify the specific VPN provider (e.g., "NordVPN", "ExpressVPN")?

These signals combine to create five distinct categories of traffic, each with different characteristics and implications for your security and business policies.

The Five Categories Explained

1. Hosting + VPN, No Service Identified

Signals:

{   "is_hosting": true,   "anonymous": {     "is_vpn": true,     "name": null   } }

What it is: These are IPs in datacenter or hosting networks where we detect VPN protocols, but we haven't identified a specific commercial VPN provider. This typically includes self-hosted VPNs running on VPS instances, newly-launched VPN services not yet in our database, or unknown VPN infrastructure.

Examples:

• Someone renting a DigitalOcean droplet to run their own OpenVPN server
• Small VPN providers we haven't cataloged yet
• Custom VPN infrastructure for specific purposes

Characteristics: These IPs often indicate deliberate infrastructure setup. Users in this category have typically made an active choice to configure their own VPN rather than using a commercial service, which can signal different intent depending on your use case.

2. Non-Hosting VPNs, No Service

Signals:

{   "is_hosting": false,   "anonymous": {     "is_vpn": true,   } }

What it is: IPs where we see VPN activity but they're not associated with hosting providers or known commercial services. These are often legitimate privacy use cases.

Examples:

• Corporate VPN tunnels from office locations
• Residential users running personal VPN protocols

Characteristics: This is where most false positives occur when organizations apply blanket VPN blocks. This category represents users who are typically protecting their privacy in legitimate contexts rather than attempting to evade detection or violate policies.

3. Hosting + VPN + Known Service

Signals:

{   "is_hosting": true,   "anonymous": {     "is_vpn": true,     "name": "NordVPN"   } }

What it is: Traditional commercial VPNs operating from datacenter infrastructure. These are the well-known consumer VPN services running servers in hosting facilities.

Examples:

• NordVPN, ExpressVPN, Surfshark, Private Internet Access
• VPN exit nodes in standard datacenter locations
• Any commercial VPN provider using traditional hosting infrastructure

Characteristics: These users are deliberately masking their location using mainstream commercial services. Their intent varies widely: from privacy protection to geographic restriction bypass to fraud attempts. The name field provides visibility into which specific provider is being used, which can inform your policy decisions.

4. Hosting IPs Without VPN Flag

Signals:

{   "is_hosting": true,   "anonymous": {     "is_vpn": false   } }

What it is: IPs from datacenters or hosting providers where we don't specifically detect VPN protocols. This is the most diverse category.

Examples:

• AWS servers running legitimate web services
• Cloud-hosted APIs and applications
• Scraping and automation tools
• Bot traffic (both malicious and legitimate)
• ISPs that also provide hosting services
• CDN nodes

Characteristics: This category requires the most nuanced interpretation because datacenter IPs serve many legitimate purposes. Legitimate services and automation exist alongside potentially problematic actors. The key is that hosting infrastructure alone doesn't indicate VPN usage, many legitimate business operations originate from datacenters.

5: Commercial VPNs Outside Hosting Ranges

Signals:

{   "is_hosting": false,   "anonymous": {     "name": "VPNGate",     "is_vpn": true   } }

What it is: This category includes commercial and peer-to-peer (P2P) VPN services operating from ISP or residential networks instead of datacenters. Rather than using centralized hosting, these VPNs route traffic through volunteer or leased residential nodes, often blending in with ordinary consumer traffic.

Examples:

• P2P or community VPNs such as VPNGate or community relays
• Commercial VPNs leasing IP space directly from residential or business ISPs
• Hybrid infrastructures mixing datacenter and residential exit nodes

Why it matters: These networks intentionally avoid hosting-based detection by appearing as normal consumer traffic. From a classification perspective, this category represents an early form of the same principle later expanded by Residential Proxy networks: routing traffic through consumer or ISP-based IP space to appear as ordinary residential users. Residential proxy systems take this idea further, industrializing and automating it at scale across millions of devices.

Characteristics

• Hardest to detect using standard hosting or ASN-based filters
• Often indicates deliberate intent to evade simple infrastructure checks
• Increasingly common among privacy-focused or evasion-oriented VPN providers

Key Considerations for Policy Development

The appropriate response to each category depends entirely on your specific business requirements, risk tolerance, and user base. A streaming platform enforcing content licensing has different needs than a SaaS application serving remote workers, which differs from a fraud prevention system.

When interpreting these signals for your use case, consider:

Business Context. What is your primary concern? Geographic licensing compliance? Fraud prevention? Bot management? Data quality? Different concerns weight these categories differently.

User Base. Do you serve international travelers? Remote workers? Privacy-conscious users? Your legitimate user patterns should inform how you interpret each category.

Risk Tolerance. How much false positive rate is acceptable? High-security environments may accept more false positives than consumer-facing platforms.

Layered Signals. These VPN/hosting signals work best when combined with other indicators: account history, behavioral patterns, device fingerprints, and transaction characteristics.

Best Practices for Signal Interpretation

Start with Understanding, Not Action

Before implementing any policies, analyze your traffic distribution. Understanding your baseline helps you make informed decisions.

Log Category Information

Even when not taking action, logging which category each IP falls into provides valuable insights for:

• Understanding your traffic composition
• Detecting emerging patterns
• Investigating incidents retroactively
• Refining policies over time

Consider Account Context

A known, trusted account exhibiting commercial VPN signals tells a different story than a brand-new account with self-hosted VPN in a datacenter.

Communicate Clearly

If your policies result in blocking or additional verification, clear communication helps users understand what's happening and reduces support burden.

Measure and Iterate

Track metrics like:

• False positive rates (legitimate users being blocked)
• False negative rates (problematic traffic getting through)
• Support ticket volume related to access issues
• Conversion or usage impact

Real-World Complexity

These five categories provide a framework for interpretation, but different scenarios often require nuance:

• A non-hosting VPN might be a corporate office that also runs a small hosting business
• A hosting without VPN IP could be a legitimate monitoring service or a sophisticated scraper
• A known good user suddenly appearing on commercial VPN might be traveling for work
• Multiple failed login attempts from self-hosted VPN carries different weight than a single successful login from a long-standing account

The signals provide context: how you use that context depends on your specific requirements and risk profile.

Acting on IP Data Context

Effective interpretation of VPN and hosting signals isn't about binary classification: it's about understanding context. By recognizing the five distinct categories created by IPinfo's three core signals (is_hosting, is_vpn, service), you can distinguish between:

• Deliberate evasion infrastructure
• Legitimate privacy protection 
• Mainstream commercial VPN usage
• General datacenter operations 

It’s also important to recognize how these categories continue to evolve. Commercial and P2P VPNs operating from ISP-based networks paved the way for today’s residential proxy ecosystems, which scale the same concept through distributed consumer devices.

As anonymization infrastructure becomes more decentralized, continuous measurement and interpretation become essential for maintaining accuracy.

The right interpretation depends on your use case while the foundation remains the same: IPinfo provides the data and evidence; how you interpret and act on it should reflect your specific business context, user base, and risk tolerance.