How Websites Detect Proxies in 2026

Ask most people how a website detects a proxy and they describe a lookup: the site checks your IP against a list of known proxy ranges, and either you are on it or you are not.

That was roughly true a decade ago. Detection today is a scoring system: a request arrives carrying dozens of independently observable properties, each is weighed, the total is compared against a threshold, and you get the page, a challenge, or a block. Your IP is one of those properties, and the only one a proxy touches.

This page walks the layers in the order a server encounters them, and states plainly for each one whether changing your proxy changes anything.

Detection is a score, not a single check

No modern anti-bot system asks one yes/no question. It collects signals across the network stack, the TLS handshake, the HTTP layer, the browser runtime and the account, assigns each a weight, and compares the total against a threshold the site owner set. You are not simply blocked or allowed — you are ranked, continuously.

That threshold moves with what you are asking for. Serving a public page to a mediocre score costs a site almost nothing; account creation, login, posting and checkout run against far stricter ones. That is the mechanical reason a setup can load a site perfectly and collapse the instant you sign in.

Two consequences follow, and they explain most of the confusion in this industry:

• No single change makes you invisible. Improving one input moves the total by that input's weight and no further.
• Contradictions cost more than weak signals. A request whose layers disagree with one another scores worse than any of those facts would alone.

Layer 1: IP address and ASN classification

Before a single byte of your request is parsed, the source address is looked up. The system resolves it to an autonomous system number, classifies that ASN as hosting, consumer ISP, mobile carrier, VPN or education, and pulls whatever historical reputation is attached to the address and its neighbours. That lookup costs nothing and runs on every request.

The classification is not guesswork. Address allocations are public records, hosting providers publish their own ranges in machine-readable form, and commercial VPN exits are enumerable by anyone willing to subscribe. A datacenter address is not suspected of being one; it is known to be one, with a name attached.

What varies is the consequence. Datacenter ranges are scored hardest, because blocking one costs a site essentially no real customers. Commercial VPN exits are close behind. Shared residential pools pool reputation, so another tenant's behaviour on the address you just rented is charged to your request. Mobile carrier ranges are scored most gently for an economic rather than technical reason: carrier-grade NAT puts many genuine subscribers behind each public address, so a block there generates support tickets from paying customers. The mechanism is in how mobile proxies work.

This is the layer a proxy exists to change, and the only one it changes by itself. Everything below arrives from your own machine unchanged, whatever network it travelled over.

Layer 2: the TLS handshake

The moment your client opens a TLS connection it sends a ClientHello listing the cipher suites, extensions and elliptic curves it supports, in a specific order. That list is a signature of the software, not the person. Hashing it — JA3 historically, JA4 now — identifies the client library long before any HTTP request exists.

The structural fact that matters is ordering. The handshake completes before your first header is sent, because headers travel inside the channel it builds. A User-Agent claiming Chrome cannot retroactively change a fingerprint OpenSSL already emitted, which is why a Python script with perfect browser headers is still a Python script.

Cloudflare, Akamai, DataDome and others all read this layer, and rate limits can be keyed to a TLS fingerprint rather than an IP, so rotating addresses does not reset the counter. What genuinely changes a handshake is in JA3 vs JA4 fingerprinting.

Layer 3: the TCP/IP stack

One layer below TLS, the very first packet of the connection carries operating-system defaults: initial TTL, advertised window size, maximum segment size, window scale, and the order of the TCP options. Those defaults differ per OS and per kernel version, so the SYN packet names your operating system before any application data is sent.

This is the layer almost nobody accounts for, because there is no setting for it: not exposed to JavaScript, not configurable in a browser, and not something an ordinary proxy changes.

The practical consequence is a contradiction anti-detect browsers cannot fix: a profile presenting as macOS on a Linux server is a macOS browser on a Linux TCP stack. TCP/IP fingerprinting covers what the SYN reveals, including the one place we intervene.

Layer 4: HTTP headers, order and agreement

Browsers send a stable, predictable set of headers in a stable order, with stable capitalisation, and with values that agree with one another. HTTP client libraries send a different set, in a different order, and frequently omit headers a real browser never omits. Header order alone separates automation from browsers reliably.

