谁能想到：6202年了还在用 crontab + HTTP Header 做时间同步
内容提要
2026年1月，隔离网络集群因UDP被阻断导致NTP失效，节点时钟漂移约38秒，引发Prometheus告警和Teleport握手失败。排查确认是时钟问题后，停用chrony，改用跳板机HTTP响应的Date头手动校时，恢复服务，并用crontab每小时同步。经验：隔离网络勿假设NTP可用，nc -u不可靠，Prometheus和Teleport对时钟漂移敏感。
延伸解读
隔离网络中的时间同步陷阱
文章指出，在隔离网络中，UDP 123 端口可能被阻断，导致 NTP 无法工作。chrony 服务虽然运行，但实际无法同步时间，容易给人“服务正常”的假象。这提醒运维人员，不能假设 NTP 在隔离环境中可用，需提前验证 UDP 连通性，并准备备用时间同步方案。
UDP 连通性测试的不可靠性
作者使用 nc -u 测试 UDP 端口时，命令显示成功，但抓包发现数据包并未到达对端。这是因为 UDP 无连接，nc 的成功提示并不代表远端收到数据。在排查网络问题时，应结合 tcpdump 等抓包工具确认实际流量，避免被表面现象误导。
时钟漂移对关键服务的影响
Prometheus 和 Teleport 对时钟漂移非常敏感。仅 38 秒的偏差就导致 Prometheus 图表异常，而 Teleport 因握手安全校验直接拒绝连接，表现为 SSH 不可达。这类症状容易误判为网络故障，实际根源可能是时钟问题。运维中应监控时钟偏差，并了解相关服务的容忍阈值。
HTTP Date 同步的临时方案与局限
作者利用跳板机 HTTP 响应的 Date 头手动校时，并通过 crontab 每小时同步。该方法仅需 HTTP 可达，精度为秒级，适合应急恢复。但长期来看，crontab 方案较为粗糙，作者建议未来改用 systemd timer 等更可靠的方式。这体现了在受限环境中权衡可用性与优雅性的思路。
Q&A
隔离网络里NTP失效导致时钟漂移，会引发哪些具体问题？
Prometheus会显示时钟漂移警告，例如检测到38秒的时间差，这足以破坏图表；Teleport握手会失败，导致SSH无法连接。
为什么在隔离网络中chrony看起来在运行却无法同步时间？
因为隔离网络阻断了UDP，NTP依赖UDP 123端口，一旦被阻断，chrony虽然进程在运行，但无法与外部时间服务器通信，实际上没有同步任何时间。
如何用HTTP Date头手动校正服务器时间？
先停止并禁用chrony，然后从跳板机的HTTP响应中提取Date头，用date -s命令设置时间。示例：HTTP_DATE=$(curl -sI http://100.64.0.5 | grep -i "^Date:" | cut -d" " -f2-) && date -s "$HTTP_DATE"。
怎样让HTTP Date时间同步持久化，避免节点再次漂移？
将同步命令加入crontab，每小时执行一次。示例：`(crontab -l 2>/dev/null; echo '0 * * * * HTTP_DATE=$(curl -sI http://100.64.0.5 | grep -i "^Date:" | cut -d" " -f2-) && [ -n "$HTTP_DATE" ] && date -s "$HTTP_DATE"') | crontab -`。
为什么不能用nc -u命令测试UDP连通性？
因为UDP没有握手过程，nc -u可能显示连接成功，但实际上数据包并未到达对端。需要结合tcpdump抓包确认。
在隔离网络环境中运维，有哪些关于时间同步的经验教训？
不要假设NTP可用，UDP 123可能被阻断；不要轻信nc -u的结果；Prometheus和Teleport对时钟漂移敏感，几十秒的偏差就可能表现为网络故障；长期方案建议用systemd timer替代crontab。
