核心是解决nat网关与数据库连接池的“时间错配”：需将连接池max-lifetime设为≤180秒、启用借出前或空闲时连接验证、调高nat超时或增加公网ip、并同步降低mysql wait_timeout至300–600秒。
核心是解决 NAT 网关与数据库连接池之间的“时间错配”：NAT 会维持连接状态（默认 TCP 空闲超时 4 分钟），MySQL 服务端默认 8 小时断连，而连接池若不主动探测，就会把已被 NAT 或 MySQL 单方面关闭的连接当成“可用”，取出来就报 Communications link failure。
匹配 NAT 的空闲超时，缩短连接池生命周期
NAT 网关的 TCP 空闲超时（默认 240 秒）通常比 MySQL 的 wait_timeout（28800 秒）短得多，是实际最先“断链”的一环。连接池必须在 NAT 断开前主动清理或验证连接。
- 设置连接池的
max-lifetime≤ 180 秒（建议比 NAT 超时少 30–60 秒），确保连接在被 NAT 清除前主动退役 - HikariCP 示例：
max-lifetime=180000，同时禁用max-lifetime=0（即永不过期） - 避免仅依赖
keepalive-time：它只对活跃连接发心跳，对空闲连接无效
启用连接有效性验证（探活）
让连接池在借出连接前做一次轻量检测，过滤掉已被 NAT 或 MySQL 关闭的“僵尸连接”。
- HikariCP 配置：
connection-test-query=SELECT 1（MySQL 8.0+ 推荐用isValid()，设connection-test-query=空值 +validation-timeout=3） - 开启
test-on-borrow=true（借出前检测）或更轻量的test-while-idle=true（空闲时检测） - 注意：
time-between-eviction-runs-millis必须小于 NAT 超时（如设为 120000），否则空闲连接可能在两次检测之间被 NAT 清除
调整 NAT 网关自身参数（Azure / AWS 等云平台）
如果业务允许且可控，可微调 NAT 行为，缓解连接中断频率。
- Azure NAT Gateway：TCP 空闲超时支持 4–120 分钟，可适当调高（如设为 300 秒），但需权衡 SNAT 端口压力——超时越长，端口占用越久，越容易触发 SNAT 耗尽
- 更推荐做法：增加公网 IP 数量（每个 IP 提供约 64K SNAT 端口），分散连接压力；避免单 IP 承载全部出站流量
- 监控关键指标：SNAT 连接总数、失败连接数、丢包率；一旦失败连接 > 0，基本可判定是 SNAT 端口耗尽或超时冲突
配合数据库端协同优化
单靠客户端或网络层调整不够，MySQL 侧也要减少“静默断连”带来的不确定性。
- 将 MySQL 的
wait_timeout从默认 28800 降低至 300–600 秒（5–10 分钟），使其接近或略长于 NAT 超时，缩小时间差 - 执行：
SET GLOBAL wait_timeout = 300;（需 SUPER 权限，重启后失效；生产环境建议写入配置文件my.cnf） - 确认应用连接串中未设置
autoReconnect=true（MySQL Connector/J 已弃用，不可靠，且掩盖真实问题）
