Django执行collectstatic调用AWS S3出现HeadObject ClientError 400问题

该报错已经排除凭证、存储桶权限、项目代码配置层面的问题，故障点集中在异常VPS的本地环境，按优先级依次排查即可：

1. 检查系统时间同步 #

AWS S3的请求签名对时间偏差高度敏感，要求请求发起时间和AWS服务时间差不能超过15分钟，时间偏差是这类同凭证异地报错的最常见原因：

• 执行命令查看当前系统时间：date
• 和标准时间比对如果偏差过大，开启NTP时间同步：
  Debian/Ubuntu系统执行：sudo timedatectl set-ntp true
  CentOS/RHEL系统执行：sudo systemctl enable --now chronyd
• 同步完成后重新执行collectstatic测试。

2. 检查依赖版本一致性 #

故障VPS的依赖版本和正常环境不一致会触发兼容性问题：

• 分别在故障VPS、正常VPS、本地环境执行命令：pip list | grep -E "boto3|botocore|django-storages"，核对三个依赖的版本号
• 把故障环境的依赖版本替换为正常环境的对应版本即可，示例命令：pip install boto3==<正常环境版本号> botocore==<正常环境版本号> django-storages==<正常环境版本号>

3. 检查VPS网络环境 #

• 测试VPS到S3端点的连通性：ping s3.<你的桶实际所在区域>.amazonaws.com，注意替换成你自己的桶区域代码
• 执行env | grep -i proxy检查是否配置了无效系统代理，导致S3请求被拦截
• 核对Django配置里的S3区域代码、端点地址是否和桶实际配置一致，区域配置错误也会直接触发HeadObject 400报错

4. 检查静态文件命名 #

如果以上排查都无异常，可在collectstatic命令后加-v 3参数输出详细执行日志，查看报错前最后处理的静态文件，确认是否存在S3不支持的特殊字符（比如生僻非ASCII字符、未经编码的特殊符号），修改对应文件名即可。

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