为何WebSocket连接空闲6-8分钟后会自动断开

核心差异定位 #

两类访问场景的链路完全不同，这是公网访问出问题、私网访问正常的根本原因：

• 私网IP访问链路：浏览器直接和内网应用服务建立连接，中间无额外转发节点，长连接超时规则完全由应用服务本身控制
• 公网域名访问链路：浏览器流量会经过公网DNS、CDN/反向代理/云负载均衡/WAF/运营商公网NAT等多层节点，每一层都有独立的空闲连接回收规则，任何一层的阈值低于应用服务的配置，都会提前掐断长连接

这类场景下观测到的6-8分钟无活动断开的现象，和绝大多数网络中间件、NAT设备的默认空闲超时阈值高度匹配，属于非常典型的链路层超时问题。

逐类可落地排查方向 #

• 定位断开连接的发起节点
  在公网域名访问的场景下，连接建立后持续抓包观察，当触发连接onclose事件时，主动发送TCP FIN/RST包的源IP就是掐断连接的节点。常见的异常节点包括：Nginx反向代理、云厂商负载均衡、WAF防护节点、运营商公网出口网关。
• 检查各中间层的空闲超时配置
  绝大多数这类网络节点的默认WebSocket空闲超时配置为300秒（5分钟），叠加网络传输延迟后，实际断开时间就会落在6-8分钟区间。排查时需要把各节点的WebSocket空闲超时阈值调整到大于600秒，避免提前回收连接。

  注意：不要依赖TCP层的keepalive机制维持连接，多数中间转发节点不会把TCP层的保活报文判定为WebSocket会话活跃，容易出现TCP层保活正常但WebSocket连接依然被掐断的情况。

• 补充应用层的WebSocket心跳保活逻辑
  现有代码仅实现了基础的连接创建和事件绑定，没有内置心跳机制，同时存在一处逻辑错误：连接成功的日志被写在了onmessage（收消息）回调里，实际连接建立成功的事件是onopen，容易导致排查时日志状态对不上。可参考下方代码补充修正：

  let pingTimer = null;
  function socketConnect(){
      var socketUrl = 'wss://'+location.hostname+'/web-socket';
      socket = new WebSocket(socketUrl);
      // 修正原有逻辑：连接成功的日志绑定在onopen事件上
      socket.onopen = function(){
          console.log("Socket connected");
          // 连接建立后启动30秒间隔的轻量心跳
          pingTimer = setInterval(() => {
              if(socket.readyState === WebSocket.OPEN){
                  socket.send(JSON.stringify({type: "ping"}));
              }
          }, 30000);
      }
      socket.onmessage = function(e){
          // 修正原有onmessage的日志逻辑
          console.log("Received message: ", e.data);
      }
      socket.onclose = function(e){
          console.log("Web-Socket Connection closed.");
          // 连接断开时清除定时器，避免内存泄漏
          clearInterval(pingTimer);
      }
  }
  

  心跳间隔设置为30-45秒即可，远低于所有中间层的默认超时阈值，能从根本上避免连接被判定为空闲回收。
• 排查公网NAT会话超时配置
  运营商公网出口网关的NAT会话映射有固定的空闲回收时间，无应用层报文交互的TCP连接会被提前回收映射关系，导致连接失效。私网访问因为不经过公网NAT层，所以不会触发这类超时。

快速验证方法 #

临时在现有WebSocket逻辑里加上30秒间隔的应用层ping心跳，观察是否还会出现6-8分钟自动断开的问题。如果加上心跳后连接稳定，就可以确认是链路中间层的空闲超时导致的问题，后续不需要修改应用服务本身的核心逻辑，只需要调整各中间转发节点的超时配置、配合心跳保活即可完全解决问题。

内容的提问来源于stack exchange，提问作者SrTan