A proxy changes the address a website sees, but not the clock, languages or location your browser reports. If the address says Frankfurt and the browser says Sydney time and English (Australia), the profile contradicts itself, and that mismatch is one of the most common reasons a site asks for an extra check. The fix is to set the profile's timezone, languages and location from where the proxy really exits, measured rather than assumed, and to keep them matched when the exit changes.
Below: the values a site compares, a one-minute check you can run in any browser, how to measure an exit properly, and what to do when it moves.
What a site compares
A website has two independent views of where you are.
From the network. Your IP address maps to a country, region, city and usually a timezone in IP-location databases. The Accept-Language header sent with every request lists your preferred languages.
From the browser. JavaScript can read:
- The timezone name, such as
Europe/Berlin, fromIntl.DateTimeFormat().resolvedOptions().timeZone. - The clock offset from
new Date().getTimezoneOffset(), which must agree with the name for the current date, daylight saving included. - The language list from
navigator.languages, which should agree with theAccept-Languageheader. - The locale that dates and numbers are formatted with, which normally follows the first language.
- Geolocation, if the page asks and the user allows it, through the Geolocation API.
A visitor whose timezone is three hours from their IP's timezone is not unusual on its own: travellers and remote workers exist. But a profile whose timezone sits on another continent from its address, every visit, for an account that belongs to a local business, is a pattern a site notices. And a timezone name that disagrees with the clock offset is something no unmodified browser produces.
A one-minute check
Open the profile, visit any "what is my IP" page and note the country and city it reports for the address. Then open the developer tools console on any page and run:
({
timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone,
offsetMinutes: -new Date().getTimezoneOffset(),
languages: navigator.languages,
locale: Intl.NumberFormat().resolvedOptions().locale,
})Compare the two:
| Check | Matched | Mismatched |
|---|---|---|
| Timezone vs IP location | Europe/Berlin with a German exit | Australia/Sydney with a German exit |
| Offset vs timezone | 60 (or 120 in summer) for Berlin | 600 for Berlin |
| Languages vs IP country | de-DE, de, en with a German exit | only en-AU with a German exit |
| Locale vs languages | de-DE first in both | en-US locale, de-DE first language |
English alongside the local language is normal in most countries. What stands out is a language list with nothing that fits the exit country, or a locale that disagrees with the list. Our free browser fingerprint test runs the timezone, clock offset and language checks for you, in your browser, without sending anything.
Measure the exit; do not trust the label
A proxy's listing says "Germany". Where it really exits can be different, and can change.
- Providers label by pool, not by address. A "Germany" residential pool may route some sessions through a neighbouring country.
- IP-location databases disagree. One database places an address in Frankfurt; another, in Amsterdam, especially for newly moved address ranges.
- Exits move. A sticky session expires and the next one lands elsewhere; a provider reassigns a static address.
So measure: connect through the proxy and ask a lookup service, over HTTPS, where the request came from. Ask a second service too. If they agree, set the timezone and languages from that answer. If they disagree, pick a more consistently located proxy, or set the timezone yourself.
Set the values from the exit
For each profile:
- Timezone: the measured exit's IANA timezone name, such as
Europe/Berlin. - Languages: the country's main language first, optionally followed by English, for example
de-DE,de,en. - Geolocation: coordinates near the exit's city, if the profile allows location requests at all.
- Re-check after any proxy change. A new exit means new values.
Doing this by hand works for five profiles. Past that, it needs to happen automatically at every check.
When the exit moves
Even a good proxy changes sometimes. The question is what the profile does next time it starts. There are three sensible policies:
- Follow the exit. Update timezone and languages from the new measurement. Right for profiles where the country does not matter.
- Refuse if the country changed. Do not start an account that should always come from Germany on an exit that now measures as the Netherlands, until a person decides.
- Refuse if the readings disagree. If two lookup services disagree about the exit's timezone, do not guess.
How Browz keeps a profile matched to its proxy
In Browz, timezone, languages and geolocation come from the profile's proxy exit, measured at each check, so a profile that browses from Frankfurt keeps Frankfurt time (anti-detect features).
- The real exit, measured. Every check opens a real tunnel through the proxy and measures the exit IP, country, city and timezone over HTTPS. Add a second lookup service, and an offline GeoLite2 database, to compare readings on every check (proxies).
- Leave them empty to follow the exit. A profile with no timezone or language set follows its proxy's measured exit. Set them only when you have a reason, and Browz warns at launch if they contradict the exit.
- Launch guards. In Settings › Network and proxies, turn on Refuse if the exit country changed and Refuse when the exit timezone is disputed. A refused start begins with REFUSING TO LAUNCH and names the profile (proxies and launch refusals).
- A baseline per profile. With Refuse if the exit country changed on, the first launch records the profile's exit country. A later launch from another country is refused until you check the proxy, or choose Accept new exit in the profile drawer when the move was on purpose (exit country changed).
- WebRTC from the same exit, so the address a page sees through WebRTC agrees as well. See WebRTC leaks explained.
From the command line
browz check "Frankfurt ISP 1" # exit IP, country and city, measured now
browz fingerprint "Acme – Ads – DE" # each value the profile presents, and its source
browz update "Acme – Ads – DE" --timezone Europe/Berlin --languages "de-DE,de,en"browz fingerprint shows whether the timezone and languages came from the exit or were set by hand. Use browz update only for a deliberate choice, such as a profile that should keep head-office time; an explicit timezone also clears a disputed timezone refusal. The engines page lists every other surface a profile sets.
Frequently asked questions
Can websites see my real timezone through a proxy?
Yes. A proxy changes only your IP address. JavaScript reads the timezone, clock offset and languages from the browser itself, so unless the browser is set to match the exit, the page sees your own computer's values next to the proxy's address.
What happens if my timezone does not match my IP?
On its own, usually nothing: people travel and use VPNs. Combined with other signals, or on a site that weighs location closely, a mismatch can lead to extra verification or a sign-in check. Matching the profile to its exit removes the contradiction.
Should the browser language match the proxy country?
It should fit it. The country's language first, with English after it, is common almost everywhere. A list with nothing that fits the exit country, or a locale that disagrees with the language list, stands out more than any single choice.
What if two IP lookup services disagree about my proxy's location?
Treat the location as uncertain. Check the proxy again, pick a proxy that is located consistently, or set the profile's timezone yourself. In Browz, Refuse when the exit timezone is disputed stops a profile from starting until one of those happens.