本文主要是介绍分享一个 APISIX 网关返回 502 的典型案例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
最近将自己开发的一个消息推送 API 接入我们新上线的定时拨测系统试了下，发现一天内居然发生了几十次 502！
感觉不太可能，因为对自己写的服务还是比较有信心的，于是通过检索网关流水日志和后端服务日志，发现网关确实记录到了 502 的请求记录，但是后端应用并没有收到请求。
于是检索了一下 APISIX[1] 的错误日志，发现对应请求有如下报错：
xxx upstream prematurely closed connection while reading response header from upstream, client: x.x.x.x报错的意思还是比较直白的：网关在读取上游响应头部时，上游服务主动关闭了连接。
快速搜了下关键词，发现主要有两种说法：
上游服务对请求头部大小或请求频率存在限制；
网关启用了 keepalived 会话保持导致的问题。
上游服务就是我自己写的，因此直接排除第一个问题，简单想了下就大概清楚了来龙去脉：
APISIX[2] 为了提高性能，默认会打开keepalived[3]特性，预设会话保持时长为 60s，我们在部署网关的时候也保留了这个优化特性，恰好我的上游服务基于 Gunicorn+FastAPI 开发框架，也开启了 keepalived，会话保持默认设置为 5s。
这样就有问题了：网关和上游服务建立连接后 60s 内，新请求会继续复用这个连接，但是上游却在 5s 后主动关闭了连接，因为网关将新请求转发给上游时，才发现连接已经被关闭了，因此就出现了上述报错。
这个问题在 Nginx 等反向代理场景下同样存在，算是一个很典型的 Case，这里解决问题的办法有两个，要么从网关关闭 keepalived 特性，要么后端的 keepalived 时长设置超过 60s，当然我毫无疑问选择了后者。
改完之后就再也没有出现过类似报错了。
恰好接入网关也是我在运维，本打算将 APISIX[4] 这个全局默认 keepalived 缺省给禁用，但考虑到性能问题，还是继续保持了现状。不过这个问题倒是成为了一个值得注意的典型问题，需要同步给业务运维，如果上游服务开启了 keepalived 特性，需要将 keepalived 超时设置在 60s 以上即可。
这个问题能这么快得到解决，多亏了网上很多前辈大牛分享的定位经验，不然可能还得各种抓包分析，比如这篇文章就写到很清楚：Nginx" upstream prematurely closed connection while reading response header from upstream"问题排查[5]。
最后，在定位问题的时候我也和 APISIX 社区反馈了下，为什么在这个 case 中 APISIX 并没有进行重试？社区反馈 APISIX 并不会无脑重试，有条件限制，感兴趣的同学可以拓展阅读一下：
https://github.com/openresty/openresty/issues/200
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
引用链接
[1]
APISIX: https://zhang.ge/tag/apisix/
[2]APISIX: https://zhang.ge/tag/apisix/
[3]keepalived: https://github.com/apache/apisix/blob/7f9623554e8f0172340fcc933da2cbb2cd8e8234/conf/config-default.yaml#L239-L243
[4]APISIX: https://zhang.ge/tag/apisix/
[5]Nginx" upstream prematurely closed connection while reading response header from upstream"问题排查: https://www.cnblogs.com/coder-yoyo/p/9157148.html
原文链接：https://zhang.ge/5163.html
你可能还喜欢
点击下方图片即可阅读
云原生是一种信仰 🤘
关注公众号
后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！
点击 "阅读原文" 获取更好的阅读体验！
发现朋友圈变“安静”了吗？
这篇关于分享一个 APISIX 网关返回 502 的典型案例的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
