Why do antidetect browsers and proxies still give each other away?

An antidetect browser is only half of a disguise. Every commercial antidetect product sells profiles with a proxy slot, because a spoofed browser on the operator’s real home connection would be linked by its address within a day. The profile tells one story (a Windows laptop, Chrome, Berlin, German keyboard) and the proxy has to tell the same story at the network layer. Detection that treats the two halves as one visit finds the places where they disagree.

This guide lists those places and how to check them without inventing a benchmark. For what the browser half changes, start with what an antidetect browser really does; for the network half, see the residential proxy detection guide.

The disguise has two halves that must agree

Profile settings are chosen once, when the profile is created. The proxy is chosen per session, often from a pool that rotates, and the operator may run dozens of profiles in one sitting. Anything that has to be consistent between the two — time, place, language, connection type, network stack — is a maintenance burden for the fraudster and a check for you. The tools know this: several advertise “time zone from IP” and “language from IP” features precisely because a mismatch is a common way profiles get caught. Those features work only while the profile keeps the proxy it was configured for.

Time zone and language versus the address

A browser exposes its clock through Intl.DateTimeFormat().resolvedOptions().timeZone and its offset through Date; it exposes preferred languages through navigator.languages and the Accept-Language header. The proxy address has a country and, for most consumer networks, a city-level location. A visitor whose browser reports America/Chicago while the address sits in Lagos is not necessarily a fraudster — travellers, VPN users and people on a company network all produce this — but it is a mismatch worth weighing, and it is exactly the mistake a rotating proxy pool makes for the operator.

Maskbreak compares the browser’s reported time zone with the address in the same evaluation. An eligible mismatch adds the timezone_mismatch reason and can move an allow decision to review; it never blocks on its own, because the innocent explanations are too common. The full rule is described in the API reference and openapi.json.

Connections that bypass the proxy

An HTTP proxy carries the page and its requests. It does not automatically carry everything the browser does. WebRTC gathers connection candidates as described in RFC 8445, and a candidate can carry an address the proxy never saw. DNS lookups may resolve locally rather than through the proxy. Antidetect browsers therefore ship switches to disable WebRTC, fake its addresses or force DNS through the tunnel. Each switch is another consistency question: a mainstream browser with WebRTC disabled, or one that reports a WebRTC address that does not match its HTTP address, looks different from the ordinary consumer Chrome the profile claims to be.

Transport fingerprints do not read navigator

Everything a profile spoofs lives in JavaScript and HTTP headers. The TLS handshake and HTTP/2 settings are produced by the actual network stack underneath, and most antidetect products are Chromium builds. A profile that presents Safari on macOS in its user agent while opening connections like Chromium on Windows has contradicted itself before a single script runs. JA4 TLS fingerprinting covers what that handshake reveals. Chromium’s own user agent reduction has already made the user agent string a weak claim on its own, which is why a modern check compares claims across layers rather than reading one field.

The proxy pool has a history the profile cannot rewrite

A fresh profile has no past. Its proxy address does. Residential proxy addresses are shared among a provider’s customers and rotate through many operators; the same address appears on other sites, in other operators’ sessions and in abuse reports. Network intelligence that recognises a residential proxy network, and names the service when it is known, catches the half of the disguise the operator did not build and cannot reset. Maskbreak reports this as network.proxied, which the base policy blocks, with network.service filled in when the provider is known.

Where the halves can disagree

What to do with a mismatch

Treat one mismatch as a reason to look, not as proof. A single contradiction should raise a visit to review: hold the protected action, ask for a step you can verify (an email code, a payment authorisation, a signed-in session), and let the person finish if they pass. Two or three independent contradictions — a spoofed browser, a proxy address and a time zone that belongs to neither — are the pattern a profile farm produces, and that is where a block is justified. Keep the evidence separate in your logs: which checks ran, which fired and which were unavailable. Maskbreak lists that in device.checked_signals and device.complete, so a “no tampering” result can be told apart from a check that never happened. How to test antidetect detection describes a test plan that keeps those cases apart, and VPN detection without blocking real customers covers the review step in detail.