症状
错误文本陈述了全部机制：RequestTimeTooSkewed——签名本身没问题，是时钟不对。直接对着权威测漂移：本地 date -u 对比 AWS 响应的 Date 头，差 21 分钟即真相大白。单主机模式是指纹：同代码同凭证，一台机器失败、其他主机正常——变量不是凭证而是时钟。快照恢复、VM 暂停续跑、容器热迁移造成的时间跳变，是 NTP 渐进漂移永远不会产生的形态。SignatureDoesNotMatch 是它的表亲：模块加载时缓存时间戳、或凭证范围里区域与服务写错，属于另一类修法。
诊断思路
先拿本地时间对 AWS 权威时间测差值，超过几分钟即偏移；再查 NTP 同步状态——timedatectl 的 “System clock synchronized: no” 或 chronyc 的偏移量直接点名故障主机；最后核对签名侧：时间戳是否请求时刻取值（而不是缓存）、凭证范围的日期/区域/服务是否正确。
根因
SigV4 用请求时间戳为每个请求签名，并拒绝超出容忍窗（约 15 分钟）的时间戳以限制重放暴露。主机时钟漂移越过该窗口时，所有签名调用以 RequestTimeTooSkewed 失败——签名有效，只有钟错了。
修复与验证
恢复主机 NTP 同步（chronyd 或 systemd-timesyncd 且服务器可达），让同步服务纠正时钟；时间戳在请求时刻取值而不是模块加载时缓存；SDK 凭证范围钉到正确的区域与服务。验证时重同步后签名调用立即成功；监控显示全部主机时钟偏移在容忍内；再做一次刻意的暂停-恢复测试，确认无错误恢复。手动向前拨钟会破坏 TLS 校验与日志顺序——用 NTP 同步再验证，不要手设。
代码示例
RequestTimeTooSkewed: The difference between the request time
and the server time is too large.date -u
curl -sI https://sts.amazonaws.com | grep -i ^date
# local: Thu, 22 Oct 2026 08:41:03 GMT
# aws: Thu, 22 Oct 2026 09:02:11 GMT <- 21 minutes ahead# enable and start NTP (chronyd or systemd-timesyncd):
timedatectl set-ntp true
timedatectl status # "System clock synchronized: yes"
# measure the drift against AWS directly:
date -u
curl -sI https://sts.amazonaws.com | grep -i ^date