為什麼 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.htmlS3 重定向元數據相當於一個
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 分發是行不通的，因為儲存桶實際上並不提供重定向服務。它只提供文件和儲存元數據。
希望有幫助。
分析
根據記錄的Request and Response Behavior 以及 Supported HTTP Status Codes for Custom Origins ，不幸的是，Amazon CloudFront不遵循Redirects：
$$ … $$ 配置重定向後，最終使用者首次送出對象請求時，CloudFront Front 將請求發送到源，源以重定向響應（例如，302 Moved Temporarily）。CloudFront 記憶體重定向並將其返回給最終使用者。CloudFront 不遵循重定向。 $$ emphasis mine $$
當然，您使用的是Amazon S3而不是自定義源，並且 Amazon S3 源的請求和響應行為中明顯缺少相關部分，但鑑於最近才添加了 Amazon S3 重定向（請參閱Amazon S3 - 對網站的支持重定向），它可能仍然在那裡失去。
因此，我冒昧地猜測您沒有收到帶有 HTTP 狀態程式碼200 OK的空文件，而是 HTTP 狀態301 Moved Permanently沒有正文 - 您是否真的用瀏覽器檢查過這個，或者最終只用命令行工具檢查例如cURL或HTTPie？後一種工具通常需要一個顯式參數來跟踪重定向，因此這很容易被忽視。
潛在解決方案
如果分析結果是正確的，您需要將重定向配置為明確定位 CloudFront，再次參見重定向：
您可以將 Web 伺服器配置為將請求重定向到以下位置之一：
- 源伺服器上對象的新 URL。當最終使用者遵循重定向到新 URL 時，最終使用者會繞過 CloudFront 並直接進入源。因此，我們建議您不要將請求重定向到源上對象的新 URL。
- 對象的新 CloudFront URL。當最終使用者送出包含新 CloudFront URL 的請求時，CloudFront 從源上的新位置獲取對象，將其記憶體在邊緣位置，並將對象返回給最終使用者。對對象的後續請求將由邊緣位置提供服務。這避免了與查看者從源請求對象相關的延遲和負載。但是，對對象的每個新請求都會產生對 CloudFront 的兩次請求的費用。