生产环境中，WebSocket连接常常能完成建立，却在大约30秒、60秒或固定时长后无预警断开。客户端看到的是网络异常，服务端可能只留下上游关闭记录，代理和负载均衡日志又分散在不同机器上。若直接归因于“服务器不稳定”，不仅无法修复，还可能因集中重连进一步压垮源站。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：bqyun（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先确认连接究竟断在哪一层
连接升级握手发生在HTTP阶段：TCP连通后，客户端仍需通过代理或负载均衡转发Upgrade请求，并收到101响应。状态码不是101、超时或响应头缺失，通常不是空闲超时问题，而要检查转发规则、鉴权、路径改写以及后端是否真正支持WebSocket。
握手成功只说明长连接已经建立。若连接在业务流量持续时仍然稳定，沉默一段时间才断开，则应重点怀疑代理空闲超时。代理常按“连续未收到有效流量”计时，心跳包能否重置计时器，还取决于代理是否识别该协议与应用数据。
另一种情况是源站主动断连：代理侧可能记录上游EOF、后端连接重置或异常关闭，而客户端只能收到1006一类错误。长连接负载均衡还可能受最大连接时长、空闲阈值、单节点连接数或后端健康检查影响；滚动发布、摘流和会话迁移，也会在看似随机的时刻切断连接。
用时间线和配置验证锁定根因
排障时不要只看客户端报错。应为同一连接建立关联标识，采集客户端、Nginx或网关、负载均衡、源站四层日志，并统一时区和时间精度。重点对照三个时间点：升级请求到达时间、101响应时间、连接关闭时间，再判断关闭发生在哪一跳，以及关闭前是否存在持续数据流。
配置验证必须确认“实际生效值”，不能只查看配置文件。同一代理集群、Ingress规则、云负载均衡和后端服务可能拥有不同超时；容器配置也可能被注解、环境变量或管理平台覆盖。可用无业务数据的周期性消息测试空闲阈值，逐步拉长发送间隔，同时观察代理日志中的计时行为。
常见误区是只增加应用层ping，却忽略代理只统计业务载荷，或心跳间隔已经接近空闲超时；频繁重连也会形成重连风暴。稳妥做法是让心跳保活机制间隔小于最短空闲阈值，结合优雅重连策略加入随机退避与连接恢复检查。若需复核握手和转发过程，可使用ServLlama辅助观察请求链路，但仍应以各层原始日志和实际配置为准。
代理空闲超时与心跳保活：连接未断，业务却已停
WebSocket 完成 连接升级握手 后，TCP 长时间没有业务数据时，客户端、网关、Nginx 或云负载均衡可能按空闲时长回收连接。此时浏览器仍显示 OPEN，写入却被静默丢弃，表现为偶发超时而非立即断开。关键是让 心跳保活机制 穿透整条链路：客户端或服务端周期性发送 WebSocket Ping，由协议栈回应 Pong；应用层心跳用于判断业务是否健康，两者不能互相替代。周期应小于链路中最短的 代理空闲超时，并预留网络抖动和任务阻塞时间，可先取其一半再压测校准。只开 TCP keepalive 并不能保证代理层不休眠；多层代理的读写超时也必须逐一对齐。间隔过小会增加流量与锁竞争，过大则可能跨过回收阈值，因此要同时观察心跳成功率、延迟和断连时间。
长连接负载均衡与优雅重连：恢复顺序决定稳定性
在 长连接负载均衡 场景中，连接通常固定在一个后端实例，发布时若直接杀进程，客户端只能在数秒后才发现死亡。优雅重连策略 应按“摘流通知等待回收”执行：实例先停止接收新连接，主动关闭或通知客户端重连，给存量连接留出宽限期，再退出服务。客户端对网络错误采用带随机抖动的指数退避，如 1、2、4、8 秒并设置上限；恢复后先重新鉴权、恢复订阅，再发送业务消息。对鉴权失败等确定性错误不要无限重试，否则重连风暴会压垮新实例。
常见误区是只看应用日志、不看代理日志，或把“能建立连接”当成“连接永远可靠”。排障时应确认超时由哪一层触发、旧连接落在哪个实例、关闭码是否正常，并模拟负载均衡器重启、节点摘除和网络闪断；抓包与服务端日志需要互证。
可执行检查清单：①核对升级请求是否返回 101，并检查 Upgrade、Connection、Sec-WebSocket-* 等握手头；②列出客户端、负载均衡器、Ingress/Nginx、网关的读写和空闲超时，以最小值为基线；③开启 Ping/Pong 与应用心跳日志，观察连续 10～30 分钟无业务流量时连接是否存活；④演练代理重启、实例下线，确认关闭码、指数退避、重新鉴权和消息补发顺序正确；⑤压测集中重连，检查连接恢复速率。任何一层无法解释断连原因，都应先补齐指标和日志，再调整参数。
喜欢 
顶
难过
囧
围观
无聊
