从你给出的错误信息来看，核心问题很明确：生成预签名URL的服务器时间和S3的服务器时间严重不同步，而且所有URL都用了同一个固定的过期时间，这两个点是关键。下面是一步步的排查和解决思路：

1. 优先检查服务器时钟同步状态 #

错误里显示S3的服务器时间是2018-05-28T00:20:17Z，但你的预签名URL的过期时间是2018-05-27T22:56:29Z——也就是说，当你请求这个URL的时候，S3的时间已经比过期时间晚了1小时40多分钟。如果所有生成的URL都用这个过期时间，大概率是生成URL的服务器时钟严重滞后了，没有和UTC时间同步。

• 登录生成预签名URL的服务器，执行命令检查当前系统UTC时间：

  date -u
  

• 对比这个时间和S3返回的ServerTime，如果偏差超过几分钟，就说明时钟同步出问题了。
• 修复方法：重启服务器的NTP服务（比如systemctl restart ntpd或者systemctl restart chronyd），或者手动同步时间，确保系统时间和UTC时间一致。

2. 检查代码中是否硬编码了过期时间 #

如果服务器时间是正常的，那就要看生成预签名URL的代码逻辑是不是出问题了：

• 确认代码里是动态计算1小时后的过期时间，而不是不小心把过期时间硬编码成了2018-05-27T22:56:29Z这个固定值。
• 比如用AWS SDK的话，正确的做法应该类似（以Python为例）：

  import boto3
  from datetime import timedelta
  
  s3 = boto3.client('s3')
  url = s3.generate_presigned_url(
      'get_object',
      Params={'Bucket': 'your-bucket', 'Key': 'your-object'},
      ExpiresIn=3600  # 动态计算1小时后过期，而非固定时间
  )
  

• 如果代码里误把ExpiresIn换成了固定的过期时间戳，或者直接写死了Expires参数，就会导致所有URL都用同一个过期时间。

3. 排查AWS SDK版本或配置变化 #

如果最近更新过AWS SDK，或者修改过SDK的配置，可能会导致预签名URL的生成逻辑异常：

• 对比之前正常运行的代码版本，看看有没有关于预签名URL生成的代码变更。
• 尝试回退到之前确认正常的SDK版本，测试是否能生成正确的预签名URL。

4. 排除其他低概率可能性 #

虽然错误信息明确是过期，但还是可以快速排查下：

• 确认IAM角色/用户的权限没有变化：如果权限被修改，错误信息通常会是AccessDenied但不会附带过期相关字段，所以这个可能性较低，但可以确认下生成预签名URL的身份是否还拥有s3:GetObject权限。
• 检查是否有代理或防火墙修改了请求的时间头：不过这种情况很少见，而且会影响所有请求，不会是突然出现的。

按照这个顺序排查，应该能快速定位问题——大概率是服务器时钟漂移或者代码里的过期时间被硬编码了。

内容的提问来源于stack exchange，提问作者user1974753