如何最好地管理 AWS 中的 Cloudfront/Nginx 502 Bad Gateway 错误

Question

我们有一个通过 CloudFront 提供服务的网站。本周某个时候，源 EC2 (ECS) 服务器崩溃了，并在短时间内开始返回 502 错误：

502 错误网关 | Nginx

这个问题很快得到解决，但我们有几个用户仍然在他们的浏览器中看到错误。他们都在使用 Google Chrome，而且问题似乎一直存在（就像浏览器/CloudFront 已经缓存了错误）。一位用户通过进入隐身模式解决了该问题，另一位用户每次点击我们新闻通讯中的链接时都会看到该问题。其他一些用户仅通过使用不同的浏览器解决了这个问题。

我不确定如何开始调试。另外，我想如果接收到 502 错误，它不会缓存页面内容。另外，我无法从我这里复制。

为问题添加额外信息：

我不是在寻找有关如何停止或管理 502 错误网关错误的建议。我们知道为什么会发生这些问题（ed）这个问题纯粹是关于在将缓存的 502 错误交付给用户后修复它们的建议。

从目前的反馈来看，我们似乎可以在 10 秒后在 CloudFront 中取消缓存 502 错误。此功能已启用，但问题仍然存在。

我的感觉是用户的浏览器已经缓存了 503 错误页面并且没有从服务器请求更新。在不让他们清除缓存的情况下，有没有办法将 CloudFront 或他们的浏览器设置为仅在短时间内缓存 502 错误，然后再从服务器请求更新页面？

另外，再想想这个。错误是'502 Bad Gateway | Nginx' 这甚至来自 CloudFront 吗？我的服务器可以发送很长时间吗 带有 502 错误的 Cache-Control 标头？

Answer 1

在走了很多死胡同之后，我终于找到了解决这个问题的方法。很抱歉，最初的问题的假设不正确。但无论如何感谢大家的意见。我之前遇到的 502 错误仅限于原始服务器出现故障的情况。因此，当我们的少数用户开始收到持续的 502 错误时，当服务器正常运行时，我立即认为这是 CloudFront 缓存问题。源服务器已经崩溃，正在为这些不幸的用户缓存 502 错误。

经过更多调试后，实际问题是由于当用户从我们的电子邮件访问网站时设置了一个大的（不断增长的）cookie。如果用户没有登录，cookie 会随着时间的推移保存更多数据并增大文件大小。这仅限于 cookie 的最大文件大小。但它没有考虑 Nginx 的标头限制。因此，这会产生“上游发送的标头太大”错误。因此 502. 删除 cookie 并增加标头限制解决了这个问题。一旦我们的用户的 cookie 被删除或过期，我们将随着时间的推移降低限制。

fastcgi_buffers 8 16k;

更新为：

fastcgi_buffers 16 16k;

upstream sent too big header while reading response header from upstream

Answer 2

如果您遇到错误 502，请进行无效操作...为您的所有用户提供干净的缓存。

Cloudfront -> Distributions -> Your Distribution -> Invalidations Tab -> Create Invalidation -> 放入文本框“/*”，不带引号 -> Invalidate

仅此而已。

我建议您研究为什么您有 Bad Gateway（可能是一周中特定日期的规模）并在特定时间为当天安排更多容器。 :)