经Cloudflare代理的MinIO实例执行HeadObject请求返回403而非404问题

问题分析 #

通过Cloudflare代理访问MinIO时，对不存在的对象发送HeadObject请求会返回403状态码，但GET/PUT/DELETE操作均正常——甚至对同一个不存在的对象发送GetObject能返回预期的404。这种差异通常由两个原因导致：

• Cloudflare的安全规则拦截了HEAD请求的404响应，误判为未授权操作
• MinIO的Bucket Policy未明确允许HEAD操作，而公开访问配置仅对GET生效

解决方案 #

1. 检查并调整Cloudflare安全规则 #

• 进入Cloudflare控制台，查看目标域名的防火墙规则，确认是否有针对HEAD请求的拦截策略。如果存在，可临时禁用规则测试，或添加例外：允许对MinIO域名的HEAD请求正常返回404。
• 检查安全级别设置，过高的安全级别可能对HEAD请求做额外校验，导致误返回403。

2. 修正MinIO的Bucket Policy #

确保Bucket Policy明确允许HEAD操作，尤其是公开访问的Bucket。示例Policy如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:HeadObject"],
      "Resource": "arn:aws:s3:::mybucket/*"
    }
  ]
}

通过MinIO控制台或mc命令更新Policy后，重新测试HeadObject请求。

3. Django-storages临时适配方案 #

如果暂时无法修改Cloudflare或MinIO配置，可重写django-storages的存储类，将403错误视为对象不存在：

from storages.backends.s3boto3 import S3Boto3Storage

class CustomS3Storage(S3Boto3Storage):
    def exists(self, name):
        try:
            self.connection.head_object(Bucket=self.bucket_name, Key=name)
            return True
        except self.connection.exceptions.ClientError as e:
            error_code = e.response['Error']['Code']
            # 将403和404都视为对象不存在
            if error_code in ['403', '404']:
                return False
            # 其他异常正常抛出
            raise

在项目settings.py中替换默认存储类：

DEFAULT_FILE_STORAGE = 'yourapp.storage.CustomS3Storage'
STATICFILES_STORAGE = 'yourapp.storage.CustomS3Storage'

这样collectstatic命令检查文件是否存在时，会把403错误当作对象不存在处理，避免执行失败。

内容的提问来源于stack exchange，提问作者şuayip özülmez