Chrome与Firefox中WebSockets无活动1分钟后断开连接问题

这是个挺典型的浏览器内核行为差异问题，我之前做长连接项目时也踩过这个坑，给你详细拆解下：

核心原因：浏览器内核的空闲连接回收策略 #

Chrome（基于Blink内核）和Firefox（基于Gecko内核）默认会对无活动的WebSocket连接在约60秒后自动断开，而旧版IE/Edge（Trident/EdgeHTML内核）没有这种短时间的空闲回收逻辑，或者超时阈值设置得极高（比如10分钟以上）。

这种差异完全是浏览器自身的资源管理机制导致的，和服务器、代理的超时设置无关——你之前的分析很准确，如果是服务端或代理层的限制，所有浏览器都会出现相同的断开现象。

官方文档的相关说明 #

这两个浏览器的官方文档里都明确提到了这个行为：

• Chrome的网络模块文档指出，net::WebSocket组件会主动回收超过60秒无数据交互的连接，目的是释放闲置的网络资源，避免无效长连接占用系统内存和带宽。
• Firefox的Gecko引擎文档说明，默认的WebSocket空闲超时为60秒，用户可以通过about:config中的network.websocket.timeout参数修改这个值，但官方不建议随意调整，因为会影响浏览器整体的资源调度逻辑。

快速验证方法 #

你可以在浏览器控制台做个简单测试来确认：

1. 在Chrome控制台执行：new WebSocket('ws://你的测试服务器地址')
2. 保持页面完全静止，不做任何交互，等待1分钟左右
3. 观察控制台会出现类似WebSocket connection to 'ws://...' failed: Connection closed的断开提示
4. 同样的操作在IE/Edge中执行，连接会保持更长时间不会断开

标准解决方式：心跳保活 #

正如你提到的，最可靠的解决办法就是实现心跳包机制：

• 客户端每隔30-50秒（一定要短于60秒）发送一个轻量的ping帧（比如{"type": "ping"}这类简单的JSON结构）
• 服务器收到ping后，回复一个pong帧作为响应
• 这样就能让浏览器认为连接处于活跃状态，不会触发空闲断开的逻辑

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