我们正在运行与API通信的SPA。两者都通过Cloudfront向公众公开。
我们现在遇到的问题是，我们在后端看到的请求被Cloudfront掩盖了。含义：
因此Cloudfront以某种我们无法预期的方式拦截了请求。
我已经完成了以下步骤：https://aws.amazon.com/premiumsupport/knowledge-center/configure-cloudfront-to-forward-headers/，但最终切断了API与前端之间的连接。
我们不在乎缓存的含义（我们没有很多流量），我们只需要将正确的字段显示在后端即可。
答案 0 :(得分：0)
默认情况下，大多数请求标头都将被删除，因为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缓存响应。