白天一切正常,可到了凌晨两三点,挂着代理跑的长连接就会无声无息地断开,重新连上又一切如常。排查日志没有报错,换出口也照断不误。问题出在哪里?很多时候,是 TCP Keepalive 和代理侧的空闲超时在暗中较劲——两套机制都在管理”连接活不活”,规则却互相冲突。
TCP Keepalive 是系统自带的”查岗”机制
操作系统内核里内置了一个探测机制:当一条 TCP 连接空闲一段时间后,内核会主动发出探测报文,确认对端还活着。这个机制叫 TCP Keepalive,目的是把”对端已经消失但本地还在傻等”的死连接识别出来,及时释放资源。
它的默认参数相当保守:连接空闲满 2 小时才开始第一次探测,之后每隔 75 秒发一次,连续 9 次都没有回应,才判定连接死亡并断开。换句话说,在默认配置下,一条连接至少得空转两个多小时,系统才会动手”查岗”。
这套机制设计得很稳,但它只对”对端真的挂了”的场景有意义。如果连接两边都活着,只是长时间没有数据往来,探测报文往往还没来得及发出,另一套规则就已经先动手了——那就是代理侧的空闲超时。
代理为了控制资源占用,几乎都会给空闲连接设一个回收时限,常见的设置在几分钟到半小时之间。空闲超过时限,代理就主动断开连接,好把名额让给其他业务。于是问题就来了:客户端的内核还在按 2 小时的节奏等待,代理却已经提前把连接回收了。
| 机制 | 由谁发起 | 默认节奏 | 断了会怎样 |
|---|---|---|---|
| TCP Keepalive | 操作系统内核 | 空闲 2 小时起步 | 对端无响应才断开 |
| 应用层心跳 | 应用自己 | 秒级到分钟级 | 由应用决定重连策略 |
| 代理空闲超时 | 代理服务端 | 几分钟到半小时 | 直接回收连接 |
为什么代理链路上这个问题更常见
走代理之后,一条业务连接被拆成了两段:客户端到代理一段,代理到目标站一段。两段各自维护自己的空闲计时,任何一段超时,整条业务连接都会断。代理侧的超时通常远短于客户端的探测节奏,所以大部分”半夜断连”都是代理先动手的。
如果用的是轮换型出口,情况会更明显:地址轮换本身就会重建连接,再叠加两段空闲计时,断连的随机性进一步放大。长期挂机的业务,比如定时同步、监控脚本、消息推送,最容易踩中这个坑。
怎么判断是它在作怪
断连时间有规律可循:总是发生在”空闲一段时间之后”,而不是访问正忙的时候;断开后立即重连通常一次成功;日志里看不到报错或认证失败。这三条同时满足,基本可以锁定是空闲超时和探活节奏错位导致的。
验证方法也很直接:把业务改成持续有小流量(比如应用层心跳或定时保活请求),如果断连消失,就坐实了猜测;再把代理侧的空闲阈值调高或换用支持长连接的出口,问题也能缓解。
长连接业务:优先给应用配心跳或保活请求,让连接保持”活跃”状态,别让两端的空闲计时器启动
参数调整:应用层无法改心跳时,再考虑调整系统探活参数,但默认值别乱动,先确认业务确实需要长连接
出口选择:轮换型出口天然不适合长连接,长期挂机业务应优先考虑稳定型出口,把空闲超时策略问清楚
把 TCP Keepalive 和代理超时这层关系理清楚,”半夜断连”就不再是玄学:它不是代理质量差,而是两套空闲管理机制没对齐。选代理IP时,除了看速度、看可用率,把连接空闲策略也纳入评估,长连接业务才能睡得安稳。
TCP Keepalive 是系统给连接上的保险,代理空闲超时是资源管理的手刹,两者节奏不对齐,长连接就会在深夜悄悄断掉。给应用配上心跳、选对出口类型,才是挂机业务和代理IP相处的正确姿势。