Your timezone should match your IP address, and small clock drift is quietly identifying. Here is how both are read and what you can realistically do.
On this page
Two quiet signals, neither decisive
This is not a guide to defeating detection, and it is not a claim that either signal names you on its own. It is an explanation of two consistency checks, and of why correcting them badly is worse than leaving them alone.
Two of the quieter signals a website can read are your timezone and the accuracy of your clock. Neither feels sensitive. Both are more revealing than they look, and both are awkward to fake, because getting them wrong creates exactly the inconsistency that gives you away.
The timezone should match the address
Your browser reports a timezone, and it also reveals an IP address that resolves to a country. When the two disagree, that mismatch is easy to spot and hard to explain innocently.
If your IP geolocates to Germany while your browser insists you are in Asia, the reasonable conclusion is that one of them is not yours. This is one of the standard checks used to detect VPN and proxy use, and it is a large part of why a VPN alone rarely makes you anonymous. You can see what the pairing currently looks like on the timezone test.
It is usually an accident rather than an attempt at deception.
- A VPN with a distant exit. You connect through a server in another country while your operating system stays on your home timezone.
- A browser that reports UTC. Some hardened configurations standardise the timezone to UTC for everyone, which removes the signal but no longer matches any particular location.
- Travel. You change location without changing the device’s timezone settings, or you change the timezone and then connect from home again.
- Spoofing tools that overshoot. A tool that changes your timezone but not your locale, language or daylight-saving behaviour creates a cluster of small contradictions.
Clock skew, measured quietly
The second signal is subtler. Every time a browser and a server exchange timestamps, the server can compare its own clock against yours. The difference is clock skew, and it is measured passively. No script asks permission, and the browser never reports anything explicitly.
What makes skew useful to a tracker is that it is close to individual. Most devices keep reasonably good time, but almost none keep identical time. A clock that runs a fraction fast or slow, combined with a timezone and a set of other traits, helps confirm that two visits came from the same machine.
You can correct your clock, but you cannot easily make it indistinguishable from everyone else’s. The problem is that correcting it removes the trait that made you you, only to replace it with the trait that made everyone else them. A wildly wrong clock is unusual, and unusual is what stands out. A clock that is a few seconds off is not unusual, because most clocks are. So the useful move is not to chase perfection but to make sure your device synchronises automatically and is not drifting by minutes.
What the checks look like together
A site testing whether a visitor is using a VPN does not rely on one signal. It layers them. Timezone is compared against IP country. Language is compared against IP country. DNS compares the resolver’s location against the IP location. Clock skew compares the device clock against server time.
| Check | What a mismatch suggests |
|---|---|
| Timezone | A VPN, a proxy, or a spoofing tool |
| Language | The same, or a borrowed browser |
| DNS | A leak or a misconfigured tunnel |
| Clock skew | Usually nothing; it is a linking signal |
A caution before you change anything
Timezone and clock skew are consistency checks, not identity checks. On their own, neither names you. Their value to a tracker is corroboration: they are inexpensive to collect, and they either confirm or contradict everything else.
It also means the signals are cheap to check and cheap to ignore. A site that never asks about your timezone still receives it with every page load, and comparing it to the country attached to your address takes no effort at all. You do not have to be interesting to be checked; you only have to be inconsistent.
The caution is this: each correction you make is itself a change, and a change that leaves the rest of your signals behind is a new inconsistency rather than a fix. You do not need to defeat these checks in order to reduce their value; you need your setup to be internally consistent. A VPN exit in a nearby country, a timezone that matches, a language list that fits, and a DNS resolver that is not pointing somewhere else entirely is a far less suspicious picture than any single clever trick.
Realistically, three things are worth doing, and each is easier than the last:
- Keep your device clock synchronised. Automatic time synchronisation avoids the unusual cases and costs nothing.
- Match your timezone to your exit. If you use a VPN, either choose an exit in your own region or change your device timezone to match, remembering that the second option affects everything else you do.
- Check the whole picture, not one setting. Run the proxy and VPN detection test to see whether the combination of signals reads as inconsistent, rather than judging any single value in isolation.
And if the two agree already, you have no problem to solve here. Open the timezone test and compare the reported zone against what your IP address suggests before you change a setting.