Home → Learn → Proxy timezone mismatch

Proxy timezone mismatch

Most fingerprinting advice is about being ordinary — not having a rare canvas hash, not having an unusual font list. This one is different. An IP in New York paired with a browser clock in Karachi is not a rare combination; it is an impossible one. No amount of blending in helps, because the problem is not that you look unusual. It is that you look self-contradictory.

What the site is actually comparing

Three values, all free to obtain, none requiring anything clever.

Comparing them is one line of JavaScript and one database lookup. There is no machine learning involved, no behavioural model, no scoring threshold to tune. Either the IP's region and the browser's clock can describe the same person, or they cannot.

Why this one is worse than a rare fingerprint

A rare canvas hash makes you identifiable — it links your sessions to each other. Unhelpful, but not incriminating on its own; plenty of real people have unusual hardware.

A contradiction is different. There is no honest configuration that produces a Lahore clock on a Chicago IP. The only ways to get there are a proxy or a VPN with the browser left untouched — which is exactly what the check is looking for. It is not evidence that you are unusual. It is evidence that you are routing traffic.

The signals that have to agree

Timezone is the one people notice, because it is the one that breaks most visibly. It is not the only one tied to where you appear to be.

• Timezone and offset — and they must agree with each other too. A browser claiming America/New_York while reporting an offset of UTC+5 is a worse signal than either problem alone, because it means something is overriding one and not the other.
• WebRTC — a leaked reflexive candidate can carry your real public IP even while every HTTP request goes through the proxy. The page then sees two IPs, in two countries, for one visitor.
• Language — navigator.language and the Accept-Language header. Less damning than timezone, because real people travel and emigrate, and plenty of English-language browsers sit in non-English countries. Worth keeping plausible rather than perfect.

Two fixes that quietly do not work

This is the part worth writing down, because both look like they worked.

Setting the TZ environment variable

The obvious approach is to launch the browser with TZ=America/New_York. On Linux and macOS this generally works. On Windows, Chrome ignores it. The process starts, no error appears anywhere, and the browser reports the machine's real timezone exactly as before. Everything about the setup looks correct except the one value you were trying to change — and you only find out by checking the browser itself rather than the launch command.

Setting it once over the debugging protocol

The other approach is CDP's Emulation.setTimezoneOverride, applied when the page opens. That does work — until the first cross-origin navigation, at which point the override is gone and the real timezone is reported again.

This failure is particularly awkward because it passes a naive test. You open a fingerprint checker, the timezone is right, you conclude it is fixed. But a real session navigates: to a login page, to an OAuth provider, to the site itself. By the time anything is being decided about you, the override has lapsed. It has to be re-applied on every navigation, not set once at launch.

What to do instead

• Derive the timezone from the proxy, not from a dropdown. A list where you pick a timezone by hand is a list you will eventually get wrong — when a proxy's exit moves, when you swap proxies between profiles, when a provider rotates a pool. The value should come from the proxy's actual measured exit.
• Check it in the browser, not in the config. The only meaningful test is what the page reports, because both common fixes fail silently at exactly that point.
• Test after navigating, not just on the first page. That is where the second failure mode hides.
• Do not hide the timezone. Blocking or randomising it per page produces something no real browser does, and you are back to being conspicuous rather than consistent.

How Parallel handles it

Each profile's timezone is taken from its proxy's tested exit, not from anything you type. When a proxy check succeeds, the geolocation it returns is cached and the launcher uses it, so the clock follows the proxy rather than your machine or your memory.

The WebRTC public IP is set to the proxy's exit IP for the same reason — a leaked candidate stays consistent with the proxy instead of unmasking the real address.

And the override is applied over CDP and re-applied on every navigation, specifically because setting it once does not survive a cross-origin hop. We use CDP rather than the TZ variable because, on Windows, Chrome ignores TZ — and passing it through from the parent process can crash the launch outright.

Check yours

You do not need our software to test this. Open our fingerprint test through whatever proxy setup you use now, and compare the reported timezone against the country of your exit IP. Then navigate to another site and check again — the second reading is the one that usually disagrees.

Related reading

• Language and locale mismatch — the same contradiction one corner over, and the one that shows up in the page itself.
• Residential vs datacenter proxies — which to use per profile.
• Browser fingerprinting, explained — the full signal list, and why coherence beats hiding.
• Behavioral bot detection — the half that has nothing to do with the fingerprint.