Three things get checked, roughly in this priority:

• Order. Chrome, Firefox and Safari each emit headers in a characteristic sequence. Most HTTP libraries emit them in dictionary order, or in whatever order you supplied.
• Presence. Real browsers send Accept-Language, a current Accept-Encoding codec list, and the Sec-Fetch-* and Sec-CH-UA families. A request missing all of those while claiming to be Chrome is not Chrome.
• Agreement. Accept-Language should match the timezone's locale and the IP's geography; Sec-CH-UA should match the User-Agent.

Over HTTP/2 there is more. Pseudo-header order differs between browser engines, and the SETTINGS frame a client opens with is itself a stable fingerprint: two clients can send byte-identical headers and still be told apart by the frames that carried them.

Layer 5: the browser fingerprint

Once JavaScript runs, the page can interrogate the environment directly: canvas and WebGL rendering output, installed fonts, audio stack behaviour, screen geometry, hardware concurrency, timezone, language, and the presence of automation flags. Combined, these produce an identifier stable enough to recognise the same browser across IP changes.

Canvas and WebGL are the load-bearing ones. Rendering text or a 3D scene and hashing the pixels produces a value that depends on the GPU, the driver, the OS font rasteriser and the browser build. It is not random, not user-visible, and does not change when your IP does.

That last property is what matters for proxy buyers. A browser fingerprint survives rotation. Twenty accounts run from one machine share a canvas hash, a WebGL renderer string, a font list and a screen geometry: one identity with twenty logins, regardless of how many carrier addresses they arrived from. Suppressing that is an anti-detect browser's job, a separate purchase; see the setup notes for Puppeteer and Playwright, which leak automation flags by default.

Timezone is the most common self-inflicted contradiction here. The browser reports the machine's timezone, not the proxy's, so a browser reporting Europe/Belgrade from a US carrier address is a mismatch one line of JavaScript detects, and a frequent cause of endless CAPTCHA loops.

Layer 6: behaviour

Behavioural scoring watches what happens after the page loads: pointer movement, scroll rhythm, typing cadence, dwell time, and the path taken through the site. It also watches request timing at the network level — perfectly regular intervals, or a client that goes straight to an endpoint no link on the site points at.

Two sub-signals do most of the work. Timing regularity: humans are erratic, and a request every 2.000 seconds is a loop, not a careful person. Navigation shape: a real session arrives from somewhere, loads assets, follows links and abandons things, while one that requests a single JSON endpoint a thousand times with no page loads around it is describing itself accurately.

Behaviour is measured per session and per account. No proxy influences it, and no rotation makes a metronome look like a person.

Layer 7: account and identity history

For anything behind a login, the account itself carries more weight than the network. Age, verification status, payment history, the devices it has used, the addresses it has logged in from, and its connections to other accounts all feed the score. A fresh account is suspicious on any IP.

There is a counter-intuitive consequence, and one of the most expensive misunderstandings in this field. On platforms that weight consistency, changing your IP frequently is itself a negative signal. An established account logging in from the same carrier address for weeks looks like a person with a phone; the same account appearing from a new address every session looks like a shared credential.

That is why rotation and account work pull in opposite directions, a trade-off laid out in dedicated vs rotating proxies.

The whole model on one screen

Here is the model in one table. Read the right-hand column first — it is the short answer to almost every question people ask about proxies. A proxy changes the source address and, by extension, the reputation attached to it. Everything else in the list travels with your client, unchanged.

One row is hedged rather than flatly negative, and it belongs to us: the signature in the SYN packet can be rewritten in flight at the network layer, below the browser and below TLS, on the machine that emits the packet. We ship that on opted-in devices, and the mechanism and its limits are on the TCP/IP fingerprinting page.

Why contradictions score worse than weak signals

A weak signal lowers your score. A contradiction between two signals collapses it. Real devices are internally consistent by construction: the TLS stack, the TCP stack, the headers, the timezone and the network type all come from the same machine on the same connection. Faking one layer while leaving the rest untouched manufactures a combination no real user produces.

Common examples, none requiring a sophisticated vendor to spot:

