我们的负载均衡器对某些请求返回 502 错误。这只是总请求的一个非常低的百分比，我们每小时大约有 36000 个请求和大约 40 个错误，因此只有 0.01% 的请求返回错误。
发生错误时实例是健康的，我们已将此转发规则添加到负载均衡器的防火墙:130.211.0.0/22 tcp:1-5000 适用于所有目标
这不是一个非常严重的问题，因为应用程序可以容忍此类错误，但我想知道为什么会出现这些错误。
任何帮助将不胜感激。
最佳答案
似乎没有一个简单的解决方案。
正如 Mike Fotinakis 在 this blog 中解释的那样(感谢您提供此信息 JasonG :)):
It turns out that there is a race condition between the Google Cloud HTTP(S) Load Balancer and NGINX’s default keep-alive timeout of 65 seconds. The NGINX timeout might be reached at the same time the load balancer tries to re-use the connection for another HTTP request, which breaks the connection and results in a 502 Bad Gateway response from the load balancer.
在我的情况下，我将 Apache 与 mpm_prefork 模块一起使用。提出的解决方案是将连接的keepalive超时时间增加到650s，但这是不可能的，因为每个连接都会打开一个新进程(因此这将代表资源的极大浪费)。
更新:
官方负载均衡器文档页面上似乎有一些关于这个问题的新文档(搜索“超时和重试”):https://cloud.google.com/compute/docs/load-balancing/http/
他们建议在两种情况下(Apache 和 Nginx)都将 KeepAliveTimeout 值设置为 620。
关于google-compute-engine - GCP HTTP 负载平衡中的一些 502 错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41305122/