最近将自己开发的一个消息推送 API 接入我们新上线的定时拨测系统试了下，发现一天内居然发生了几十次 502！
感觉不太可能，因为对自己写的服务还是比较有信心的，于是通过检索网关流水日志和后端服务日志，发现网关确实记录到了 502 的请求记录，但是后端应用并没有收到请求。
于是检索了一下 APISIX 的错误日志，发现对应请求有如下报错：
xxx upstream prematurely closed connection while reading response header from upstream, client: x.x.x.x
报错的意思还是比较直白的：网关在读取上游响应头部时，上游服务主动关闭了连接。
快速搜了下关键词，发现主要有两种说法：
- 上游服务对请求头部大小或请求频率存在限制；
- 网关启用了 keepalived 会话保持导致的问题。
上游服务就是我自己写的，因此直接排除第一个问题，简单想了下就大概清楚了来龙去脉：
APISIX 为了提高性能，默认会打开keepalived特性，预设会话保持时长为 60s，我们在部署网关的时候也保留了这个优化特性，恰好我的上游服务基于 Gunicorn+FastAPI 开发框架，也开启了 keepalived，会话保持默认设置为 5s。
这样就有问题了：网关和上游服务建立连接后 60s 内，新请求会继续复用这个连接，但是上游却在 5s 后主动关闭了连接，因为网关将新请求转发给上游时，才发现连接已经被关闭了，因此就出现了上述报错。
这个问题在 Nginx 等反向代理场景下同样存在，算是一个很典型的 Case，这里解决问题的办法有两个，要么从网关关闭 keepalived 特性，要么后端的 keepalived 时长设置超过 60s，当然我毫无疑问选择了后者。
改完之后就再也没有出现过类似报错了。
恰好接入网关也是我在运维，本打算将 APISIX 这个全局默认 keepalived 缺省给禁用，但考虑到性能问题，还是继续保持了现状。不过这个问题倒是成为了一个值得注意的典型问题，需要同步给业务运维，如果上游服务开启了 keepalived 特性，需要将 keepalived 超时设置在 60s 以上即可。
这个问题能这么快得到解决，多亏了网上很多前辈大牛分享的定位经验，不然可能还得各种抓包分析，比如这篇文章就写到很清楚：Nginx" upstream prematurely closed connection while reading response header from upstream"问题排查 - Hello-YOYO - 博客园 (cnblogs.com)。
最后，在定位问题的时候我也和 APISIX 社区反馈了下，为什么在这个 case 中 APISIX 并没有进行重试？社区反馈 APISIX 并不会无脑重试，有条件限制，感兴趣的同学可以拓展阅读一下：