我有一个托管在 Amazon S3 上的网站。它是托管在 WordPress 上的旧网站的新版本。
我已经设置了一些带有元数据的文件Website Redirect Location来处理旧位置并将它们重定向到新的网站页面。
例如：我http://www.mysite.com/solution想要重定向到因此我在存储桶内http://mysite.s3-website-us-east-1.amazonaws.com/product.html创建了一个名为“空文件”，并使用正确的元数据：solution
Website Redirect Location=/product.html
S3 重定向元数据相当于301 Moved Permanently对 SEO 非常有用的。当直接从 S3 域访问 URL 时，这非常有用。
我还根据网站存储桶设置了 CloudFront 分发。当我尝试通过我的分发进行访问时，重定向不起作用，即：
http://xxxx123.cloudfront.net/solution不重定向而是下载空文件。
所以我的问题是如何通过 CloudFront 分发保持重定向？或者有什么关于如何在不影响 SEO 的情况下处理重定向的想法吗？
谢谢
答案1
我最近遇到了这个问题并且找到了一个似乎有效的解决方法。
我创建了一个 Cloudfront 发行版，其中自定义源指向 S3 静态网站主机名，而不是存储桶主机名。在 OP 的案例中，所需的源是。
mysite.s3-website-us-east-1.amazonaws.com
仅使用 bucket 作为源来访问 Cloudfront 分发是行不通的，因为 bucket 实际上并不提供重定向服务。它只提供文件和存储元数据。
希望有所帮助。
答案2
分析
据记载请求和响应行为以及自定义来源支持的 HTTP 状态代码，亚马逊 CloudFront不符合重定向， 很遗憾：
[...] 配置重定向后，最终用户第一次提交对象请求时，CloudFront Front 会将该请求发送到源，源会通过重定向进行响应（例如，302 暂时移动）。CloudFront 缓存重定向并将其返回给最终用户。CloudFront 不会遵循重定向。 [重点是我的]
当然，你正在使用亚马逊 S3而不是自定义来源，并且相关部分明显缺失Amazon S3 源的请求和响应行为，但鉴于 Amazon S3 重定向功能最近才刚刚添加（请参阅Amazon S3 - 支持网站重定向)，它可能仍然缺失在那里。
因此，我大胆猜测您没有收到带有 HTTP 状态代码的空文件200 正常而不是 HTTP 状态301 永久移动没有任何主体 - 您是否真的使用浏览器检查过，或者最终仅使用命令行工具（例如卷曲或者HTTPie? 后一种工具通常需要明确的参数来跟随重定向，因此这很容易被忽视。
潜在解决方案
如果分析结果正确，您需要将重定向配置为明确以 CloudFront 为目标，再次参见重定向：
您可以配置 Web 服务器以将请求重定向到以下位置之一：
源服务器上对象的新 URL。当最终用户按照重定向到新 URL 时，最终用户将绕过 CloudFront 并直接转到源。因此，我们建议您不要将请求重定向到源上对象的新 URL。
对象的新 CloudFront URL。当最终用户提交包含新 CloudFront URL 的请求时，CloudFront 会从源上的新位置获取对象，将其缓存在边缘站点，然后将对象返回给最终用户。该对象的后续请求将由边缘站点提供服务。这可避免与查看器从源请求对象相关的延迟和负载。但是，每个新的对象请求都将产生两次 CloudFront 请求的费用。
答案3
只需补充一点 - 在 Lambda @ Edge 中可以看到“x-amz-website-redirect-location”标头（大概也是 Cloudfront 函数），如果标头存在于 S3 响应中，则可以使用它来生成 301/302 响应。
答案4
我知道已经八年了，但如果有人发现这一点，CloudFront 通过网站模式（如接受的答案中所述）或使用 Origin Access Identity 在非网站模式下前置 S3 连接到 S3。我发现自己在这里寻找一种解决方案，以解决切换到非网站模式后与 S3（网站模式）一起工作的重定向问题；因此，重新打开它是行不通的。
我在亚马逊文档中发现以下内容：重定向功能. 此功能可用于发出重定向，甚至无需联系原始服务器。