连接池 maxLifetime 设了 30min 仍偶发 Connection reset by peer：如何区分是 DB wait_timeout 还是中间 NAT/LB 空闲回收，配置该谁兜底

【背景】

链路是「清算编排 → 账务落库」，使用 HikariCP 5.1，K8s 部署，4 副本，QPS 峰值约 1.2k。连接走公司 VPC，中间有一层 NAT 网关（空闲连接默认回收，文档标称 60s 但没写死）+ RDS 侧 wait_timeout=28800（8h）。

【现象】

线上偶发（约每天 2~5 次、多在业务低峰时段）出现 Connection reset by peer，导致业务请求失败。当前配置 maxLifetime=1800s（30min），但问题依旧。

【已尝试的排查】

• 确认 DB 侧 wait_timeout=28800s，未发现相关日志；
• 检查 NAT 网关配置，发现其空闲回收默认为 60s，但未明确写死，可能存在动态调整；
• 确认连接池配置中 idleTimeout=300s，maxLifetime=1800s；
• 尝试增大 maxLifetime 到 1800s 以上，但问题未解决。

【期望得到的答案】

1. 如何区分是 NAT/LB 的空闲回收导致的连接关闭，还是数据库 wait_timeout 触发；
2. 配置应如何兜底（谁来负责？是 NAT/LB、数据库还是连接池）；
3. 是否需要调整 maxLifetime 的值，如何合理设置；
4. 是否有其他排查手段或监控指标，能更精准定位问题根源。

【引用】

• 《HikariCP 连接生命周期：idleTimeout 与 maxLifetime 两条生命线的机制差异，和『悄悄退役』的连接》（id=2097）
• 《HikariCP maxLifetime 比 LB 空闲超时还长：首请求失败尖峰怎么压到 P99 之外？keepaliveTime 到底敢不敢开、开多大？》（id=1619）