• A User-Agent claiming Safari on macOS, with a TLS fingerprint belonging to a Python HTTP library.
• A browser reporting a US English locale from an address geolocating to another continent.
• A mobile browser fingerprint (touch support, small viewport, mobile GPU string) arriving over a TCP stack with desktop Linux defaults.

A single weak signal is a bad hand. A contradiction is a hand with five aces in it.

This is also the honest caveat on every fingerprint-modification technique, ours included: a layer changed to something that does not fit the rest of your stack can score worse than leaving it alone. Consistency is the target, not any particular value.

Diagnosing which layer is actually failing

Before buying anything, find out which layer is scoring against you. The test is cheap: change one variable at a time and watch whether the outcome changes. Most people who buy proxies to fix a detection problem are fixing a layer that was already working fine.

1. Load the same URL from your own connection, in a normal browser, by hand. If it fails there too, the problem is your account or your behaviour, not your network.
2. Run your script's exact request from a residential connection, no proxy. If it still fails while a real browser on the same connection succeeds, the failing layer is TLS, TCP or headers: your client, not your address.
3. Read the error you are getting. A rate limit that expires is a volume problem; a firewall block that never expires is an identity problem, a distinction spelled out in Error 1020.
4. Change the IP last. It is the most expensive variable and, for scripted clients, usually not the one failing.

If step 2 fails, no proxy on the market fixes it. If step 2 passes and step 1 fails, no proxy fixes that either.

Where a mobile proxy helps, and where it does nothing

We sell dedicated 4G/5G mobile proxies — one physical device, one customer, a carrier address that is not shared with a rotating pool. That is a strong answer to layer one and one unusual extra at the TCP/IP layer. It is not an answer to TLS, browser fingerprint, behaviour or account history.

Where it genuinely helps: your address is classified as datacenter or VPN and scored out before anything else is evaluated; you are inheriting other tenants' reputation in a shared residential pool; or you need an address that stays put for weeks so an account can build history.

Where it does nothing: your requests are identifiable as a script from the handshake onwards; your accounts share one browser fingerprint; your traffic moves at a rate no person moves at; or the platform has decided something about the account rather than the address. In each case the failing layer arrives from your machine, and it arrives identically over the best network in the world.

This page is structured as layers rather than tips because the layers are how the decision is actually made. Work out which one is costing you, then buy the thing that changes it. Mobile versus residential is the next page if layer one turns out to be yours; the TLS page if it is not.

Frequently asked questions

How do websites know I'm using a proxy?

Usually they do not know — they estimate. The source address is resolved to an autonomous system, classified as hosting, ISP, mobile or VPN, and given a reputation score. That score is combined with your TLS fingerprint, TCP characteristics, header order, browser fingerprint and behaviour. A high total triggers a challenge or a block.

Can a website detect a proxy if I use a residential or mobile IP?

It can still detect automation, which is usually what it is actually looking for. A carrier address removes the easiest signal — an obviously non-consumer network — but leaves the TLS handshake, the TCP stack, the header order, the browser fingerprint and the behaviour completely unchanged.

Does changing my User-Agent help avoid detection?

Barely, and it can hurt. The User-Agent is one string that anything can set, so it carries almost no weight on its own. Worse, if it claims an OS or browser that contradicts your TLS fingerprint, TCP stack or JavaScript environment, you have created a contradiction that scores worse than the original header.

Why does my proxy work for browsing but fail at login?

Because the threshold moves with the action. Serving a public page to a mediocre score costs the site very little. Account creation, login, posting and checkout run against much stricter thresholds and often add extra checks, so the same setup passes one and fails the other.

What is the single strongest proxy detection signal?

Inconsistency between layers. Any individual weak signal just lowers your score, but a combination a real device cannot produce — say a browser claiming Windows on a macOS TCP stack from a mobile carrier address in a timezone that does not match the IP — is a much stronger flag than any of those facts alone.

Do anti-bot vendors share reputation data between sites?

Vendors that operate across many customer sites — Cloudflare, Akamai, DataDome, HUMAN, Imperva and others — build reputation from traffic they see across their whole network, not just the site you are on. An address or fingerprint that behaved badly elsewhere can arrive already scored.