我设置了CloudFront分配以与Custom Origin - 我客户的网络服务器（www.mydomain.com）配合使用。
当我加载网页并检查Chrome网络检查员的“网络”标签时，资源显示为来自原始服务器（www.mydomain.com），“发起人”列将CloudFront网址显示为重定向。我认为这意味着CloudFront正在将资产请求重定向到我的原始服务器，这几乎违背了目的。
当我设置发行版时，我将TTL保留为默认值，我认为这意味着24小时。
如果我使用S3存储桶作为源而不是Web服务器，则资产会按预期直接从CloudFront加载。
答案 0 :(得分：8)
如果您在资产的网址中看到自己的服务器域，则表示CloudFront在获取资产时收到重定向响应，并将该重定向作为缓存结果提供。这绝对不是你想要的。
我有一个类似的问题，我在看到这篇文章中的一个答案后解决了这个问题：
Magento - Amazon Cloudfront CDN and Caching
我从domain.com重定向到www.domain.com，CloudFront正在缓存并返回该重定向。您可能会看到http / https重定向的相同内容。
如果你正在做HTTP - ＆gt; HTTPS重定向，您有两种选择：您可以将资产作为HTTP提供给CloudFront，也可以让CloudFront将它们作为HTTPS请求。要执行后者，您需要将CloudFront原点配置为“匹配查看器”。这意味着如果观众使用HTTPS，CloudFront也会。如果用户使用HTTP，CloudFront将在HTTP中请求，返回从服务器收到的HTTPS重定向，然后客户端将以HTTPS形式重新发出请求。
在我们的案例中，资产本身不需要在飞行中受到保护。它们从CloudFront作为HTTPS提供服务非常重要，因此用户的浏览器可以看到所有HTTPS内容。因此，在我们的案例中，没有必要将资产作为HTTPS提供给CloudFront。无论它如何从我们的服务器获取内容，CloudFront都会在响应时匹配查看器的协议。
答案 1 :(得分：3)
这是一个迟到的答案，但是如果有人偶然发现这个问题，我在没有使用任何HTTPS重定向的情况下遇到了同样的问题。
在Cloudfront中，我的起源是＆＃34; mysite.com＆＃34;，当网站实际上是＆＃34; www.mysite.com＆＃34;。我在Cloudfront中更新了它，现在它可以工作了！