Ubuntu默认启用systemd-timesyncd但常因NTP服务器不可达、防火墙屏蔽UDP 123端口、时区或RTC配置错误导致timedatectl显示“System clock synchronized: no”，需检查服务状态、修正配置文件、确保网络连通并避免与chrony/ntpd冲突。
Ubuntu 默认已启用 NTP 自动时间同步，但很多用户发现 timedatectl 显示 System clock synchronized: no，或时间偏差明显——这通常不是“没开”，而是服务未生效、配置被覆盖、或时区/硬件时钟混乱导致的假性失效。
systemd-timesyncd 是否真的在跑？
Ubuntu 20.04+ 桌面和服务器版默认启用 systemd-timesyncd，但它不等于“一定在工作”。常见失效场景：
- 虚拟机里宿主机时间不准，
systemd-timesyncd会拒绝同步（防止雪崩式漂移） - 防火墙或网络策略屏蔽了 UDP 123 端口，连接 NTP 服务器超时
- 手动执行过
sudo timedatectl set-ntp false，但忘了再设回true
验证方式：运行 timedatectl，重点看两行：
System clock synchronized: yes NTP service: active
如果都是 no 或 inactive，先执行：sudo timedatectl set-ntp true，再等 30 秒重查。别急着装 chrony——多数问题就卡在这一步。
/etc/systemd/timesyncd.conf 配置是否被绕过？
系统默认用 time.google.com 和 time.windows.com，但国内访问不稳定，容易超时失败。直接改配置文件最可靠：
- 编辑
/etc/systemd/timesyncd.conf，取消[Time]下NTP=行的注释 - 填入国内可用地址，例如：
NTP=ntp.aliyun.com ntp1.aliyun.com -
FallbackNTP=可留空，或填pool.ntp.org作兜底 - 改完必须重启服务：
sudo systemctl restart systemd-timesyncd
注意：不要混用 ntpd 或 chrony ——它们会抢占 UDP 123 端口，导致 systemd-timesyncd 启动失败并静默退出。
硬件时钟（RTC）和时区错位会让时间“看起来不准”
即使网络时间同步成功，如果硬件时钟存的是 UTC 而系统按本地时间读取（或反过来），date 命令显示的时间仍可能偏差 8 小时。这不是同步失败，是解释逻辑冲突：
- 检查当前时区：
timedatectl | grep "Time zone"，确认是Asia/Shanghai - 如果不是，运行：
sudo timedatectl set-timezone Asia/Shanghai - 检查硬件时钟模式：
timedatectl | grep "RTC in local TZ"，输出应为no（即 RTC 存 UTC） - 若为
yes，运行：sudo timedatectl set-local-rtc false
这个设置影响重启后时间恢复逻辑，错一次，下次开机就倒退 8 小时。
为什么 crontab + ntpdate 是陷阱？
网上大量教程教你在 crontab 里写 ntpdate ntp.ubuntu.com，这在现代 Ubuntu 上属于危险操作：
-
ntpdate是单次强制校正，会瞬间跳变时间，可能中断正在运行的数据库、日志服务或 TLS 会话 - 它不平滑调整时钟频率，长期使用反而加剧时钟漂移
- Ubuntu 22.04+ 已不再预装
ntpdate，需额外安装，且与systemd-timesyncd冲突
真正需要“更高精度”或“低延迟同步”的场景（如金融交易服务器），才该换用 chrony 并关闭 systemd-timesyncd；普通桌面或 Web 服务器，坚持用默认服务即可。
最容易被忽略的点：时间同步依赖网络可达性，而很多云服务器安全组默认禁 UDP 123。开个端口，比换工具管用得多。
