Skip to content
On this page

A timezone/IP mismatch is when the location a browser claims and the location of its IP address disagree. Anti-bot systems (the software sites use to block scrapers) read the browser timezone (via Intl.DateTimeFormat().resolvedOptions().timeZone and Date.getTimezoneOffset()), the Accept-Language header, and any GPS/geolocation claims, then compare all of them against the IP geolocation - where the connecting IP physically maps to. A request from a German residential proxy that reports America/New_York and en-US is geographically incoherent and scores block-grade. It is the single most common reason proxied scrapers get caught.

Quick facts

Signals comparedIntl timezone, getTimezoneOffset, Accept-Language, navigator.language(s), IP geo
Why it is reliableReal users almost always have a timezone matching their IP region
Common causeRotating proxy IP changes country but the browser keeps a fixed timezone
FixDerive timezone + locale + language from the exit IP, per session
Bonus checkWebRTC / DNS geo and Accept-Language must agree too

Everything a site can read about your location

Your location leaks from several independent places at once, and they are all supposed to agree:

  • Browser timezone - Intl.DateTimeFormat().resolvedOptions().timeZone returns a named zone like "Europe/Berlin"; new Date().getTimezoneOffset() returns the numeric offset from UTC. Both come from the operating system.
  • Language - navigator.language, navigator.languages, and the Accept-Language header.
  • IP geolocation - the server maps the connecting IP to a country/region/city using a GeoIP database (MaxMind and similar).
  • Geolocation API - if you grant permission, exact GPS coordinates.
  • Locale-derived signals - currency, number/date formatting, and even the set of bundled fonts can hint at your region.

On a real device these all line up, because they trace back to the one place where the person installed and configured their OS. A scraper instead assembles them from different sources - a US server timezone, a default en-US locale, and a proxy IP in Brazil - and the seams show.

Why rotating proxies make it worse

The mismatch is most damaging with rotating proxies (proxies that change exit IP from request to request). The browser process keeps one fixed timezone for its whole lifetime, but the exit IP may hop from Germany to Japan to Brazil across requests. Within a single session the timezone is now wrong for two of the three countries. Worse, an IP that changes country mid-session while the timezone stays fixed is itself behaviour no real user shows - so the inconsistency is not just static but temporal (it shows up over time).

Anti-bot vendors specifically watch for: a timezone offset that does not match the IP country, an Accept-Language that does not match the IP country, and an IP whose country changes while the client-side geo signals stay constant. Any one of these is a soft signal; two together is usually a block.

Keeping geo coherent

The fix is to derive every location signal from the exit IP, per session, instead of leaving OS defaults in place. That means: set the browser timezone to the IP's zone, set navigator.languages and Accept-Language to a locale plausible for that country, and if geolocation is granted, return coordinates inside the IP's region. Pin the proxy to one country for the lifetime of a session so the timezone never contradicts a later request.

Serious anti-detect browsers and managed scraping APIs automate this: they look up the proxy exit IP, then configure timezone, locale, language, and geolocation to match before the first page load. This is exactly why frameworks warn against using a separate proxy-auth path the fingerprint layer does not know about - if the browser does not know the exit IP, it cannot align the timezone to it. Keeping geo coherent is a clustering problem, not a single setting: see fingerprint clustering.

Code example

javascript
// Client signals an anti-bot script collects
const geo = {
  tz: Intl.DateTimeFormat().resolvedOptions().timeZone, // 'Europe/Berlin'
  offset: new Date().getTimezoneOffset(),               // -120 (minutes, DST-aware)
  langs: navigator.languages,                           // ['en-US','en']
  lang: navigator.language
};

// Server compares against IP geo (pseudo)
function geoCoherent(geo, ipCountry /* from MaxMind */) {
  const tzCountry = zoneToCountry(geo.tz);     // 'Europe/Berlin' -> 'DE'
  if (tzCountry !== ipCountry) return false;   // timezone vs IP
  const langCountry = (geo.lang.split('-')[1] || '').toUpperCase();
  if (langCountry && langCountry !== ipCountry) {
    // en-US on a DE IP is common for expats, so this is a soft signal,
    // but tz mismatch + lang mismatch together is block-grade.
    return 'soft';
  }
  return true;
}
// Rule of thumb: pin one country per session and derive tz+locale+lang from the exit IP.

Next in Environment and display signals · 5 of 7

What the machine reports about its own capacity.

What Is Hardware Fingerprinting?

Related terms

Concept map

Concept map

How Timezone / IP Mismatch connects

The terms most directly tied to this one. Hover a node to see its neighbours, click to preview, drag to rearrange.

0 terms · 0 connections
You are here · Anti-Bot
Building map…

Frequently asked questions

How strong a signal is a timezone/IP mismatch on its own?

Strong. Real users overwhelmingly have a browser timezone that matches their IP region. A clear mismatch (timezone country != IP country) is enough for a soft block at most vendors, and a hard block when combined with any other anomaly. It is cheap to compute on the server, so nearly every anti-bot system checks it.

What about expats and travellers whose language does not match their IP?

That is exactly why an Accept-Language mismatch on its own is treated as a soft signal - en-US on a German IP is plausible. But the timezone almost always still matches the IP for those users, because the OS timezone follows wherever they physically are. Timezone mismatch is the harder signal; language mismatch only corroborates it.

How do I keep timezone and IP consistent with rotating proxies?

Pin a session to one proxy exit country instead of rotating mid-session, look up the exit IP, and set the browser timezone, languages, and (if used) geolocation to match that country before navigating. Tools that handle this automatically read the exit IP first, then configure the fingerprint - which is why a proxy the browser is unaware of breaks the alignment.

Last updated: 2026-05-31