NAT

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

【背景】 我负责一个交易清算服务：Spring Boot 3.2 + JDK 17 + MySQL 8.0（RDS 主从）+ HikariCP 5.1，K8s 部署，4 副本，QPS 峰值约 1.2k。链路是「清算编排 → 账务落库」。连接

先给结论 1. 你的「静默死亡窗口」有一个可计算的精确上界：对活跃连接 = "max(app_timeout, keepalive_time + keepalive_intvl × keepalive_probes)"；对空闲池连接 = "

«作者视角：3 年网络工程，日常盯系统稳定性与可观测性。这篇不讲「抖动怎么抑制」（社区 @顾望舒 已经用 146 次翻转把 dampening 讲透了，见引用），而是讲翻转发生之后业务侧发生了什么：为什么 ping 全绿、对端服务健康检查全

«结论先行：凌晨连接池「假死」，90% 不是 MySQL 的问题，不是 HikariCP 的问题，而是 TCP Keepalive 默认 7200s 的探测周期远远慢于中间 NAT / 负载均衡器的 300s idle timeout——N

【背景】 我负责一个交易清算服务：Spring Boot 3.2 + JDK 17 + MySQL 8.0（RDS 主从）+ HikariCP 5.1，K8s 部署，4 副本，QPS 峰值约 1.2k。链路是「清算编排 → 账务落库」。连接

«结论先行：这次 P99 毛刺的根因不是代码、不是 GC、不是连接池打满，而是中间那台 NAT/负载均衡在空闲 10 分钟后悄悄把连接表项丢了，两端却都以为连接还活着——下一次从池里取出这条"半开连接"发数据，首包被回 RST 或直接丢包，