云服务器NTP配置；内网时钟源与公网源取舍

系统时间差个几秒，平时什么都看不出来。真出事，特别难看。日志时间戳对不齐；两个节点差半分钟，分布式任务就互相干等；证书校验报还没生效，或者已过期；定时备份跑到不该跑的时段去。云服务器NTP配置，说白了就干一件事——让机器知道现在几点。改起来花不了几分钟。可配错了呢，往往半年不发作。等发作那天，你还想不到是它。

云服务器NTP配置到底在改哪几行

现在装机基本都是 chrony 了，CentOS 7 往后默认带它，Ubuntu 也是，ntpd 那套虽然还在，新机器真没必要往回退。要动的配置文件就是 /etc/chrony.conf，跟时间源有关的就两三行：server 认死一个上游，pool 给一组让它自己挑。两者差别没想象中大，pool 会选几个响应好的，server 就从头到尾盯着一个。

就这么几行。

改完 systemctl restart chronyd，再 chronyc sources -v 看一眼，不然你连它到底连没连上都心里没底。别改完就撒手，我见过配完一年没人管的机器，chrony 早就退出了，时间靠宿主机飘着走，也一直没出事，直到某天证书续期失败。

内网时钟源，好处和坑一样明显

内网源最大的好处是稳。不依赖出口带宽，不怕云安全组顺手把 123/udp 挡了，几百台机器一起同步也不会把外面的公共源打烦。还有一层是审计，全站机器的时间来源收敛到你能控制的一两台，出问题不用满世界找根因。

坑在哪呢。内网源自己也是从公网拿时间的话，它就是二手时间，精度会打折，链路越长越明显。

更麻烦的是有人图省事，在内网源上直接写 local stratum 10，断网了也不慌，看着挺聪明吧。

这是自欺欺人。

本地时钟不是不能当兜底，是不能当长期源头。物理机的晶振一天漂多少要看环境温度，虚拟机就更别提了，宿主机一忙，你那点时间就跟坐船似的。拿它兜底可以，当主力不行，老实说这个坑我踩过。

公网源怎么挑，别只看 ping

pool.ntp.org 那一套是社区在维护，各地都有分区；云厂商一般也提供自己的时间服务地址，具体用哪个、走不走内网、算不算流量，以官方文档为准，我不在这瞎写。说白了就看三件事：域名能不能解析出来、你的出口放不放 123/udp、上游本身稳不稳。

ping 低不代表时间准，那玩意儿是 UDP，ping 通的路径和时间包走的路未必一样，中间隔一层 NAT 就更说不清了呗。

我一般这么干：先 chronyc sources -v 把每个源的 offset 和 stratum 摆清楚，带星号的是当前选中的，加号是备选，问号就是还没拿定主意或者连不上的。再 chronyc tracking，看 System time offset 和 frequency，frequency 要是一直在几十 ppm 上蹿，多半不是上游的问题，是本机晶振或者宿主机负载的问题，你会发现它跟换源没关系。

云主机上还有一层宿主机在管时间

虚拟机的时间不完全是自己说了算。宿主机 CPU 抢得厉害，时钟漂移会明显，轻量实例上尤其容易碰到。有些平台在控制台里有时间同步的开关，开了客户机就跟着宿主机走，没开就得自己在系统里配 chrony，这事以你用的平台说明为准。

如果你的业务对时间敏感——下单、日志追溯、分布式锁、证书有效期判断都算——那就不能只把 chrony 装上、看见一个 synced 就收工，还得隔一阵回来看 tracking 里的偏移是不是在收敛，我自己在一台配置很低的实例上就见过同步周期被拉得很长、offset 弹回去又慢慢爬回来的情况。

容器嘛，跟宿主共用一个内核时钟，容器里跑 chronyd 基本没意义，改的只是自己 namespace 里的表象。要让容器时间准，把宿主机弄准就完事。

多台机器的结构，几台对公网其余对内

机器一多，全指公网源？不太行吧。出口策略未必放行；公共源也不是欠你的；将来审计，每台机器时间打哪儿来，你说得清吗？常规做法：挑两三台当边界节点，分别指不同上游，其余全指到它们。边界节点开 allow，让内网段来查，比如 allow 192.168.0.0/16——按自己网段写就好。

边界节点上别给自己写 local stratum 自封为王，那是给断网兜底用的，长期开着等于对外宣布我最准，其实你那台的时间也是从上游来的。

层级要短。

一跳和两跳，精度差着一截呢，能一层就别叠三层。

配完怎么验，几个命令就够

timedatectl 先看一眼，NTP synchronized 是不是 yes；Ubuntu 上 systemd-timesyncd 和 chronyd 会打架，两个都想管时间，先停一个，不然你会看到两边互相改。防火墙和安全组要放 123/udp，出方向也得放，很多人只顾着入方向，结果包根本出不去。

偏移特别大的时候 chrony 默认慢慢 slew，不给 step，重启一下 chronyd 让它重新校正一次就好，别手动 date -s 硬敲。

手动改时间不靠谱。

firewalld 的话 firewall-cmd –add-service=ntp –permanent 一句就够；用 iptables 就自己写 -A INPUT -p udp –dport 123 -j ACCEPT，别把整条链清了再重来，那是另一场事故。

几个常见的报错原文

Server not found 多半是主机名解析不到，换成 IP 试一下就知道了；no suitable source 一般是所有源都不可达，或者偏移大到被拒；日志里出现 Can’t synchronise: no selectable sources，就去看 chronyc sources 里是不是一片问号。日志在 /var/log/chrony/，或者 journalctl -u chronyd 翻几行，这事很常见啊，不用想复杂。

云服务器NTP配置落到操作上无非改两行、重启、看状态，真正花时间的是想清楚时间从哪来。内网源图的是稳和可控，公网源图的是省事和准，这俩不是非此即彼：边界机器对公网、内网机器对内网源，中间别叠太多层，偏移隔一阵回头瞄一眼。这几条做到，半夜因为时间问题被叫起来的概率就小多了吧。