空闲连接超时没有通用值，必须结合业务特征来定。设短了，低峰期连接反复重建，数据库和网关压力反而更大；设长了，空闲连接堆积，最终触发连接数上限，判断标准只有一条：连接超过多久不用，就基本不可能再被复用,那这个时间就是你的超时阈值。
拿到一个业务，从三个维度判断连接该怎么断
空闲连接超时的本质，是判断“这条连接还有没有保留价值”，不同业务里，连接的价值完全不同,判断从三个维度入手。
应用层连接还是传输层连接
应用层连接指HTTP Keep-Alive、数据库连接池里的连接、Redis连接这类有明确业务语义的连接，它们断掉后重连生态成本高,超时时间允许较长。
传输层连接指TCP层本身的连接（通过tcp_keepalive控制），它只关心网络通不通，不关心业务上下文的存活，传输层超时往往由网络环境决定，比如NAT设备会回收空闲映射,传输层需要在NAT超时前发探测包。
请求-响应模式还是长连接推送模式
- 请求-响应模式（典型的HTTP调用、数据库查询）：连接用完了就空闲，下次请求会复用，业务特征是密集调用+有空闲窗口,超时设太短会导致高峰期不断重连。
- 长连接推送模式（消息推送、IM、股票行情、WebSocket）：连接平时没数据但必须保持在线，业务特征是连接存活本身就有价值，超时不能按业务交互间隙来设,要按客户端或NAT的容忍上限来设。
网络路径是否稳定和可控
- 内网连接：网络稳定，路由可控,连接可以放得更久。
- 跨运营商公网：中间节点不可控，NAT映射、运营商空闲回收都会主动断连接,公网的超时设置必须比内网短。
- 移动网络：4G/5G环境下，无线侧的空闲资源回收更激进，连接稳定性最差,超时与心跳策略要单独设计。
数据库连接池的空闲连接超时怎么配置
数据库连接池是空闲连接超时最容易踩坑的地方，业内专家指出，相当一部分线上故障并非连接数不够,而是空闲连接没及时回收导致连接池被占满。
MySQL连接池的空闲超时策略
MySQL服务端默认的wait_timeout通常是8小时，但你的连接池客户端超时一定要比它短，这是第一原则，比如服务端8小时回收，连接池里那条连接如果干等4小时，服务端可能早就把它断了，连接池不知道，拿给业务用就报“Connection closed”。
具体配置建议：
- 核心交易链路：池内空闲超时设30到60秒，交易类业务的连接复用率高，但空闲窗口很短,超时太短反而在秒杀或脉冲流量下疯狂建连。
- 报表分析类业务：设5分钟，这类任务批量跑SQL，中间有空档，连接空闲5分钟后大概率不再复用,可以回收。
- 连接池的min-idle参数调成和高峰期并发相当，空闲超时只对超出min-idle的连接生效,避免频繁销毁重建。
很多人问数据库连接池空闲超时和MySQL服务端wait_timeout谁优先，答案是：取两者较小值，连接池把空闲连接养到接近wait_timeout，等于把炸弹埋在池子里,任何一次网络抖动都会引爆。
缓存型存储的空闲超时
Redis这类缓存的连接超时逻辑相反，Redis单机连接成本极低，但空连接几乎不占资源，所以Redis连接池的空闲超时可以设得比MySQL大得多（比如10分钟到30分钟），因为Redis本身不主动断连接（除非配了timeout），旧连接复用的风险极小,省下重建连接的消耗更划算。
网关和四层代理的空闲连接超时设置
网关是连接汇聚点，一条上游连接对应多条下游连接，超时设置直接影响吞吐量，这一层最容易混淆两个概念：tcp keepalive和http keep-alive。
tcp keepalive和http keep-alive的区别
- TCP Keep-Alive是传输层机制，默认关闭或间隔极长（Linux默认7200秒），它只探测对端主机是否存活,不关心业务进程是否卡死。
- HTTP Keep-Alive是应用层行为，指一次TCP连接上可以连续发起多个HTTP请求，它决定的是“连接空闲多久后，不再接受新的HTTP请求”。
两者要配合使用，TCP Keep-Alive负责在防火墙或NAT清掉连接之前保持住映射，HTTP Keep-Alive负责在业务空闲窗口内保留连接避免重建，协调原则：
TCP Keep-Alive的探测间隔要小于NAT超时，HTTP Keep-Alive的idle timeout要大于TCP Keep-Alive的探测周期,否则HTTP连接会在TCP层被倒腾断。
LVS/Nginx/HAProxy的常见配置
- LVS的持久连接超时：内网服务设15到30分钟，公网服务设5到10分钟，配太短，用户短时间内的多个请求被负载到不同后端，会话失效；配太长,LVS的连接表会被半开连接占满。
- Nginx的keepalive_timeout：默认65秒已经覆盖绝大多数场景，如果你的业务是API网关，调到30-60秒足够；如果是静态资源或图片服务，调到120秒也没有问题,因为客户端下次刷新基本还要拉资源。
- HAProxy的timeout client/server：HTTP服务建议1到5分钟，WebSocket或消息类长连接要单独开通道，不设超时或设到数小时,不能直接套用普通HTTP超时。
判断网关该用哪个值，看两条链路：一条是用户到网关，一条是网关到后端，公网用户链路要短，因为NAT拦截概率高；内网到后端可以设长,因为网络可控。
移动端长连接的心跳包间隔设置
移动端长连接（IM、推送SDK、消息通知）的空闲连接超时，本质上由心跳包主导，行业共识认为，移动网络的NAT空闲回收时间集中在30秒到5分钟，跨度极大,因此心跳策略不能让连接真正空闲下来。
为什么心跳要比NAT超时短
运营商NAT对UDP映射的回收通常在30-60秒，TCP映射稍长但仍远短于有线网络，App的推送连接如果按有线网络习惯设置10分钟心跳，在移动网络下基本撑不过3分钟。心跳间隔取NAT回收时间的二分之一到三分之二,是最稳妥的经验值。
不同业务场景的心跳间隔参考
- IM消息类：优先保证消息实时性，心跳间隔30-90秒，这需要权衡电量消耗，多数情况下SDK会做智能心跳：Wi-Fi环境下拉长到3-5分钟,蜂窝网络下缩短到1分钟以内。
- 资讯类App推送：实时性要求低，可以接受1-5分钟延迟，心跳间隔放长到3-5分钟，离线推送兜底,不依赖长连接存活。
- 股票行情、IoT设备指令下发：要求秒级到达且不能断，心跳间隔15-30秒，同时服务端要能快速识别半开连接并踢掉,避免向死连接推数据。
移动端还有个容易被忽视的点：服务端主动断开空闲连接时，不要发FIN包，直接静默丢弃，让客户端在心跳超时后自己发现连接断开再重连，这能避免客户端反复触发断线重连风暴,也是各家长连接网关的通用做法。
常见问题与空闲连接超时排障
设置了很短的连接池空闲超时，为什么还是报连接数超限？
检查连接池之外的长连接占用，相当于一部分连接被定时任务、消息消费者、后台扫描线程占用，这些连接长期活跃不释放，占满连接池与超时设置无关，优先排查是否存在连接泄漏业务代码里获取了连接但没归还，空闲超时只能回收池内已归还的空闲连接,拦不住泄漏。
按照建议设置了超时，服务端仍然大量TIME_WAIT怎么办？
TIME_WAIT是主动关闭一方产生的，与空闲超时长短无关，调小超时只会让更多连接被主动关闭，反而增加TIME_WAIT，优化方向是减少新建连接次数，提高连接复用率，比如调大HTTP Keep-Alive的复用上限，或者让服务端不要主动断开连接,把断连接的主动权交给客户端。
心跳发送正常，连接还是会在高峰期断开，怎么回事？
高峰期网络设备压力和丢包率上升，心跳包可能因为拥塞被丢弃，服务端要配置连续多个心跳超时（通常3次）后再判定连接死亡，单个心跳丢失不应触发断开，同时客户端在检测到断线后要做指数退避重连，避免服务端刚恢复，所有客户端像约好了一样同时重连,形成连接雪崩。
空闲连接超时本质是资源与体验的权衡，内网组件之间短配置，公网入口按NAT特征配置，移动端靠心跳保活，把握住这三类场景的特征，一个连接该活多久,答案自然清晰。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635305.html
