How do websites detect proxies? 8 signals anti-bot systems look at

"How does this site know I'm on a proxy?" is a very common question — and the answer is rarely just "the IP". Anti-bot and anti-fraud systems combine many small signals into a risk score. This guide walks through the eight most common signals, explains where a 4G proxy stands against each one, and shows how to check your own setup. Understanding how sites see you is the first step to using a proxy normally and responsibly.

Detecting a proxy isn't the same as blocking it

Lots of people use proxies or VPNs for good reasons: security, remote work, corporate networks. So most sites don't block the moment they see a proxy. They add signals up into a risk score and, depending on it:

• let you through as normal,
• ask you to verify (CAPTCHA, email, phone),
• rate-limit you,
• or block you outright.

A single signal rarely decides everything. Several signals "ringing" together is the problem.

1. IP type and IP lists

This is the first and cheapest signal. A site looks your IP up in databases to learn:

• which network (ASN) it belongs to — a mobile carrier, a fixed-line provider or a hosting company,
• whether it's on lists of known proxies, VPNs or Tor exits,
• whether it has a history of abuse.

Datacenter IPs are recognised immediately because they sit in hosting ASNs. Mobile IPs are much harder for sites: blocking one blocks many real subscribers. See also clean proxies and blacklists.

2. Revealing HTTP headers

Some proxies add headers to requests, such as Via, X-Forwarded-For or Forwarded — sometimes including your real IP. On that basis, proxies are often sorted into three levels:

Note: a proxy can only insert headers into plain HTTP requests. With HTTPS the proxy just opens a tunnel and can't read or change headers — so most of today's traffic isn't affected.

3. Open ports on the IP

Some systems scan the visitor's IP back for well-known proxy ports (such as 1080, 3128 or 8080). If the IP is running a public proxy server, that's a clear sign.

With a 4G IP, inbound connections are stopped by the carrier's NAT, so this kind of scan usually finds nothing.

4. Mismatched time zone, language and location

A browser reveals plenty besides the IP: time zone, system language, preferred language (Accept-Language), and sometimes GPS location if you allow it. A Singapore IP with a Vietnam time zone (UTC+7) and a GPS fix in Hanoi is an obvious mismatch.

A mismatch isn't proof of fraud — travellers look like that too — but it adds to the risk score. The settings that should match your proxy are in setting up a proxy in antidetect browsers.

5. WebRTC and DNS leaks

• WebRTC (used for video calls in the browser) can expose your real IP through a connection that bypasses the proxy.
• DNS may be resolved by your real provider instead of through the proxy. The site can see that the DNS server asking about its domain is in a different country from your IP.

Both come from your setup, not the proxy. How to check is in how to check a proxy.

6. TCP and TLS fingerprints

At a lower level, every operating system and network library has its own "signature":

• The TCP/IP fingerprint (packet time-to-live, window size and so on) comes from the machine that actually opens the connection to the site — the proxy's machine. If the browser claims to be an iPhone but the packets look like they came from a Linux box, that's a mismatch.
• The TLS fingerprint comes from your program, because with HTTPS the encryption runs between your program and the site. A programming library has a TLS fingerprint quite unlike a real Chrome browser's.

A TLS fingerprint doesn't reveal that you use a proxy, but it does reveal whether you're a real browser — which is why a simple script gets blocked even on a very clean IP.

7. Latency mismatch

Some systems compare the latency measured at the network level (between the site and the proxy's machine) with the latency measured by JavaScript in the browser (between the site and you, going round through the proxy). A large gap suggests a hop in the middle. It's an advanced technique, used by few sites, and usually just one more signal.

8. Behaviour

This is the heaviest signal and the one no proxy can handle for you:

• speed — hundreds of requests a minute,
• patterns — the same path, the same rhythm, no variation,
• many accounts on one IP,
• interaction — no scrolling, no mouse movement, no reading.

How to scrape without getting blocked goes deep into behaviour.

Where a 4G proxy stands against these signals

A 4G proxy handles signal 1 best, and that's the signal that gets server proxies blocked on sight. The rest is on you.

Check your own setup

See whether the proxy adds headers to HTTP requests (use http://, not https://, since a proxy can't touch HTTPS):

curl -s -m 15 -x "http://USER:PASS@HOST:PORT" http://httpbin.org/headers

If the result includes Via, X-Forwarded-For or Forwarded, the proxy gives itself away on HTTP. Then check the IP, network type, DNS and WebRTC leaks and time zone with how to check a proxy.

Frequently asked questions

Is there a proxy that can't be detected?

No promise like that is honest. Mobile IPs are hard to block because they're shared with real people, but behaviour, browser setup and speed still leave traces. The right goal is to look like a normal user, not to be "invisible".

Does it matter if a site knows I'm on a proxy?

Usually not, if you're doing ordinary things. Plenty of people use proxies and VPNs legitimately. The trouble only starts when the proxy signal comes with unusual behaviour.

Is SOCKS5 harder to detect than HTTP?

SOCKS5 adds no HTTP headers, but with HTTPS an HTTP proxy can't add any either. The other signals (IP type, behaviour, browser setup) are exactly the same. See SOCKS5 vs HTTP proxies.