如何最好地管理 AWS 中的 Cloudfront/Nginx 502 Bad Gateway 错误
How best to manage Cloudfront/Nginx 502 Bad Gateway errors in AWS
我们有一个通过 CloudFront 提供服务的网站。本周某个时候，原始 EC2 (ECS) 服务器崩溃并在短时间内开始返回 502 错误：
502 错误网关 | Nginx
这个问题很快就解决了，但是我们有几个用户仍然在他们的浏览器中看到错误。他们都在使用 Google Chrome 并且问题似乎一直存在（比如 browser/CloudFront 已经缓存了错误）。一位用户通过进入隐身模式解决了该问题，另一位用户每次点击我们时事通讯中的 link 时都会看到该问题。其他一些用户仅通过使用不同的浏览器解决了该问题。
我不确定如何开始调试它。另外，我想如果收到 502 错误，它就不会缓存页面内容。另外，我无法从我的结尾复制。
向问题添加额外信息：
我不是在寻求有关如何停止或管理 502 错误网关错误的建议。我们知道为什么会发生这些（ed）这个问题纯粹是关于在将缓存的 502 错误传递给用户后修复它们的建议。
从目前的反馈来看，我们似乎可以在 10 秒后取消缓存 CloudFront 中的 502 错误。这已启用，但问题仍然存在。
我的感觉是用户的浏览器缓存了 503 错误页面，并且没有请求服务器更新。在不让他们清除缓存的情况下，有没有一种方法可以将 CloudFront 或他们的浏览器设置为在从服务器请求更新页面之前仅在短时间内缓存 502 错误？
另外，又在想这个。错误是'502 Bad Gateway | Nginx' 这甚至来自 CloudFront？我的服务器可以发送长吗
Cache-Control headers 有 502 个错误？
如果您遇到错误 502，请执行失效...为您的所有用户清理缓存。
Cloudfront -> Distributions -> Your Distribution -> Invalidations 选项卡 -> Create Invalidation -> 在文本框“/*”中不带引号 -> Invalidate
仅此而已。
我建议你研究为什么你有 Bad Gateway（可能是一周中特定日期的规模）并在特定时间为那天安排更多容器。 :)
在走了很多弯路之后，我终于找到了解决这个问题的方法。抱歉，最初的问题在其假设中是不正确的。但无论如何，感谢大家的投入。我以前的 502 错误经验仅限于原始服务器出现故障的情况。因此，当我们的少数用户开始收到持续的 502 错误时，当服务器正常运行时，我立即认为这是 CloudFront 缓存问题。原始服务器已崩溃，并为这些不幸的用户缓存了 502 错误。
经过更多调试后，实际问题是由于当用户通过我们的电子邮件访问网站时设置了一个大的（不断增长的）cookie。如果用户没有登录，cookie 会随着时间的推移保存更多的数据，文件也会变大。这仅限于 cookie 的最大文件大小。但它并没有指望 Nginx 的 header 限制。所以这造成了 'upstream sent too big header' 错误。因此 502。删除 cookie 并增加 header 限制解决了这个问题。一旦我们的用户的 cookie 被删除或过期，我们将随着时间的推移降低限制。
fastcgi_buffers 8 16k;
更新为：
fastcgi_buffers 16 16k;
upstream sent too big header while reading response header from upstream
我们有一个通过 CloudFront 提供服务的网站。本周某个时候，原始 EC2 (ECS) 服务器崩溃并在短时间内开始返回 502 错误：
502 错误网关 | Nginx
这个问题很快就解决了，但是我们有几个用户仍然在他们的浏览器中看到错误。他们都在使用 Google Chrome 并且问题似乎一直存在（比如 browser/CloudFront 已经缓存了错误）。一位用户通过进入隐身模式解决了该问题，另一位用户每次点击我们时事通讯中的 link 时都会看到该问题。其他一些用户仅通过使用不同的浏览器解决了该问题。
我不确定如何开始调试它。另外，我想如果收到 502 错误，它就不会缓存页面内容。另外，我无法从我的结尾复制。
向问题添加额外信息：
我不是在寻求有关如何停止或管理 502 错误网关错误的建议。我们知道为什么会发生这些（ed）这个问题纯粹是关于在将缓存的 502 错误传递给用户后修复它们的建议。
从目前的反馈来看，我们似乎可以在 10 秒后取消缓存 CloudFront 中的 502 错误。这已启用，但问题仍然存在。
我的感觉是用户的浏览器缓存了 503 错误页面，并且没有请求服务器更新。在不让他们清除缓存的情况下，有没有一种方法可以将 CloudFront 或他们的浏览器设置为在从服务器请求更新页面之前仅在短时间内缓存 502 错误？
另外，又在想这个。错误是'502 Bad Gateway | Nginx' 这甚至来自 CloudFront？我的服务器可以发送长吗 Cache-Control headers 有 502 个错误？
如果您遇到错误 502，请执行失效...为您的所有用户清理缓存。
Cloudfront -> Distributions -> Your Distribution -> Invalidations 选项卡 -> Create Invalidation -> 在文本框“/*”中不带引号 -> Invalidate
仅此而已。
我建议你研究为什么你有 Bad Gateway（可能是一周中特定日期的规模）并在特定时间为那天安排更多容器。 :)
在走了很多弯路之后，我终于找到了解决这个问题的方法。抱歉，最初的问题在其假设中是不正确的。但无论如何，感谢大家的投入。我以前的 502 错误经验仅限于原始服务器出现故障的情况。因此，当我们的少数用户开始收到持续的 502 错误时，当服务器正常运行时，我立即认为这是 CloudFront 缓存问题。原始服务器已崩溃，并为这些不幸的用户缓存了 502 错误。
经过更多调试后，实际问题是由于当用户通过我们的电子邮件访问网站时设置了一个大的（不断增长的）cookie。如果用户没有登录，cookie 会随着时间的推移保存更多的数据，文件也会变大。这仅限于 cookie 的最大文件大小。但它并没有指望 Nginx 的 header 限制。所以这造成了 'upstream sent too big header' 错误。因此 502。删除 cookie 并增加 header 限制解决了这个问题。一旦我们的用户的 cookie 被删除或过期，我们将随着时间的推移降低限制。
fastcgi_buffers 8 16k;
更新为：
fastcgi_buffers 16 16k;
upstream sent too big header while reading response header from upstream