一、先分清两件事：时钟走没走对，和时区标没标对
服务器时间不对，其实是两个互不相干的问题被混在一起抱怨了。第一个是时钟不准——机器的绝对时间偏离真实世界的时间，可能是几分钟，可能是几小时。第二个是时区标错——时钟本身很准，但系统把它标成了另一个时区，导致 date 输出的时间和你的实际生活时间差了八小时。
这两者的排查方式完全不同。先确认时钟本身对不对：
# 显示当前时钟状态，systemd 机器上会直接告诉你与 NTP 源的偏差
timedatectl关键看两行：
Local time: Mon 2026-11-05 17:23:41 CST
Universal time: Mon 2026-11-05 09:23:41 UTC
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
NTP service: activeSystem clock synchronized 是 yes 才是真的同步上了。Time zone 那一行只影响显示，不影响时钟本身——把时区从 Asia/Shanghai 改成 UTC，时钟的绝对值一点都不会变，只是显示的数字变了。
所以判断方法很干脆：如果 timedatectl 说 synchronized 是 yes，而你看到的日志时间比实际早了八小时，那就是时区问题，改时区就好，不需要装任何 NTP 服务。如果 synchronized 是 no，或者系统时间本身偏差很大，那才是时钟同步出了问题。
这第二种情况在 VPS 上非常常见，原因不神秘：虚拟机的时钟由宿主机提供，宿主机本身如果没配 NTP，或者快照恢复、迁移之后时钟被重置，虚拟机内的时钟就会停留在某个历史时刻。这不是 VPS 商的问题，而是虚拟化环境时钟同步机制的一个固有特性——大多数 VPS 提供商会把时钟和宿主机对齐，但这个对齐依赖的是宿主机自己的时间准确性。
还有一个隐蔽的成因：虚拟机在长时间挂起或者宿主机做过快照恢复之后，Linux 内核的时钟漂移速率（drift）会显著变大，这时候就需要更频繁地校准，这正是第五节讲 chrony 时会提到的 driftfile 机制存在的原因。
二、时区怎么设：timedatectl 与三种时间标准
时区的正确做法不是去搜一个「时区对照表」然后改 offset 数字，而是设置 IANA 时区名称。IANA 时区数据库（也叫 Olson database）是 Linux 系统里 /usr/share/zoneinfo 下那套文件，用 /usr/share/zoneinfo/Asia/Shanghai 这种路径表示。
用 timedatectl 设置：
# 设置时区为上海
sudo timedatectl set-timezone Asia/Shanghai
# 确认
timedatectl | grep "Time zone"这个命令会做两件事：改 /etc/localtime 这个符号链接指向正确的时区文件，同时更新 /etc/timezone 里记录的名字。第二步不能省，因为有些程序读的是 /etc/timezone 而不是 /etc/localtime，两者不一致时就会出现「命令行显示对、某个应用显示错」的怪现象。
设置完成后，时间应该这样变化：
设置前（UTC）： Local time: Mon 2026-11-05 09:23:41 UTC
设置后（CST）： Local time: Mon 2026-11-05 17:23:41 CST绝对时刻没变，显示的墙上时间变了。
三种时间标准必须分清，这是新手最容易绕晕的地方。
UTC（协调世界时）是基准，所有时区都是 UTC 加上一个偏移量。UTC+8 就是 UTC 加 8 小时。
CST 在中文语境里指中国标准时间，偏移 +8。但要注意 CST 这个缩写在美国语境里是 Central Standard Time（美国中部时，UTC-6），跨时区协作时用 CST 缩写会出歧义。在配置文件里要写全 Asia/Shanghai 而不是写 CST。
本地时间（Local Time）就是 date 命令直接输出的那个值，它是「UTC 加上当前设置的时区偏移」的结果。
在日志、数据库、监控里，应该存什么？答案是 UTC。存 UTC 的理由不是「更专业」，而是三个具体的工程好处：第一，日志聚合时不同来源的时间戳能直接比较，不需要先猜每个来源在哪个时区；第二，夏令时切换时本地时间会重复或跳变一小时，UTC 不会；第三，服务器迁移到另一个时区时，历史数据不需要重写。
做法是让应用以 UTC 存储、只在展示层转换：
# 让 PHP 用 UTC
echo "date.timezone = UTC" > /etc/php/8.2/cli/php.ini
# 让 MySQL 用 UTC
mysql -e "SET GLOBAL time_zone = '+00:00';"反过来，如果你的业务就是面向国内用户的站点、且没有任何跨时区协作需求，把服务器时区设成 Asia/Shanghai 也能正常工作——判断依据是「有没有需要和别的时区比对的时间数据」，不是「哪个更正确」。
三、chrony 与 ntpd：两代时间同步方案的差异
ntpd 是老一代方案，chrony 是新一代方案。两者现在都能用，但机制和适用场景不一样。
ntpd（Network Time Protocol daemon）的模型是分层时间同步：服务器之间互相投票，形成一个层级的时钟树，底层由外部 NTP 服务器提供时间源。配置在一个文件里：
# /etc/ntp.conf
server ntp.aliyun.com iburst
server time.cloudflare.com iburst
driftfile /var/lib/ntp/ntp.drift
restrict default kod nomodify notrap nopeer noqueryserver 行指定时间源，iburst 表示开机时快速同步（发几个包就锁定），driftfile 记录本地晶振的漂移率，让重启后不用重新慢慢收敛。
chrony 的模型不一样，它把客户端和服务端角色统一在同一个软件里，通过配置文件里的 pool、server、peer 等指令灵活配置，并且原生支持多种时间源类型（NTP、PTP、PPS、SHM、参考时钟）。它的两个核心配置是：
# /etc/chrony/chrony.conf
pool ntp.aliyun.com iburst maxsources 4
server ntp.cloudflare.com iburst
driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsyncpool 指向一个时间源池，chrony 会从池里挑最快的几个用，比单个 server 更抗单点故障。makestep 1.0 3 的意思是：如果系统时钟偏差超过 1.0 秒，就在启动后的前 3 次更新里直接跳变（step）而不是慢慢校准（slew）。这个参数对 VPS 尤其重要——刚开机时时钟可能差几个小时，如果用 slew 慢慢校准，系统要花很长时间才能把时间调准，这期间 HTTPS 证书校验会失败、日志时间戳全乱。
rtcsync 让内核把系统时钟每 11 分钟同步一次到 RTC（硬件时钟）。在云主机上 RTC 通常是宿主机共享的虚拟设备，这个选项有时会带来意外，需要实测。
怎么选？如果你的系统是 Debian 12 或 Ubuntu 22.04 及以后，chrony 已经是默认服务，直接用。如果是老的 CentOS 7 机器，ntpd 更常见，但 chrony 也完全能装。两个方案不要同时跑：
# 检查有没有两个服务在抢
systemctl status chronyd ntpd 2>/dev/null | grep -E "Active|Loaded"
# 确保只有一个在运行
sudo systemctl disable --now ntpd 2>/dev/null两个 NTP 守护进程同时跑会互相校正，产生时钟在两个值之间来回跳的现象，表现是日志时间戳偶尔倒序、偶尔跳跃。
四、chronyd 怎么配才对：五个关键参数与验收阈值
chronyd 的配置看着简单，配错的地方却很多。这一节给出一份可直接使用的配置，并明确验收标准。
先看一份完整的配置：
# /etc/chrony/chrony.conf
# 使用国内时间源池 + 一个境外源做交叉校验
pool ntp.aliyun.com iburst maxsources 4
server ntp.cloudflare.com iburst
server time.google.com iburst
# 记录本地时钟漂移率，重启后无需重新收敛
driftfile /var/lib/chrony/chrony.drift
# 允许 systemd 调整时钟步进
makestep 1.0 3
# 允许在启动初期快速校准（虚拟机的常见需求）
rtcsync
# 记录日志到 syslog
logdir /var/log/chrony
# 允许指定网段的机器来同步（按需放开）
allow 10.0.0.0/8配置好之后重启并查询状态：
sudo systemctl restart chronyd
chronyc tracking
chronyc sources -v
chronyc activitychronyc tracking 的输出里最关键的是这几行：
Reference ID : 0A2B3C4D (10.0.0.1)
Stratum : 3
Ref time (UTC) : Mon Nov 05 09:24:11 2026
System time : 0.000000234 seconds fast of NTP time
Last offset : -0.000000182 seconds
RMS offset : 0.000000401 seconds
Frequency : 8.213 ppm slow
Residual freq : -0.001 ppm
Skew : 0.021 ppm
Root delay : 0.000693195 seconds
Root dispersion : 0.000074 seconds验收标准必须是数字，给你六个可以直接对照的阈值：
| 指标 | 健康阈值 | 含义 |
|---|---|---|
| System time 偏移 | 绝对值 < 0.05 秒 | 主机时钟与参考源的瞬时差 |
| Last offset | 绝对值 < 0.1 秒 | 上一次测量的偏移 |
| RMS offset | < 0.1 秒 | 长期均方根偏移，反映稳定度 |
| Stratum | 2 到 4 | 距离真实时间源的层数 |
| Root delay | < 0.5 秒 | 网络往返延迟的贡献 |
| Frequency | 绝对值 < 100 ppm | 本地晶振的漂移估计 |
System time 那一行如果显示的是 0.000000234 seconds fast，就是 234 纳秒，远好于 0.05 秒的阈值。如果显示 0.512 seconds fast，说明同步链路有问题。
chronyc sources -v 里每一行前面有一个状态标记，含义是：
^ - 源不可达
? 源不可达或不可用
+ 源可用，是当前最优源
- 源可用，但不是最优
x 源有偏差（falseticker）
~ 源时间偏差太大健康的配置应该看到至少一个 + 标记的行。如果全是 ? 或 ^，说明网络出不去或者 DNS 解析失败：
# 测一下能不能到时间源
chronyc -n sources
ping -c 3 ntp.aliyun.com
# 测 UDP 123 是否通
nc -zvu ntp.aliyun.com 123NTP 用的是 UDP 123 端口，很多云厂商的出站安全组默认会放行，但要显式确认。如果你的 VPS 有本地防火墙（ufw、iptables），UDP 123 需要单独放行，否则 chronyd 只能靠本地时钟慢慢漂移，误差会慢慢积累到几秒甚至几十秒。
另外要检查时间源本身是否可靠。chronyc sourcestats -v 会显示每个源的抖动和偏差：
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
203.107.6.88 10 10 361 0.001 0.023 +0.001 0.010Offset 列（这里是 +0.001 秒）应该接近 0；Std Dev 是抖动，健康的源在 0.01 秒量级。
最后一步是重启后验证。这是很多配置会漏的一环——chronyd 的 makestep 1.0 3 只在启动的前三次更新里生效，如果配置写错了，重启一次就能暴露出来：
sudo systemctl restart chronyd
sleep 10
chronyc tracking | grep -E "System time|Stratum"五、容器里的时间为什么总是不对
容器内的时间问题有三种不同的成因，处理方式完全不同。
第一种是宿主机时钟本身不准。容器共享宿主机内核的时间，宿主机时间漂了，所有容器一起漂。处理方式是修宿主机，容器侧无解。判断方法是在容器内外各跑一次对比：
# 宿主机上
date +%s
# 容器里
docker exec 容器名 date +%s两边秒数一致，说明容器与宿主机同步，问题在宿主机或物理时间源。两边不一致，才是容器自身的问题。
第二种是容器镜像里没有时区数据。精简镜像（alpine、部分 debian slim）为了体积会删掉 /usr/share/zoneinfo，导致设置时区时失败：
# 在容器里设置时区
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
echo "Asia/Shanghai" > /etc/timezone如果提示找不到文件，说明时区数据确实被删了。Debian 系可以装 tzdata，Alpine 可以装 tzdata 包。
第三种是容器内的服务进程不使用宿主机的时钟偏移。这在用 libfaketime 或者某些 Java 应用的场景下会出现——应用为了测试会自己偏移时间。
还有一个非常常见的坑：容器里的 chronyd 根本不工作。原因是 Linux 内核在同一个时钟命名空间里只能有一个进程设置系统时钟（CAP_SYS_TIME），容器默认不带这个权限。在容器里启动 chronyd 会看到：
chronyd: Can't open /dev/ptp0
chronyd: Could not open /dev/ptp0: No such file or directory
chronyd: Fatal error处理方式有两种。正确的方式是让容器用宿主机的时钟——因为容器本来就共享宿主机内核时钟，宿主机同步好了容器自然就准了，不需要在容器里再跑一遍 chronyd。如果你的编排系统（Docker Compose、Kubernetes）里的容器需要独立时间，可以给容器加 SYS_TIME capability，但多数场景没必要。
验证容器时间是否正确的三个数字：
docker exec 容器名 date # 容器内时间
docker exec 容器名 date +%s # Unix 时间戳，不受时区影响
date -u # 宿主机 UTC 时间前两个的差值应该小于 1 秒。
关于时区的一个常见误解：很多镜像把 TZ 环境变量设成 Asia/Shanghai 就以为完事了。TZ 环境变量只对部分程序（glibc 程序、Python 的 time 模块）生效，对另一些（很多 Java 应用默认用 UTC、Go 程序读 /etc/localtime）不生效。可靠的做法还是改 /etc/localtime 符号链接，两种方式一起设最稳。
六、时间不对会引发的四种典型故障
时间问题的危害不是「显示难看」，而是会造成具体的业务故障。这一节列出四种常见的后果，以及对应的判定方法。
第一种是 HTTPS 证书校验失败。这是时间偏差最经典的表现。当服务器时间比真实时间快时，证书还没生效就被判定为「尚未开始使用」；慢时则是「已经过期」。浏览器的报错信息很有辨识度：
ERR_CERT_DATE_INVALID排查命令：
# 本地证书的生效与过期时间
echo | openssl s_client -servername 你的域名 -connect 你的域名:443 2>/dev/null \
| openssl x509 -noout -dates
# 本机当前时间
date -u证书的 notBefore 早于本机时间、notAfter 晚于本机时间，就是时钟问题。Let’s Encrypt 的证书有效期是 90 天，这个有效期是从签发机构自己的时钟算的。你的机器时钟偏了，浏览器拿你的时钟去比对的也是同一个标准，所以时钟偏了就是偏了。
第二种是日志时间错乱。这个问题在多台机器写同一份日志时特别明显。表现是日志行的时间戳倒序，比如：
2026-11-05 17:20:01 INFO 请求处理完成，耗时 12ms
2026-11-05 17:19:58 INFO 请求开始原因是两台机器的时钟差了几秒，而日志采集器按到达时间排序而不是按事件时间排序。
第三种是定时任务重复执行或漏执行。cron 是按系统时钟判断「当前时间是否匹配 cron 表达式」的。如果时钟被 NTP 往回调整了 1 小时，那么在这个 1 小时窗口内匹配到的那个 cron 条目会触发两次。这就是所谓的时钟回拨导致的重复执行。
第四种是证书、令牌、签名过期。JWT 有 exp 声明，API 签名有时间戳窗口，OAuth 的 id_token 也有有效期。服务端时钟偏了会拒绝本该有效的令牌，或者接受本该过期的令牌。
第五种，数据库和应用的时区不一致导致的业务数据错乱。这个值得单独说，因为它不会报错，只是数据悄悄错了。
-- MySQL：查全局时区、会话时区、系统时区
SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;如果 @@global.time_zone 是 SYSTEM，它跟的是系统时区；如果你改了系统时区而数据库没重启，@@system_time_zone 显示的还是旧值。同一个表里，MySQL 记录的 NOW() 和应用层的 datetime.now() 可能差八小时。
最稳妥的做法是前面说过的：数据库连接时统一设置会话时区为 UTC：
SET GLOBAL time_zone = '+00:00';偏移写法不依赖时区表，也不会因为夏令时产生歧义。
还有一个与时间相关的内核参数值得检查：
# 存在时间同步问题时的内核日志
dmesg | grep -i "time\|clock"如果看到 TSC unstable 或 clocksource: Marking TSC unstable，说明 CPU 的时间戳计数器在多核之间不同步，这会直接导致时钟漂移速率异常（有时是几百 ppm），必须用 chrony 的 driftfile 机制持续校正。
七、什么情况下不该用 NTP：三类场景与替代方案
这一节讲的是：什么情况下「装 chronyd 修时间」这个动作本身就不该做，或者换了时间源也没用。判断依据只能是公开事实——机房位置、线路类型、计费方式、IP 资源、网络策略，不涉及对任何商家的评价。
第一种场景：你的业务依赖单调递增的时间戳，而不是绝对时间。典型的是高频交易系统、日志采集的严格排序、部分数据库的主从复制。在这类系统里，用 NTP 平滑校时（SLEW）会让时间偶尔倒退或停滞，破坏单调性。替代方案是使用 chrony 的 smoothtime 指令在特定时段禁用 slew，或者使用 monotonic clock——Linux 内核提供的 CLOCK_MONOTONIC 本身就不受系统时钟调整影响，程序层面应该优先用它做耗时计算：
clock_gettime(CLOCK_MONOTONIC, &ts); // 用于计算间隔，不受校时影响
clock_gettime(CLOCK_REALTIME, &ts); // 用于显示真实时间第二种场景：网络策略禁止出站 UDP 123。有些云厂商的出站安全组默认只放行 TCP，或者某些机房为了防 NTP 反射攻击而封锁了 UDP 123 出站。这时 chronyd 装上了也同步不了。
替代方案有两个。第一是走 NTP over TLS 或 chrony 的 tls 指令（需要 4.4 以上版本和支持 NTS 的服务端）。第二是改用 HTTP 头时间源做粗校准：
# 通过 HTTPS 响应头里的 Date 获取服务器时间，误差通常在秒级
curl -sI https://www.cloudflare.com | grep -i '^date:'第三种场景：你需要的是「本地时区正确」，而不是「时钟同步」。这两件事在第一节就分开了。如果服务器时钟本来就是准的（timedatectl 显示 synchronized 为 yes），你只需要改时区，任何 NTP 服务都是多余的。
替代方案：直接 sudo timedatectl set-timezone Asia/Shanghai，成本为零。
第四种场景：单台一次性机器，生命周期短于几天。对这类机器，跑一个常驻的 chronyd 守护进程、维护 driftfile、偶尔还要处理 makestep 的边界情况，收益远小于成本。
替代方案：开机时用 hwclock 或者一次性对时即可，不需要常驻服务。
第五种场景：你的机器有多网卡且默认路由会漂移。这不是「不该用 chrony」的场景，但同样是常见故障源——多网卡 VPS 上，如果 chronyd 从一个不通的时间源发起同步，它会认为网络不通而阻塞整个同步流程。处理方式是显式指定绑定接口或者只配置可达的时间源。
八、按预算算账：时间同步场景下的机型选择
时间同步这件事本身对机器的要求极低，一个 512MB 内存的机器都能跑 chronyd。所以选型时不要被这个需求带偏，真正的决定因素是你的业务负载。这里给出真实价格下的单位成本，供你判断哪一档是「够用且不浪费」的。
渠道库里能查到的真实机型价格与配置如下：
RosCloud-01 19.99 美元/月 2 核 1 GB 内存 20 GB 盘 500 Mbps 1024 GB 流量
RosCloud-03 39.99 美元/月 4 核 4 GB 内存 80 GB 盘 500 Mbps 3072 GB 流量
RosCloud-05 59.99 美元/月 6 核 16 GB 内存 240 GB 盘 500 Mbps 5120 GB 流量
sixtynet LAX-STARTER 200 美元/年 → 16.67 美元/月 2 核 2 GB 40 GB 盘 2000 Mbps 5000 GB
sixtynet LAX-MEDIUM 800 美元/年 → 66.67 美元/月 8 核 8 GB 160 GB 盘 10000 Mbps 20000 GB换算成单位成本：
| 机型 | 折合月价 | 每 GB 内存 | 每 GB 磁盘 | 每 TB 流量 |
|---|---|---|---|---|
| RosCloud-01 | 19.99 美元 | 19.99 美元 | 0.999 美元 | 19.99 美元 |
| RosCloud-03 | 39.99 美元 | 10.00 美元 | 0.500 美元 | 13.33 美元 |
| RosCloud-05 | 59.99 美元 | 3.75 美元 | 0.250 美元 | 11.998 美元 |
| LAX-STARTER | 16.67 美元 | 8.33 美元 | 0.417 美元 | 3.413 美元 |
| LAX-MEDIUM | 66.67 美元 | 8.33 美元 | 0.417 美元 | 3.413 美元 |
从这张表能读出三件事。
第一，每 GB 内存的单价随规格递减。RosCloud 从 01 到 05，每 GB 内存成本从 19.99 美元降到 3.75 美元，降幅超过 80%。这意味着「买一台配置刚好够用的低档机」在内存维度上是浪费的，跳档往往更划算。
第二，LAX-STARTER 的每 GB 内存成本是 8.33 美元，每 TB 流量成本是 3.413 美元，两项都明显低于同价位区间的其他档位。按流量折算，它在「小配置 + 大流量」这个组合上有结构性优势。
第三，把账算到「时间敏感型业务」上就更有意思。假设你要跑一个对时间戳有要求的 API 服务，日志量大约是每个请求 500 字节，一天 10 万次请求，日志总量是 50MB/天，一年约 18GB。那么用 RosCloud-01（20GB 盘）的机器，日志加上系统和应用文件基本会占满一年以内；用 LAX-STARTER（40GB 盘）能撑两年。
更实际的一个算法是「按日志留存期倒推磁盘」。如果你要做 90 天的日志留存（很多合规要求就是这个周期），每天 50MB 就是 4.5GB，加上系统本身 8GB 到 10GB 的占用，20GB 的盘刚好够，40GB 的盘就有充裕余量。这就是从业务需求反推配置的路径，比「看什么配置便宜」要准确得多。
流量侧同样可以算。LAX-STARTER 每月 5000GB 流量，如果你的 API 每次响应 10KB，5000GB 对应约 5 亿次请求/月，约 19 次/秒的持续速率，带宽上限 2000 Mbps 远高于这个速率所需。换句话说，这个配置的瓶颈不在流量总量，而在内存和磁盘。
九、验收清单：七个数字确认时间同步已经到位
配置完成不等于生效。这一节给出一份可以照着跑的验收清单，每个数字都有明确的合格线。
第一项，系统时钟状态：
timedatectl | grep -E "synchronized|NTP service|Time zone"合格标准：System clock synchronized: yes、NTP service: active、Time zone 显示你设定的时区名称。
第二项，与参考源的实时偏差：
chronyc tracking | grep "System time"合格标准：绝对值小于 0.05 秒。
第三项，长期稳定度：
chronyc tracking | grep "RMS offset"合格标准：小于 0.1 秒。这个指标比瞬时偏差更重要，因为它反映的是时钟会不会慢慢漂。
第四项，时间源可用性：
chronyc sources -v | grep -c "^\^" # 状态为 ^ 的行数合格标准：至少有一个 + 标记的源，且 ^ 和 ? 的源总数不超过源总数的一半。
第五项，重启后仍然正确。这是最容易漏的一项：
sudo systemctl restart chronyd
sleep 15
chronyc tracking | grep -E "System time|Stratum"合格标准：重启后 15 秒内偏差回到 0.05 秒以内，Stratum 落在 2 到 4。如果重启后偏差很大，说明 makestep 1.0 3 没生效，虚拟机开机时的时钟跳变需要更多次更新才能收敛。
第六项，时间源的网络可达性：
chronyc -n activity
# 或者直接测 UDP 123
nc -zvu ntp.aliyun.com 123合格标准：能看到选中的源，且端口可达。
第七项，业务侧的一致性。这一项最容易被忽略，也最能暴露问题：
# 容器内外时间一致
docker exec 容器名 date +%s
date +%s
# 数据库时区与应用时区
mysql -e "SELECT @@global.time_zone, @@session.time_zone;"合格标准：容器内外 Unix 时间戳差值小于 1 秒；数据库全局时区与应用约定一致。
把这七项的数字记在一张表里，每周跑一次，两周之后你就有了趋势数据。如果某一项的数值在缓慢劣化（比如 RMS offset 从 0.02 秒涨到 0.08 秒），说明时钟源质量下降或者本地晶振漂移变大，需要提前干预，而不是等到偏差到分钟级才发现。
十、按四类人的明确选型结论
前面九节讲的是原理、配置和数字，这一节直接给结论。按你的实际情况对照下面四条，每一条都指向具体的配置和机型，不留「视情况而定」。
第一类，个人博客与静态站，只有一两个服务，时区需求仅仅是让日志时间好看。这一类选最低成本能跑 chronyd 的机型即可。RosCloud-01 是 19.99 美元/月，2 核 1GB 内存 20GB 盘，跑 chronyd 加一个静态站服务绑绑有余。注意它的每 GB 内存成本是 19.99 美元，在内存维度上非常不划算，所以这一档只适合内存需求确实在一 GB 以内的场景。用它的代价是：如果哪天要加一个数据库或跑 PHP，1GB 内存会立刻见底，届时再升级比一开始就选 4GB 更折腾。
第二类，中小型业务站或 API 服务，需要跑 PHP-FPM、Redis 和一个 MySQL 实例。这一类选 4GB 内存档。RosCloud-03 是 39.99 美元/月，4 核 4GB 内存 80GB 盘 3072GB 流量，每 GB 内存 10.00 美元、每 GB 磁盘 0.500 美元、每 TB 流量 13.33 美元。这个组合的内存能撑起 PHP-FPM 每个进程 30 到 50MB 的开销加上数据库缓存，是这类负载的合理起点。
第三类，对时间戳敏感的服务——签发令牌、计费结算、订单处理、日志严格排序。这一类要加两条硬性要求。第一，机器必须支持 CAP_SYS_TIME 或由宿主机提供可靠时间基准，开机后用 makestep 1.0 3 快速跳变。第二，主从或多副本之间必须用同一时间源，避免节点间漂移。机型上选 LAX-STARTER，16.67 美元/月，2 核 2GB 内存 40GB 盘 2000 Mbps 5000GB 流量，特点是每 TB 流量只要 3.413 美元，是本轮所有档位里流量单价最低的，配合 40GB 盘足够放日志与短期数据。
第四类，存储密集型服务，磁盘和流量是主要成本，内存需求适中。这一类选 LAX-Storage 系列：500GB 盘那档 400 美元/年，折合每月 33.33 美元，每 GB 磁盘 0.067 美元；1TB 盘那档 700 美元/年，折合每月 58.33 美元，每 GB 磁盘 0.058 美元，是全部机型里单位磁盘成本最低的一档，而且带宽标到 10000 Mbps。
还有一个跨类别的通用结论：如果你要的是「内存和磁盘都很大、流量不大」的形态，比如自建大数据平台或存储型服务，那么云途 HK.DS.S 是 800 元/月，128GB 内存 6000GB 磁盘 40000GB 流量，折合每 GB 内存 6.25 元、每 GB 磁盘 0.133 元、每 TB 流量 20.48 元。它按月付、没有年付锁定，形态和美元计价的年付机型完全不同，适合「先跑起来、按月调规模」的路径。
不管哪一类，验收标准是同一套：时钟偏差绝对值小于 0.05 秒，RMS offset 小于 0.1 秒，Stratum 在 2 到 4，重启后 15 秒内回到同步状态，容器内外 Unix 时间戳差小于 1 秒。达不到这五个数字，时间同步就还没做完。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 racknerd 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 cloudcone 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十一、常见问题
timedatectl显示时间正确，但date命令显示的时间和实际差八小时，为什么？ 说明 date 读的是 /etc/localtime 符号链接，而它指向的时区文件和你以为的不一致。检查 ls -l /etc/localtime 和 cat /etc/timezone，两个地方都要一致。改时区用 timedatectl set-timezone Asia/Shanghai，它会同时处理这两处。
改了时区之后系统时间变了吗？ 没有变。时区只改变显示方式，绝对时刻不动。验证方法是对比 date +%s（Unix 时间戳，不受时区影响）在改前改后是否相同。
chronyd启动了但状态一直显示不同步？ 按顺序查三件事：一是 chronyc sources 看源的标记，全是 ? 说明网络不通，重点查 UDP 123 是否被出站安全组拦了；二是 dmesg | grep -i clock 看有没有 TSC unstable；三是 journalctl -u chronyd 看具体报错。虚拟机上最常见的是第一种。
开机后时间不准，要等几分钟才对？ 这是没有配 makestep 的典型症状。chrony 默认用平滑校准（slew），时钟差几小时也要慢慢调。在配置里加 makestep 1.0 3，让开机后的前三次更新直接跳变。
服务器时间和容器时间差了几秒，怎么处理？ 容器与宿主机共享内核时钟，正常情况下不会差。先在宿主机和容器里各跑一次 date +%s 确认方向：如果容器慢，是容器内跑了自己的 NTP 客户端在打架，删掉它；如果宿主机慢，修宿主机。给容器加 SYS_TIME 权限是最后手段，多数场景不需要。
HTTPS证书提示ERR_CERT_DATE_INVALID，证书明明还没过期？ 九成是服务器时钟偏了。用 openssl s_client 拿到证书的 notBefore 和 notAfter，和本机 date -u 对比。如果本机时间早于 notBefore，就是时钟慢了。
ntpd和chronyd能同时装吗？ 能装，但不能同时运行。两个守护进程会互相校正，导致时钟在两个值之间来回跳，日志时间戳会偶尔倒序。保留一个，另一个 systemctl disable --now。
夏令时切换会不会让我的日志出问题？ 如果服务器时区设置成有夏令时的地区（如 America/New_York），一年两次时钟会跳一小时，前进时那一小时的时间戳会重复，后退时会有一段空白。对国内用户为主的业务，把时区固定成 Asia/Shanghai 或干脆用 UTC 就没有这个问题。
VPS的时间不准是商家的问题吗？ 多数是虚拟化环境的机制导致：虚拟机时钟依赖宿主机，宿主机漂移或快照恢复会让虚拟机时钟跟着漂移。判断方法是在重启后立刻检查偏差幅度，如果每次重启偏差都是几小时且方向随机，这是环境特性；固定向偏几秒则是本地晶振漂移，靠 chrony 的 driftfile 校正。
用了chrony还需要ntpdate这种手工对时吗？ 不需要。chrony 是常驻服务，持续校准并且能处理网络抖动，手工对时只在没有守护进程的容器里作为临时手段。而且 ntpdate 那种直接跳变的方式对运行中的业务有害（时间戳倒序、连接中断），chrony 的 slew 模式更安全。
怎么监控时间同步会不会悄悄失效？ 三个做法：一是把 chronyc tracking 的输出采集到监控系统，对 System time 偏移设阈值告警（比如超过 1 秒）；二是用 chronyc sources 监控源的状态标记，+ 变成 ? 就告警；三是业务侧自己加一个时间一致性检查——应用启动时或定时任务里检查本机时间与外部时间源的差值，超过阈值就报警。第三个最可靠，因为它验证的是实际效果而不是配置状态。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
