背景
之前，服务器到期，刚好阿里云有活动，便把服务器从腾讯云迁移到了阿里云 ECS。 迁移完成后，网站、数据库、WordPress 等业务均可以正常运行，因此没有继续检查服务器底层配置。
后来，在 WordPress 后台编辑文章时发现一个异常： “文章发布时间比本地时间慢了 8 个小时”。
例如：
- 本地时间已经是上午；
- WordPress 编辑器显示的发布时间却仍然是凌晨。
由于刚好相差 8 小时，第一反应通常会认为：
- 是不是 WordPress 时区配置错误？
但进一步排查发现，WordPress 本身没有问题，真正异常的是服务器系统时间。
最终定位到：
云服务器迁移后，系统中的 chrony 配置仍然保留着腾讯云 NTP 地址，而该地址依赖原云厂商网络环境，在迁移到阿里云 ECS 后无法继续正常提供时间同步服务。
这也是在云服务器迁移中容易忽略的一类问题：
系统能够启动、业务能够运行，并不代表迁移已经完整。
故障现象
首先检查服务器当前时间：
date输出：
Sun Aug 9 01:17:51 CST 2026查看 UTC 时间：
date -u输出
Sat Aug 8 17:17:53 UTC 2026进一步检查时区和 NTP 状态：
date +"%F %T %Z %z"
timedatectl status关键输出：
2026-08-09 01:18:01 CST +0800以及：
Local time: Sun 2026-08-09 01:18:06 CST
Universal time: Sat 2026-08-08 17:18:06 UTC
Time zone: Asia/Shanghai (CST, +0800)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: yes从这里可以得到三个重要信息：
-
系统时区已经是：
Asia/Shanghai并且：
+0800正确。
- 本地时间和 UTC 时间之间的转换关系没有问题。
- NTP 服务虽然启用，但是实际上没有完成同步。
因此：
这不是简单的时区错误，而是服务器系统时间本身发生了偏移。
先区分：时区错误还是系统时间错误？
“服务器慢 8 小时”通常有两种可能。
情况一：时区配置错误
例如服务器时间本身正确：
2026-08-09 09:00 UTC但是系统显示时使用了 UTC：
Time zone: UTC (+0000)这种情况只需要修改时区：
timedatectl set-timezone Asia/Shanghai情况二：系统时间本身错误
本次故障属于这种情况。
表现：
Time zone: Asia/Shanghai已经正确。
但是：
date显示的时间仍然比真实时间慢 8 小时。
这说明：
- 时区没有问题；
- 系统维护的实际时间错误；
- NTP 没有成功校准系统时钟。
检查 chrony 时间同步状态
当前系统使用 chrony 作为 NTP 客户端。
首先查看时间源：
chronyc sources -v异常输出：
210 Number of sources = 0
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | xxxx = estimated error.
MS Name/IP address Stratum Poll Reach LastRx Last sample这里最关键的是：
Number of sources = 0意味着：
- chronyd 服务可能正常运行；
- 但是没有任何有效 NTP 时间源；
- 没有时间源，就无法校准系统时间。
因此：
NTP synchronized: no就是必然结果。
找到真正原因：遗留腾讯云 NTP 配置
继续检查 chrony 配置：
grep -Ev '^[[:space:]]*(#|$)' /etc/chrony.conf输出：
server ntpupdate.tencentyun.com iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony问题出现：
当前服务器已经运行在阿里云ECS。
但是配置文件仍然：
server ntpupdate.tencentyun.com iburst也就是说：
服务器迁移了，但时间同步配置没有迁移。
完整故障链路：
腾讯云迁移到阿里云
|
↓
保留原系统配置文件
|
↓
/etc/chrony.conf 仍使用腾讯云 NTP
|
↓
旧 NTP 地址依赖原环境，当前环境无法同步
|
↓
chrony 没有有效时间源
|
↓
NTP synchronized: no
|
↓
系统时间长期偏移
|
↓
WordPress 发布时间错误修复方案
1. 备份 chrony 配置
修改配置前先备份：
cp -a /etc/chrony.conf /etc/chrony.conf.bak-20260809这样如果修改后出现异常，也可以快速恢复。
2. 替换旧 NTP 时间源
打开 chrony 配置：
vi /etc/chrony.con删除原来的腾讯云时间源：
server ntpupdate.tencentyun.com iburst
替换为阿里云 ECS 推荐时间源：
server ntp.cloud.aliyuncs.com iburst
server ntp7.cloud.aliyuncs.com iburst
server ntp8.cloud.aliyuncs.com iburst
server ntp9.cloud.aliyuncs.com iburst保留其他 chrony 配置，最终配置示例：
server ntp.cloud.aliyuncs.com iburst
server ntp7.cloud.aliyuncs.com iburst
server ntp8.cloud.aliyuncs.com iburst
server ntp9.cloud.aliyuncs.com iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony说明：
阿里云 ECS 内网时间源依赖云环境支持，不同地域和实例环境可能存在差异。
配置NTP服务确保实例时间准确-云服务器 ECS(ECS)-阿里云帮助中心
3. 使用命令方式替换时间源
如果不想手动编辑配置文件，也可以直接替换：
先备份：
cp -a /etc/chrony.conf /etc/chrony.conf.bak-20260809删除已有时间源：
sed -i '/^[[:space:]]*server[[:space:]]/d' /etc/chrony.conf追加新的时间源：
cat >> /etc/chrony.conf <<'EOF'
server ntp.cloud.aliyuncs.com iburst
server ntp7.cloud.aliyuncs.com iburst
server ntp8.cloud.aliyuncs.com iburst
server ntp9.cloud.aliyuncs.com iburst
EOF执行完成后检查：
grep -Ev '^[[:space:]]*(#|$)' /etc/chrony.conf确认配置是否正确。
4. 重启 chronyd 服务
启用服务：
systemctl enable chronyd重启：
systemctl restart chronyd查看时间源：
chronyc sources -v如果系统时间偏差较大，可以执行：
chronyc makestep强制立即校正时间。
需要注意：
本次故障中系统时间偏差约8小时。
makestep会让系统时间直接跳跃，而不是缓慢调整。
生产环境执行前，应确认：
- 是否有依赖精确时间的业务；
- 是否正在执行定时任务；
- 是否会影响日志排序；
- 是否会影响数据库时间。
验证修复结果
1. 验证系统时间
执行：
date
date -u
date +"%F %T %Z %z"正常状态：
date显示当前北京时间；date -u显示当前 UTC 时间；- 两者相差 8 小时；
- 当前时间与真实时间一致；
需要注意：
- 北京时间和 UTC 相差 8 小时是正常现象。
- 两个时间是否都对应当前真实时刻。
2. 验证 chrony 同步状态
查看同步状态：
chronyc tracking查看时间源：
chronyc sources -v正常情况下应该至少存在一个有效时间源：
^* ntp.cloud.aliyuncs.com
^+ ntp7.cloud.aliyuncs.com
^+ ntp8.cloud.aliyuncs.com状态含义：
^*：当前正在使用的时间源；^+：可用的候选时间源；^?：时间源无法访问；Number of sources = 0：没有任何时间源；
再次检查：
timedatectl status目标状态：
Time zone: Asia/Shanghai (CST, +0800)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no3. 修复 RTC 配置
排查过程中发现：
RTC in local TZ: yesLinux 服务器通常推荐：
硬件时钟 RTC 保存 UTC 时间，系统根据时区转换显示。
确认系统时间已经同步后执行
timedatectl set-local-rtc 0
hwclock --systohc --utc再次检查：
timedatectl status目标：
RTC in local TZ: no这样可以避免未来：
- 更换系统时区；
- 跨云迁移；
- 夏令时规则变化；
导致额外时间问题。
验证 WordPress 时间
服务器时间恢复后，再检查 WordPress：
WordPress 后台
↓
设置
↓
常规
↓
时区
↓
上海确认：
时区：上海然后：
- 清理页面缓存；
- 重新进入文章编辑页面；
- 检查发布时间；
- 测试定时发布功能；
如果服务器时间正确，WordPress 会自动读取正确系统时间。
如果 NTP 仍然无法同步
如果修改后：
chronyc sources -v仍然没有有效时间源，可以继续检查。
1. 检查 DNS
getent hosts ntp.cloud.aliyuncs.com
getent hosts ntp7.cloud.aliyuncs.com
getent hosts ntp8.cloud.aliyuncs.com如果无法解析：
检查：
cat /etc/resolv.conf2. 检查 chronyd 日志
journalctl -u chronyd -n 50 --no-pager3. 检查服务状态
systemctl status chronyd --no-pager云服务器迁移后的检查清单
这次的经验不是：“记住修改一个 NTP 地址”，而是云服务器迁移后，需要重新检查所有绑定原云厂商环境的配置。
1. 时间同步配置
检查：
grep -RniE 'tencentyun|aliyuncs|ntp|chrony' \
/etc/chrony.conf \
/etc/ntp.conf \
/etc/systemd 2>/dev/null确认：
- 是否残留旧云厂商地址；
- 时间同步服务是否正常。
2. 软件源配置
检查：
- yum/dnf 源；
- apt 源；
- 镜像地址。
避免继续依赖旧云厂商镜像。
3. DNS 配置
检查：
cat /etc/resolv.conf确认：
- DNS 服务正常；
- 云内网域名可以解析。
4. 云监控和 Agent
迁移后检查：
- 原云厂商监控 Agent；
- 日志采集 Agent；
- 初始化脚本。
避免产生无效请求。
5. 网络策略
重点检查：
- 安全组；
- 防火墙；
- SSH；
- 数据库端口；
- NTP UDP 123。
6. 定时任务
系统时间错误可能影响：
- Cron；
- systemd timer；
- WordPress Cron；
- 自动备份；
- 证书检查。
检查：
crontab -l
systemctl list-timers --all总结
这次故障表面上表现为：WordPress 后台文章发布时间比本地时间慢 8 小时。
但真正的问题链路是：
腾讯云迁移到阿里云 ECS
|
↓
遗留腾讯云 NTP 配置
|
↓
旧时间源无法正常同步
|
↓
chrony 没有有效时间源
|
↓
NTP synchronized: no
|
↓
服务器系统时间长期偏移
|
↓
WordPress 显示错误时间最终修复步骤：
- 确认系统时区为
Asia/Shanghai； - 发现
chronyc sources -v返回Number of sources = 0； - 定位
/etc/chrony.conf中残留的腾讯云 NTP 地址； - 替换为阿里云 ECS 内网 NTP：
ntp.cloud.aliyuncs.com； - 重启 chronyd 并执行
chronyc makestep； - 将 RTC 从本地时间调整为 UTC；
- 验证服务器时间、chrony 状态和 WordPress 后台时间。
迁移云服务器时，系统能启动并不代表迁移已经完整。像时间同步、DNS、软件源、监控 Agent、定时任务和安全组等基础设施配置，都应该纳入迁移后的检查清单。
