How Websites Detect Proxy Servers — And Why Most Proxies Are Easier to Spot Than You Think
A technical deep-dive into proxy detection methods, from cheap tricks to sophisticated TCP fingerprinting — and what it means for scrapers, multi-account operators, and anyone who relies on staying anonymous online.
Valentin Ghita
Technical Writer, Marketing, Research
Mihalcea Romeo
Co-Founder, CTO
Proxies are not as invisible as the vendors selling them want you to believe.
That's not cynicism - it's just how the network stack works. Every connection leaves fingerprints, and detection systems have gotten very good at reading them. Whether you're running scraping pipelines, managing multiple accounts, or just trying to understand what proxy detection actually involves under the hood, the picture is more nuanced than "use a residential proxy and you're safe."
Let's break down exactly what's happening.
Buy Rotating Mobile Proxies
Real 4G/5G IPs that rotate automatically. Highest trust score of any proxy type.
What Is Proxy Detection, Really?
Proxy detection is the set of techniques websites, fraud prevention systems, and bot mitigation platforms use to identify whether an incoming connection is routed through an intermediary rather than coming directly from a real user's device.
It's not a single check. It's a layered stack of signals - each one probabilistic on its own, but increasingly damning in combination.
Detection systems generally operate at two levels:
- Network-level signals - IP reputation, ASN classification, TCP behavior, routing anomalies
- Application-level signals - Browser fingerprinting, JavaScript execution patterns, canvas/WebGL inconsistencies, font rendering
This article focuses primarily on the network layer, because that's where most proxies are caught - before the browser even loads.
The Low-Hanging Fruit: IP Reputation and ASN Classification
The simplest method to detect a proxy server is to check who owns the IP address.
Most datacenter proxies and cheap ISP proxies come from IP ranges owned by hosting providers - AWS, Hetzner, DigitalOcean, OVH, Vultr, and a few dozen others. These ASN ranges are well-known, publicly listed, and maintained in commercial databases like IP2Proxy, MaxMind, and ipinfo.
| IP Type | Detectable by ASN lookup? | Confidence |
|---|---|---|
| Datacenter proxy | Almost always | Very high |
| Shared ISP proxy | Usually | High |
| Dedicated ISP proxy | Sometimes | Medium |
| Residential proxy | Rarely | Low |
| Mobile proxy | Very rarely | Very low |
This is why residential proxies became the default recommendation for anything serious. But IP reputation is just the first filter. The real detection happens deeper.
DNS Leaks: The Proxy That Betrays Itself
Here's something that surprises a lot of people: many proxies leak their true identity through DNS.
When a client connects through a proxy, DNS resolution should ideally happen server-side - the proxy resolves domain names on behalf of the client. But poorly configured proxies, or proxies running SOCKS5 without DNS proxy support, will let the client resolve DNS locally. This means the DNS query goes out through the real network interface - often directly to the user's ISP or a well-known resolver - while the HTTP traffic goes through the proxy.
The mismatch is detectable. If your connection IP is a residential address in Germany but your DNS resolver is Google's 8.8.8.8 that routes the request through the closest server to your real location (or worse, your ISP's default resolver in a completely different country), that asymmetry is a strong signal.
QUIC protocol makes this worse. Chrome's QUIC implementation will sometimes bypass a proxy entirely when the protocol negotiates over UDP rather than TCP. Detection systems that see HTTP/3 QUIC traffic arriving from a different IP than the initial TCP handshake have a nearly perfect signal.
The takeaway: a proxy that doesn't control DNS is leaking. Full stop.
TCP Fingerprinting: Where Most Proxies Get Caught
This is the method most people don't know about, and it's where the majority of proxies - including many residential ones - get exposed.
Every operating system has a distinct way of setting up a TCP connection. The initial SYN packet carries a set of parameters that differ between operating systems, versions, and even kernel builds:
- TTL (Time to Live) - Windows typically starts at 128; Linux at 64; macOS at 64
- TCP Window Size - varies significantly between OS families
- Maximum Segment Size (MSS)
- TCP Options order - the sequence of SACK, Timestamps, NOP, WScale matters
- Window Scaling factor
These are just a few of many ways to catch a proxy or a VPN for that matter, services such as VisitorQuery are quite good at this. Tools like p0f, nmap, and commercial platforms like Cloudflare use these fields to passively fingerprint the OS behind a connection.
Here's the problem for proxy operators: the overwhelming majority of proxy server infrastructure runs Linux. And Linux servers have a very specific TCP fingerprint - one that looks nothing like Windows 11 on a consumer laptop, or macOS 14 on a MacBook.
So when a connection arrives claiming to be a Chrome browser on Windows, but the TCP SYN packet has a Linux server fingerprint with a 64 TTL and Linux kernel-typical window sizes? That's a contradiction. And contradictions are flags.
Running a TCP Listener to Inspect Handshake Data
You can observe this yourself. Here's a simple way to capture and inspect incoming TCP handshake data:
Run this on a server and connect from different devices. A Windows machine, a Linux machine, and an Android phone will produce noticeably different outputs. A proxy server running on Linux will look exactly like a Linux server - because it is one.
What a Fingerprint Mismatch Looks Like
| Signal | Windows 11 Chrome | Linux Proxy Server | Verdict |
|---|---|---|---|
| TTL | 128 | 64 | Mismatch |
| TCP Window | 64240 | 5840–29200 | Mismatch |
| WScale | 8 | 7 | Mismatch |
| Options order | MSS,NOP,WScale,SACK,TS | MSS,SACK,TS,NOP,WScale | Mismatch |
| MSS | 1460 | 1460 | Match |
Three or four mismatches simultaneously? That's not noise - that's a proxy.
Handshake Timing: The Subtler Signal
Beyond the fingerprint content, the timing of TCP handshakes carries information.
A direct connection from a user on a home network has a certain latency profile - shaped by the last-mile link, local routing, and geographic distance to the server. A proxied connection goes: client → proxy server → target server. Even if the proxy is fast, this double-hop introduces a measurable timing pattern.
The three-way handshake gives it all away. First the proxy server established the connection (with a latency of it's own), then the browser sends the payload with a latency of their own + the proxy server latency so the target server sees a small latency at start and a double latency for the remainder → red flag.
Detection systems that collect enough baseline data can build statistical models of expected latency for a given IP geolocation. When a connection arrives from an IP geolocated in São Paulo but the round-trip time suggests the actual endpoint is in Amsterdam, that divergence is a signal.
The exception here is mobile proxies.
Mobile proxies route traffic through actual mobile devices on carrier networks (4G/5G). The carrier infrastructure itself - carrier-grade NAT (CGNAT), shared IP pools, inherent radio variability - creates timing and routing patterns that are genuinely indistinguishable from legitimate mobile traffic. You can't trust the numbers here, because the numbers are inherently noisy. This makes mobile proxies the most detection-resistant category by a wide margin.
The Use Case Split: Scraping vs. Multi-Accounting
Scraping: Largely a Solved Problem with Backconnect Proxies
For automated data collection, the proxy detection problem is mostly manageable thanks to backconnect (rotating) proxy pools.
If you use a different IP for every single HTTP request, there's nothing to build a behavioral profile on. Even aggressive detection systems can't build a pattern when the noise floor is too high. Backconnect residential pools rotate through millions of IPs. No single IP makes more than a handful of requests.
Important caveat: this doesn't protect from application-layer signals (JA3/JA4 TLS fingerprinting, JavaScript bot detection). But for pure HTTP scraping at scale, backconnect pools remain effective.
Multi-Accounting: Still Genuinely Hard
This is where it stays difficult. Multi-account management requires consistent sessions over time - and that consistency is exactly what detection systems track.
| Signal | What It Reveals |
|---|---|
| IP address | Same proxy used across accounts |
| TCP fingerprint | Underlying OS doesn't match claimed browser |
| Canvas fingerprint | Identical rendering = same device |
| WebGL fingerprint | GPU and driver details |
| Font rendering | OS-level font stack |
| Navigator UA + platform | Must match TCP fingerprint OS |
| Screen resolution + DPR | Device characteristics |
| AudioContext fingerprint | Hardware audio pipeline |
| Timezone + locale | Geographic consistency |
The critical point: fingerprints must be generated based on data that closely matches the actual OS - or the discrepancy is immediately visible.
Most anti-detect browsers spoof navigator.platform to "Win32" and set a Windows user agent - but run on Linux. The TCP fingerprint (set at the OS level, not spoofable without kernel intervention) says Linux. The canvas uses the host GPU. The font set reflects the host OS. You've built a fake identity with internal contradictions, and detection systems only need one.
A properly consistent identity needs:
- A TCP fingerprint matching the claimed OS (requires a Windows machine or VM)
- A matching font set
- Matching canvas rendering profile
- A navigator object consistent with all of the above
- A residential IP from a matching geography
- Timezone, locale, and screen resolution that are internally consistent
Getting all six right simultaneously is genuinely hard. Most solutions get three or four. Detection systems need only one inconsistency.
Proxy Type Detection Resistance — Full Comparison
| Proxy Type | ASN Detection | TCP Fingerprint | Timing Analysis | DNS Leaks | Best Use Case |
|---|---|---|---|---|---|
| Datacenter | Easily caught | Linux fingerprint | Variable | Common | Internal tools, unprotected targets |
| Shared ISP | Sometimes | Linux fingerprint | Variable | Common | Light scraping |
| Dedicated ISP | Usually passes | Linux fingerprint | Better | Can be clean | Mid-tier scraping |
| Residential (rotating) | Passes | Node-dependent | Good | Usually clean | Scraping, general anonymity |
| Residential (static) | Passes | Node-dependent | Good | Usually clean | Long-term sessions |
| Mobile | Passes | Mobile OS profile | Best | Clean | Multi-accounting, high-security targets |
FAQs
Can you detect a proxy just from the IP address?
Yes, for datacenter and shared ISP proxies - IP reputation databases are comprehensive and near real-time. For residential and mobile proxies, IP-alone detection is unreliable, which is why detection stacks layer multiple signals.
Does HTTPS prevent proxy detection?
No. TCP/IP fingerprinting operates below TLS. The handshake data identifying the OS is visible before any encryption begins.
What is a TCP fingerprint?
The unique combination of TCP parameter values (TTL, window size, MSS, options order) in the initial SYN packet. Different OS families set these differently, making passive OS identification possible from a network capture.
Why are mobile proxies harder to detect?
Mobile carrier infrastructure - carrier-grade NAT, dynamic IPs, variable latency - produces traffic patterns that naturally resemble proxied traffic. There's no reliable baseline to deviate from.
Are rotating proxies safe for multi-accounting?
At the network layer, yes. At the application layer, no - rotating IPs doesn't help if your browser fingerprint is consistent across accounts or internally inconsistent with the claimed OS. Plus, many websites completely end the session if you're caught changing IP addresses mid session.
What is a DNS leak in proxy detection?
When a proxy routes HTTP traffic through the proxy server but lets DNS queries resolve locally, the divergence between DNS resolver IP and proxy IP is a detectable signal.
