我们正在运行一个与 API 通信的 SPA。两者都通过 Cloudfront 向公众公开。
我们现在遇到的问题是，我们在后端看到的请求被 Cloudfront 屏蔽了。含义：
所以 Cloudfront 以某种我们没有预料到的方式拦截了请求。
我已经完成了这些步骤：https://aws.amazon.com/premiumsupport/knowledge-center/configure-cloudfront-to-forward-headers/，但最终切断了 API 和前端之间的连接。
我们不关心缓存的影响（我们没有很多流量），我们只需要正确的字段显示在后端。
【问题讨论】：
标签： api single-page-application amazon-cloudfront
默认情况下，大多数请求标头都会被删除，因为 CloudFront 的默认行为通常是围绕优化缓存而设计的。 CloudFront 的默认标头处理行为is documented。
如果您需要查看源头的特定标头，请将这些标头列入白名单以便在缓存分发中转发。文档将此称为“Selecting the Headers on Which You Want CloudFront to Base Caching” - 这就是它的作用 - 但该描述掩盖了实际发生的事情。 CloudFront 会删除其余的标头，因为它无法确定具有特定值的特定标头是否可能会更改源生成的响应。如果默认情况下不删除这些标头，那么当用户看到缓存提供的“错误”响应时，就会在另一个方向上产生混淆。
在您的情况下，您几乎肯定不想将 Host 标头包含在要转发的白名单中。
尤其是在测试的时候，请确保你也set the Error Caching Minimum TTL to 0，因为默认值是300秒……所以你在修复后最多5分钟内看不到问题是否得到修复。此默认设置也是设计使然，这是一种保护措施，可避免因请求可能继续失败而使您的源过载。
在检查来自 CloudFront 的响应时，请留意 Age 响应标头，该标头在从缓存提供响应时出现。它告诉您距离 CloudFront 获得当前返回给您的响应已经过去了多长时间（以秒为单位）。
如果您想禁用 CloudFront 缓存，您可以将最大、最小和默认 TTL 全部设置为 0（这仅影响 2xx 和 3xx HTTP 响应 - 错误缓存在不同的时间窗口，如上所述），或者您的源可以始终返回 Cache-Control: s-maxage=0，这将阻止 CloudFront 缓存响应。
【讨论】：