我们的负载均衡器为某些请求返回502错误。它只占总请求的百分比非常低，我们每小时有大约36000个请求，每小时大约有40个错误，因此只有0.01％的请求会返回错误。
发生错误时实例正常，我们已将此转发规则添加到负载均衡器的防火墙： 130.211.0.0/22 tcp：1-5000适用于所有目标
这不是一个非常严重的问题，因为应用程序可以容忍这些错误，但我想知道为什么给它们。
任何帮助都会被贬低。
答案 0 :(得分：10)
似乎没有一个简单的解决方案。
正如Mike Fotinakis在this blog中解释的那样（感谢您提供此信息JasonG :)）：
事实证明，Google Cloud HTTP（S）负载均衡器与NGINX的默认保持有效超时为65秒之间存在竞争条件。在负载均衡器尝试重新连接另一个HTTP请求的同时，可能会达到NGINX超时，这会中断连接并导致来自负载均衡器的502 Bad Gateway响应。
在我的情况下，我使用Apache和mpm_prefork模块。建议的解决方案是将连接keepalive超时增加到650s，但这是不可能的，因为每个连接都会打开一个新进程（因此这会浪费很多资源）。
<强>更新
似乎在官方负载均衡器文档页面上有一些关于此问题的新文档（搜索＆＃34;超时和重试＆＃34;）：https://cloud.google.com/compute/docs/load-balancing/http/
他们建议在两种情况下都将KeepAliveTimeout值设置为620（Apache和Nginx）。
答案 1 :(得分：9)
但我犯了更多错误 - 1/10。有负载均衡器日志可以告诉您原因是什么，文档解释原因。
我的是： jsonPayload：{statusDetails：“failed_to_pick_backend”@type：“type.googleapis.com/google.cloud.loadbalancing.type.LoadBal ancerLogEntry”}
如果你正在使用nginx并且它在POSTS上并且错误被报告为“backend_connection_closed_before_data_sent_to_client”，则可以通过更改你的nginx超时来修复它。看到这篇优秀的博文：
答案 2 :(得分：0)
检查您的后端防火墙是否阻止了Google的云cdn ip地址（不仅仅是130.211.0.0/22），所有这些地址都可以在这里找到：https://cloud.google.com/compute/docs/faq#find_ip_range