How Websites Detect Proxies and VPNs

Every time you load a web page, the site learns your IP address. For many sites, that is where the questions start. Is this visitor connecting through a VPN? Is this a home broadband connection, or a proxy running in a data center?

Sites ask these questions for ordinary reasons. Streaming services have to honor regional licensing. Banks and online stores screen for fraud. Ad networks try to filter out fake traffic. And many sites want to tell human visitors apart from automated ones.

What most people don’t realize is that there is no single “proxy check.” Detection works in layers: signals from the IP address itself, from the network connection, from the browser, and from behavior. Each layer contributes evidence, and the site combines it into a judgment. Understanding those layers also explains something that puzzles many people: why two lookup tools can give different answers for the same IP address.

Layer 1: What the IP address reveals

The first and cheapest check happens before a page even loads: looking up who owns the address.

Who owns the address

Every public IP address belongs to a network known as an autonomous system, identified by an ASN. The ASN reveals the organization that announces the address to the internet: a consumer broadband provider, a mobile carrier, a university, or a hosting company. Traffic from hosting providers is the easiest to flag, because very few people browse the web from a rented server. When an address belongs to a large cloud or hosting network, most detection systems treat it as a probable proxy or VPN straight away.

Reputation databases

Commercial IP intelligence providers, such as MaxMind and IP2Location, maintain large databases that classify addresses by usage type, such as residential, mobile, business or hosting, and track which ones are known VPN exit points, open proxies or sources of abuse. Some lists are entirely public: the Tor Project publishes the addresses of its exit relays, so Tor traffic is trivial to identify.

Why residential proxies are harder

Residential proxies route traffic through real consumer internet connections, so the ASN points to an ordinary home ISP. In an IP lookup, the address looks like any other household address. That is why detection increasingly depends on the other layers below.

Layer 2: What the connection reveals

Even when the address looks clean, the way the connection behaves can give an intermediary away.

Proxy headers

Some proxies announce themselves. A transparent proxy may add headers such as Via, X-Forwarded-For or Forwarded (standardized in RFC 7239) to each request, sometimes including the visitor’s original IP address. Proxies that strip these headers are often described as anonymous or elite, but removing headers only hides the most obvious evidence.

TCP/IP fingerprints

Operating systems build network packets slightly differently. Windows, for example, typically starts packets with a time-to-live of 128, while Linux and macOS start at 64, and each system orders its TCP options in its own way. Open-source tools such as p0f have used these differences for passive fingerprinting for years. A site can compare that fingerprint with what the browser claims to be. When traffic passes through a proxy, the proxy server opens the connection to the website, so the site sees the proxy’s network stack rather than the visitor’s. A browser announcing Windows over a connection whose packets look like Linux is a strong hint that something sits in between.

Tunnel overhead

VPNs wrap traffic in an extra layer of encryption, which reduces the largest packet the connection can carry. Detection systems can sometimes infer from the TCP maximum segment size that a connection is running through a tunnel.

Timing

Round-trip times carry information too. Comparing network connection latency with timing measured inside the browser can reveal an extra hop, while unusually high latency for the apparent network connection may suggest that traffic is passing through a relay.

Layer 3: What the browser reveals

A proxy or VPN changes where your traffic appears to come from. It doesn’t change the device, and browsers reveal a great deal about it.

WebRTC leaks

WebRTC, the technology behind browser video calls, can discover a device’s public IP address using STUN requests sent over UDP. If a browser is set to use an HTTP proxy that doesn’t carry UDP traffic, those requests may bypass the proxy and reveal the real address. Modern browsers hide local network addresses by default, but the public address can still leak in some configurations.

DNS leaks

Before connecting to a site, your device looks up its address through a DNS resolver. If those lookups go to your ISP’s resolver instead of through the VPN, the site can find out. A common technique is to load a resource from a unique subdomain and check which resolver asked for it. A VPN connection paired with a resolver that belongs to an unrelated ISP can indicate that DNS traffic is bypassing the VPN.

Time zone and language

JavaScript can read the device’s time zone, and every request carries an Accept-Language header. When the apparent network information does not align with the device’s time zone or language settings, it is not proof of anything on its own, but it is exactly the kind of inconsistency detection systems may weigh.

Location permissions

If a visitor grants location access, the browser’s geolocation can be compared directly with the location of the IP address.

Layer 4: What behavior reveals

Finally, sites watch what visitors do. Many sign-ups from one address, hundreds of requests per minute, or navigation no person would produce all raise suspicion. These signals matter more for bot detection than for spotting individual VPN users, but they feed the same risk scores.

Why different tools give different answers

If you check the same IP address in several lookup tools, you’ll often see disagreement. One database calls it residential, another labels it hosting, a third flags it as a VPN. That is normal, and there are good reasons for it.

• Different data sources: Each provider builds its database from its own mix of registry records, network measurements, partner data and user reports.
• Update cycles: IP addresses change hands constantly. A range sold by a hosting company to an ISP can keep its old label for months.
• Shared addresses: Mobile carriers and many ISPs use carrier-grade NAT, where hundreds of customers share one public IP address. Blocking such an address risks blocking many real users, so providers label and score these addresses cautiously.
• Legitimate relays: Corporate VPNs can route employees’ traffic through shared network infrastructure, causing many users to appear under the same public IP address. Some privacy services also provide information that helps networks identify their relay traffic. Apple, for example, publishes IP address ranges used by iCloud Private Relay and provides guidance for network operators on handling that traffic while supporting approximate location information.

This is also why good detection systems produce a score rather than a verdict. A single signal is rarely conclusive. A hosting ASN, a WebRTC mismatch and a time zone conflict together make a strong case; any one of them alone might simply be a traveler, a remote worker or a privacy-conscious user.

Checking what your own connection reveals

You can run most of these checks on yourself:

• Look up your IP address and note the ISP, ASN, and usage type reported.
• Run a WebRTC leak test and confirm the address it shows matches your IP lookup.
• Run a DNS leak test to see which resolvers answer your lookups.
• Compare your device’s time zone and browser language with the location of your IP address.

If you connect through a proxy or VPN, all four should tell the same story. If they don’t, sites can see the mismatch as easily as you can.

For developers, the same principle applies to testing and research. A proxy changes only the network origin; everything else about the request, from language headers to the client software, still has to be consistent with it. Practical guides to proxy configuration and troubleshooting can provide technical context for setup in curl, Python, and Playwright, including authentication and common connection errors.