JDBC连接在防火墙后断开是因为防火墙空闲超时（300–1800秒）而JDBC不发心跳，需靠连接池配置keepalive-time与validation-query协同保活，如HikariCP设keepalive-time≤防火墙超时一半并配SELECT 1类验证查询。
为什么JDBC连接会莫名其妙断在防火墙后面
因为多数企业级防火墙（比如 aws security group、阿里云安全组、硬件 f5）默认开启 tcp 连接空闲超时，通常 300–1800 秒不发包就直接 kill 连接。而 jdbc connection 对象本身不会主动发心跳，应用层没感知，等到下次 executequery() 才抛 communications link failure 或 connection reset —— 此时已晚。
jdbcUrl 加 tcpKeepAlive 参数根本没用
MySQL Connector/J 8.0+ 确实支持 tcpKeepAlive=true，但注意：它只影响底层 Socket 的 SO_KEEPALIVE 标志位，而操作系统默认的 keepalive 探测间隔（Linux 通常是 2 小时）远超防火墙超时阈值，所以实际起不到作用。除非你同时调大内核参数（/proc/sys/net/ipv4/tcp_keepalive_time），但这需要运维权限，且影响全局，生产环境基本不可行。
更现实的做法是交给连接池来管：
-
HikariCP推荐用connection-test-query=SELECT 1+validation-timeout=3000+keepalive-time=30（单位秒，必须 ≤ 防火墙超时时间的一半） -
Druid对应配置是validationQuery=SELECT 1+testWhileIdle=true+timeBetweenEvictionRunsMillis=30000 - 别设
testOnBorrow=true：每次取连接都查一次SELECT 1，高并发下反而成瓶颈
SELECT 1 不是万能的，得看数据库类型
不同数据库验证查询写法不同，错一个就导致连接池误判为失效：
- MySQL / PostgreSQL / SQL Server：用
SELECT 1没问题 - Oracle：必须写
SELECT 1 FROM DUAL，否则报ORA-00942 - SQL Server：如果启用了
SET NOCOUNT ON全局设置，SELECT 1可能返回空结果集，建议改用SELECT COUNT(*) FROM sysobjects或启用isWrapperFor检测 - H2 / HSQLDB：部分嵌入式模式不支持无表 SELECT，得配
SELECT CURRENT_TIMESTAMP
连接池 keepalive 和 validation 的组合逻辑容易搞混
以 HikariCP 为例：keepalive-time 是“空闲连接多久发一次心跳”，validation-timeout 是“验证查询最多等多久”，二者必须配合防火墙策略：
- 假设防火墙超时是 5 分钟（300 秒），那么
keepalive-time建议设为120（2 分钟），确保每 2 分钟至少有一个包发出 -
validation-timeout要小于网络 RTT 的 3 倍，一般设3000（3 秒）足够，设太大可能卡住线程 - 别把
max-lifetime设得太长（比如 30 分钟），否则即使 keepalive 活着，连接也可能被数据库服务端主动回收（如 MySQLwait_timeout默认 8 小时，但有些 RDS 会缩到 30 分钟）
真正关键的是：keepalive 发包 ≠ 数据库连接有效。它只能保 TCP 层不断，不能替代定期验证。所以 keepalive-time 和 validation-query 得共存，不能只选一个。
