Kong v2.2作为Ingress控制器报HTTP/2流未正常关闭如何解决

报错现象 #

错误日志：HTTP/2 stream 1 was not closed cleanly before end of the underlying stream
已确认特征：所有触发该报错的请求均未从Kong转发至后端业务服务器，异常完全发生在Kong接入层链路。

核心诱发原因 #

• 版本原生Bug：Kong v2.2内置的HTTP/2处理模块存在已知缺陷，当客户端与Kong之间走HTTP/2协议通信时，若Kong侧主动回收空闲连接，不会按照HTTP/2协议规范向客户端发送GOAWAY帧告知连接失效，只会直接断开底层TCP连接。客户端复用本地连接池里的这类失效连接发请求时，就会直接抛出该错误。
• 全链路超时配置不匹配：Kong Ingress默认的http2_idle_timeout（HTTP/2空闲连接超时）参数值，和前置的边缘负载均衡（如云SLB、外层Nginx网关）的HTTP/2连接保活时长不匹配，通常是Kong侧超时时间短于外层LB的保活时间，外层LB将自身连接池内标记为存活的连接转发给Kong时，Kong早已断开对应连接，直接触发连接重置。
• 资源耗尽暴力断连：Kong节点连接数打满、内存占用触达OOM保护阈值、worker进程异常崩溃重启时，会直接强制切断所有现存HTTP/2连接，完全跳过正常的协议关闭流程，该时间窗口内的请求都会触发该报错，且因为连接在接入层就被切断，根本不会转发到后端服务。

解决方案 #

• 版本修复：优先将Kong升级至v2.4及以上稳定版本，该版本线已经修复了HTTP/2连接关闭时不发送GOAWAY帧的原生模块缺陷，从底层解决协议兼容问题。
• 全链路参数对齐：统一调整整条接入链路的HTTP/2空闲超时配置，保证超时值从客户端到外层LB、再到Kong节点逐层递减，例如外层LB配置为600s，Kong侧配置为300s，从根源避免脏连接被复用。参数修改后执行kong reload加载配置即可生效。
• 资源水位兜底：调整Kong节点最大连接数配置，预留至少30%的资源冗余；配置worker进程异常退出后的自动拉起策略，开启僵死进程快速检测能力；流量突增期提前扩容节点，避免资源耗尽导致的无通知断连。
• 紧急规避：如果短时间内无法完成版本升级，可以临时关闭客户端到Kong侧的HTTP/2支持，强制降级为HTTP/1.1协议，该问题会立刻消失，缺点是会损失HTTP/2多路复用的性能收益，仅适合故障紧急恢复场景使用。

内容的提问来源于stack exchange，提问作者israelshenkar