为什么CloudFront不遵循S3网站重定向位置？

我有一个托管在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的任何想法？

谢谢

我最近遇到了这个问题，并且发现了一种可行的解决方法。

我创建了一个Cloudfront发行版，其中的自定义来源指向S3静态网站主机名而不是存储桶主机名。在OP的情况下，期望的原点将是。

mysite.s3-website-us-east-1.amazonaws.com

仅使用存储桶作为源来打Cloudfront发行版是行不通的，因为存储桶实际上不提供重定向。它仅提供文件并存储元数据。

希望能有所帮助。

分析

根据记录的请求和响应行为以及自定义来源支持的HTTP状态代码，不幸的是，Amazon CloudFront不遵循重定向：

[...]配置重定向之后，最终用户首次提交对该对象的请求时，CloudFront Front会将请求发送到原始地址，原始地址以重定向响应（例如302临时移动）。CloudFront缓存重定向并将其返回给最终用户。CloudFront不遵循重定向。 [强调我的]

当然，您使用的是Amazon S3而非自定义来源，并且Amazon S3 Origins的请求和响应行为中明显缺少相关部分，但是鉴于Amazon S3重定向只是最近才添加的（请参阅Amazon S3-网站支持）重定向），则可能仍会丢失。

因此，我冒昧地猜测您没有收到HTTP状态代码为200 OK的空文件，而是HTTP状态301永久移动，没有任何正文-您是否实际上是通过浏览器或仅通过命令行工具（例如例如cURL或HTTPie？后面的工具通常需要一个显式参数来跟随重定向，因此很容易被忽视。

潜在解决方案

如果分析结果正确，则需要将重定向配置为显式地定位到CloudFront，再次参见Redirects：

您可以将Web服务器配置为将请求重定向到以下位置之一：

• 源服务器上对象的新URL。当最终用户遵循重定向到新URL时，最终用户将绕过CloudFront并直接到达源。因此，我们建议您不要将请求重定向到原始对象上的新URL。

• 对象的新CloudFront URL。当最终用户提交包含新的CloudFront URL的请求时，CloudFront将从您来源的新位置获取对象，将其缓存在边缘位置，然后将对象返回给最终用户。对对象的后续请求将由边缘位置处理。这避免了与从原点请求对象的观看者相关联的等待时间和负担。但是，对对象的每个新请求都将对向CloudFront的两个请求产生费用。