如何解决 SPA 上的“x-cache：来自云端的错误”

Question

我们在尝试使用客户端路由器（反应路由器）进行 SPA 工作时遇到问题。我们使用 DOMAIN -> CDN (CloudFront) -> S3 的概念来提供我们的静态文件。

我们已将 S3 配置为提供静态文件。 CDN 配置为来自 S3，我们配置了自定义错误页面来捕获错误：

通过这个配置，我们可以捕捉到这样的错误：

https://www.example.com/custom-url

CDN 会将所有 404/403 错误重定向到主 index.html 和 react router 将获得正确的路由。

我们的站点正常工作，客户端路由器工作正常，但我们的 CDN 响应 x-cache: Error from cloudfront 时出现问题：

如果我们在没有任何查询参数（不是查询字符串）的情况下访问主 url https://www.example.com 一切正常。

我怎样才能解决这个问题并使我的所有动态 URL 都能正常工作？

谢谢。

Answer 1

当您访问 http://mywebsite.com 时，请求将命中 S3 中的 index.html 文件。然后您可以单击一个按钮并转到http://mywebsite.com/stats，这是您的 SPA 应用程序的内部路由。因此，它不会触发任何后端请求。

但如果您重新加载页面，http://mywebsite.com/stats 将被发送到 S3，因为您的浏览器不知道您正在运行 SPA 前端。

S3 将返回带有 index.html 的 403 错误，Cloudfront 将向您发送该错误。

解决方案是在 Cloudfront 中使用边缘 lambda 函数。举个例子：

const path = require('path')

exports.handler = (evt, ctx, cb) => {
    const {request} = evt.Records[0].cf

    if (!path.extname(request.uri)) {
        request.uri = '/index.html'
    }

    cb(null, request)
}

来源：https://hackernoon.com/how-to-host-a-single-page-application-with-aws-cloudfront-and-lambda-edge-39ce7b036da2

Answer 2

Amazon CloudFront 的配置和调试错误代码可能会变得棘手 - 将其追溯到其根本原因可能需要几个小时。但是，您可能需要在进入日志之前进行以下检查。

---

存储桶名称！

存储桶名称应与您托管的网站名称相匹配。

例如，要在 Amazon S3 上托管 your-domain.com 网站，您需要创建一个名为 your-domain.com 的存储桶。

要在 www.your-domain.com 下托管网站，您可以将存储桶命名为 www.your-domain.com。

最佳做法是为 your-domain.com 和 www.your-domain.com 创建存储桶。

将您的设置/配置中的现有逻辑用于这些存储桶中的任何一个，并将其用于为静态网站提供服务。使用另一个桶将请求重定向到原来的桶。

老实说，这不会给您带来麻烦，因为您已将您的系统与 Amazon CloudFront 集成，可以将其配置为使用任何名称的 Amazon S3 存储桶。

使用 Amazon CloudFront，访问您的域的用户将直接从 CloudFront 分配中获取数据，该分配反过来缓存我们 S3 存储桶中的内容。

---

配置分发的源设置。

在使用 Amazon CloudFront 创建分配时，请记下具有源域名的关联 Amazon S3 终端节点。确保使用网站端点和NOT REST 端点。不要使用 CloudFront 自动建议的端点。

Amazon Web Services official documentation 中解释的行为有所不同

---

4XX错误代码！

从您的控制台日志中，它表明分发实例正在尝试访问被禁止的元素、页面或资源，因此是 403 状态代码。

虽然 404 只是页面未找到的结果。但是，在错误重定向之后 - 如您的配置中处理的那样，用户将被重定向回遇到 403 的index.html。

更多信息 - How CloudFront Processes and Caches HTTP 4xx and 5xx Status Codes from Your Origin

---

其他常见的嫌疑人包括 Amazon CloudFront 分配的缓存配置、AWS Route53 设置和 Amazon Certificate Manager。

如开头所述，在跟踪此类错误时会变得相当复杂。让我们知道以上是否有帮助。另外，如果您能发布有关您的调查和发现的最新信息，我将不胜感激。

感谢阅读。