VPS Clock Is Wrong (2026): Troubleshooting NTP, chrony, systemd-timesyncd, and Time Zone Sync

Start by looking at the current time status:

timedatectl

Focus on these lines:

Local time: ...
Universal time: ...
Time zone: ...
System clock synchronized: yes/no
NTP service: active/inactive

Here you need to distinguish two problems:

• The time zone doesn't match your expectations: for example, the system uses UTC but you assumed Asia/Shanghai.
• The system time itself is inaccurate: the UTC time is already off from real time by tens of seconds, several minutes, or even hours.

A time zone mismatch isn't necessarily a fault. Many production systems use UTC uniformly, which is actually clearer. What's truly dangerous is system clock drift, especially when it exceeds several minutes.

If you're troubleshooting scheduled tasks, you can also read this article: VPS Scheduled Tasks Not Running: cron, crontab, systemd timer.

View available time zones:

timedatectl list-timezones | grep Shanghai

Set the Shanghai time zone:

sudo timedatectl set-timezone Asia/Shanghai

If you prefer UTC:

sudo timedatectl set-timezone UTC

I recommend: use UTC uniformly inside the server, then convert to local time in the user-facing display layer. But if your team, logging system, and maintenance windows all communicate in Beijing time, using Asia/Shanghai is also fine—the key is consistency across the whole chain.

Don't treat "the time zone is now correct" as "NTP is fixed." Changing the time zone only affects display and local time interpretation; it won't solve system clock drift.

Enable NTP:

sudo timedatectl set-ntp true

Then check the status:

timedatectl status

If you see:

System clock synchronized: yes
NTP service: active

that means the system level already considers time synchronization normal.

If it's no or inactive, continue checking the services below. Different distributions use different default time synchronization components:

• Ubuntu / Debian commonly: systemd-timesyncd
• RHEL / Rocky / AlmaLinux commonly: chronyd
• Some images install the traditional ntp or ntpsec

Don't enable multiple time synchronization services at the same time—they can easily conflict.

On Debian / Ubuntu, first check:

systemctl status systemd-timesyncd

If it isn't started:

sudo systemctl enable --now systemd-timesyncd

View synchronization details:

timedatectl timesync-status

Common anomalies include:

• No available NTP Server
• The network cannot reach UDP 123
• DNS resolution failure
• The local time offset is too large and needs a manual calibration first

Check the logs:

journalctl -u systemd-timesyncd --since "2 hours ago"

If the logs show DNS resolution problems, you can refer to: VPS DNS Resolution Failure.

Many servers are better suited to chrony, especially virtualized environments and VPSs where time may jump.

Install:

sudo apt install chrony -y

Or:

sudo dnf install chrony -y

Enable:

sudo systemctl enable --now chrony

On some systems the service name is chronyd:

sudo systemctl enable --now chronyd

View synchronization sources:

chronyc sources -v

View tracking status:

chronyc tracking

Focus on:

• Whether there is a synchronization source marked with *
• Whether Last offset is very large
• Whether Leap status is normal
• Whether Stratum is reasonable

If all sources are ^?, that usually means the NTP sources are unreachable or not responding.

NTP uses UDP 123 by default. When outbound UDP is restricted on a VPS, time synchronization may keep failing.

First confirm DNS can resolve:

getent hosts pool.ntp.org

Then check firewall rules:

sudo ufw status
sudo iptables -S
sudo nft list ruleset

In most cases, an ordinary VPS won't block outbound UDP 123. But some cloud firewalls, security groups, enterprise network policies, or firewall rules in minimal images may block it.

If you use custom firewall rules, first allow outbound UDP 123, then restart the synchronization service:

sudo systemctl restart systemd-timesyncd
sudo systemctl restart chrony

Only restart the service you're actually using.

If the system time is far off, the NTP service sometimes won't pull it back smoothly right away. You can calibrate manually first, then let NTP maintain it.

Using chrony:

sudo chronyc makestep

Then check:

chronyc tracking
timedatectl

If you don't have chrony, you can also set the time temporarily, but be careful:

sudo date -s "2026-05-24 10:00:00"

Manual setting is only suitable for temporary emergencies. Ultimately you still need the NTP service to keep synchronizing, otherwise it will drift again after a few days.

Time synchronization isn't "ops perfectionism"—it directly affects business.

If you have multiple machines, don't have one on UTC, one on Asia/Shanghai, and one on the provider's default time zone. At minimum, unify the following:

• All servers have NTP enabled
• The logging system uniformly uses UTC or explicitly records the time zone
• Application-layer time storage uniformly uses UTC
• Convert by region only when displaying to users
• Monitoring alerts and scheduled task documentation clearly state which time zone is used

In multi-machine architectures, time differences make database replication, cache expiration, queue delays, distributed locks, and audit logs all harder to troubleshoot.

When a VPS clock is wrong, check in this order:

1. timedatectl to see the time zone, NTP status, and synchronization status.
2. Confirm whether it's a time zone problem or the UTC time itself drifting.
3. sudo timedatectl set-ntp true to enable NTP.
4. On Debian / Ubuntu, check systemd-timesyncd.
5. On RHEL / Rocky / AlmaLinux, check chrony / chronyd.
6. Use chronyc sources -v and chronyc tracking to view synchronization sources.
7. Check whether DNS and outbound UDP 123 are available.
8. When the time offset is too large, use chronyc makestep to calibrate first.
9. Verify whether HTTPS, cron, logs, JWT, and database timestamps have returned to normal.
10. Unify the time zone and NTP policy across multiple machines.

When a VPS clock is wrong, it looks like date is displaying incorrectly, but it actually affects certificates, scheduled tasks, login sessions, API signatures, log auditing, and database timestamps.

First use timedatectl to distinguish the time zone from time drift, then confirm whether the NTP service is actually synchronizing. For single-machine troubleshooting, look at systemd-timesyncd or chrony; for multi-machine environments, unify the time policy. Once the timeline is correct, subsequent troubleshooting won't get more and more confusing.