Nerzen NTP Loading status TR

Verification and troubleshooting

After setup, it takes a few seconds to see that synchronisation is really working. None of the commands below change your clock; they only measure.

How to test

A single measurement without touching the system clock

Linux · chrony
chronyd -Q 'server time.nerzen.com iburst'
Linux · ntpdate / sntp
ntpdate -q time.nerzen.com
sntp time.nerzen.com

Measuring on Windows

cmd
w32tm /stripchart /computer:time.nerzen.com /samples:5 /dataonly

Continuous monitoring

chrony
chronyc sources -v      # sources and their states
chronyc tracking        # offset of the system clock
chronyc sourcestats     # per-source stability

What to expect

FromRound tripTypical offset
Server or VPS on the Nerzen network< 1 mstens of microseconds
Fixed line / data centre within Türkiye3–25 msunder 1 ms – a few ms
Mobile network, Wi-Fi20–80 msa few ms – tens of ms
Europe40–70 msa few ms

If you see ^* at the start of a line in the chronyc sources output, the system is synchronised to that source; ^+ is a source included in the combination, ^- one kept for cross-checking, and ^? one that has not answered yet. When the Reach column shows 377, all of the last eight queries were answered.

Troubleshooting

No response at all (Reach 0, timeout)

Most often a firewall is blocking outbound 123/udp or the returning response. On corporate networks and in some DDoS filters, packets with source port 123 are dropped wholesale as a defence against reflection attacks. Instead of nc -zvu time.nerzen.com 123, try a real query (chronyd -Q); with UDP, a "connection open" result is not reliable.

The name does not resolve

getent hosts time.nerzen.com should return both an IPv4 and an IPv6 address. If only IPv6 comes back and your network has no IPv6 route, force the client to IPv4 (chrony: server time.nerzen.com iburst ipv4).

The source is listed but not selected (^? or ^-)

This is normal during the first minute; chrony collects several samples before making a selection. If it persists, the difference between us and your other sources is larger than the sum of the error bounds — usually because of an asymmetric network path. Compare the per-source offsets with chronyc sourcestats.

The clock is far off and synchronisation does not start

By default chrony closes large differences slowly. For a one-off correction run chronyc makestep, or add makestep 1 3 to the configuration. On Windows, if the difference is very large, use w32tm /resync /force.

NTS key exchange fails

Three usual causes: outbound 4460/tcp is closed; the system clock is wrong enough to fall outside the certificate's validity period; or the root certificate store is out of date. Devices that have no clock at first boot (boards without a battery) need to get an approximate time over plain NTP first and then switch to NTS.

Windows says "The computer did not resync because no time data was available"

The Windows Time service may be stopped or set to manual start: sc config w32time start= auto and net start w32time. Do not configure an external source on domain-joined computers; they take their time from the domain.

The clock keeps drifting in a virtual machine

If the hypervisor tools' time synchronisation and the NTP client in the guest both try to correct the clock at the same time, they fight each other. Pick one; we recommend using chrony in the guest and turning off hypervisor synchronisation.

Some responses do not arrive

If queries arrive from the same address more often than once per second, the rate limit leaves the excess unanswered. Normal clients (one query every 64–1024 seconds) never come near this limit. If you synchronise many devices from behind a single NAT address, set up your own server inside and point only that one at us.

The "browser offset" on this site differs from the command-line measurement

The browser measurement is made over HTTP and its error bound is half the round-trip time; it is a rough indicator. For an exact value, look at your NTP client's own measurement.

Is the problem on our side or yours?

The server's current state is published every 15 seconds on the home page and in status.json. If it says "Service healthy" there, the problem is most likely on the network path in between; you can test reachability from different locations with ping.nerzen.com.