Proxy detection: 4 signals that give a proxy exit away

The fingerprint pages are clean, the proxy answers, and the site still serves a puzzle or an empty page as soon as the agent's browser goes out through the exit. A proxy changes where a request comes from, and a site has more than one way to see that it did. We read the exit through the same eyes a site uses, on 8 and 9 September 2026, and each signal below carries the number we measured or the source that documents it.

What is proxy detection?

Proxy detection is the check a website runs to decide whether a request arrives through an intermediary instead of from the device that made it. Most of it happens on the server, before any script on the page runs: IP intelligence vendors sell databases that label an address as a VPN, a hosting network, a public proxy or a residential proxy, and a bot defence can consult one before it serves the page. The rest compares the request with itself. The transport, the browser's own network paths and its clock each tell a site something about where the device really is, and a proxy changes only some of them.

Detection feeds a score rather than a verdict of its own. A proxied request loses trust, and a site with a sharp configuration turns that lost trust into a challenge.

Which 4 signals reveal a proxy exit?

Four signals reveal a proxy exit. The first two arrive with the connection, the last two need a script on the page:

1. IP reputation. The address is looked up before the page is served. MaxMind's Anonymous IP database flags an address as is_hosting_provider or is_residential_proxy, the latter for an address "on a suspected anonymizing network" that "belongs to a residential ISP". In our series the address decided more than the profile did: 17 of 89 runs (19 percent) through bought mobile exits passed the reCAPTCHA checkbox without a puzzle, 0 of 70 over one home line.
2. TCP fingerprint. The first packet of a connection carries a window size, a list of TCP options and their order, which JA4T turns into a string. FoxIO, who defined JA4T, writes that "when a device is connected through a Proxy, the TCP fingerprint of the proxy is seen on the server side, not the client". In 4 of 4 readings through a mobile exit, a Windows browser arrived with a Unix option order.
3. WebRTC route. WebRTC gathers candidate addresses over UDP, and UDP does not travel through an ordinary HTTP proxy. RFC 8828 defines 4 modes of address handling, and only mode 4 requires that "WebRTC media traffic MUST also be proxied".
4. Timezone and locale. A page reads the clock's zone and the language list in one line of JavaScript and compares them with the address. A browser leaving through Tulsa with America/New_York is 1 hour off its own exit, which is America/Chicago.

The four do not weigh the same. Over the 191 measurements, profile maturity (cookies, history, age) had no measurable effect, p = 0.60, while the exit address separated 19 percent from 0. Cloudflare sees the same asymmetry from the defending side. Training its bot model on residential proxy networks, it found in June 2024 that "4 out of 5 requests from these networks belong to direct and benign connections from residential devices", which is why a site scores such an exit instead of blocking it outright.

Why is a Unix TCP stack under a Windows persona normal?

A Unix TCP stack under a Windows persona is normal because a terminating proxy opens its own connection to the site, and the site reads the exit device's first packet, not the browser's. We read that packet through a mobile exit in the US on 8 September 2026, 2 readings on each of 2 session tags, with a different address per tag.

The exit sent the Unix order with timestamps on while the browser behind it claimed Windows, whose first packet in our Windows 11 reading carried no timestamp. FoxIO's own table lists Windows 11 as 64240_2-1-3-1-1-4_1460_8, the same option order as our Windows row. The mismatch is real and visible before any script, on the connection layer that comes first among the detection layers of a browser.

It is also the normal case. Every correctly configured profile behind a terminating proxy carries it, so a site that blocked on it would block every proxied visitor it has. What the exit did show is that it is a device and not a server: a window scale of 6 and a window of 65535 are phone values, where our Linux control sent 10 and 64240. For that reason Scalebrowser leaves the TCP layer out of its operating system agreement check and, in strict mode, places the hard rule on the address class instead, as the coherence documentation describes. Reading the exit's TCP signature from our side costs one extra request through the exit, about 0.94 seconds over a mobile line.

Can WebRTC route around the proxy?

Yes. A proxy carries TCP, and WebRTC gathers its candidates over UDP, so unless the browser forces media through the proxy the page learns the machine's own public address. Chrome's policy documentation describes the default as "WebRTC uses all available network interfaces", which is RFC 8828 mode 1, and a browser left at that default hands the page an address the proxy never saw. The WebRTC leak test shows the two routes a page has around an exit and how to check both in your own browser.

QUIC is the second UDP path. HTTP/3 runs over UDP by construction, so Scalebrowser switches it off for a proxied profile in the same launch that forces WebRTC through the proxy, and refuses the launch if either guard is missing. The proxies page covers the rest of what an exit is checked for.

Scalebrowser gives each agent its own isolated browser with a persistent identity, on your own machine, so a run stays signed in, handles the captcha and finishes without anyone watching it.

See how Scalebrowser does it

What should you check before an agent uses an exit?

Check the address first, because it decides most. Look it up in one IP database for its class, and run one reCAPTCHA v2 checkbox through it: in our series that took 15 seconds per run and separated the mobile exits from the home line on every round. Then read the page's clock zone and language list against the exit's city, and run a WebRTC test with the proxy on. The TCP fingerprint needs no fix: it shows the exit device, as it does for every visitor behind a terminating proxy. How the timezone, the locale and the geolocation of a browser are made to agree with its exit is covered in geolocation and timezone spoofing.