proxy_read_timeout仅控制nginx从后端读数据的空闲上限，非连接总时长；须设为业务心跳间隔2–3倍（如90–120s），并同步配置proxy_send_timeout、upstream keepalive及系统tcp参数。
WebSocket连接掉线不是代码写错了，而是网络中间设备在“帮你清理闲置连接”——Nginx、运营商NAT、手机系统都在等你沉默满30–60秒后直接掐断。保活的关键不是“连得上”，是“一直动”。
为什么proxy_read_timeout设成86400也没用？
Nginx的proxy_read_timeout只管“从后端读数据”的等待时间，但如果你的服务端压根没发任何数据（比如用户只是挂着不说话），这个超时就完全不触发。更关键的是：它不阻止上游（如手机基站、企业防火墙）先动手。
- 运营商NAT空闲超时通常为30–120秒，且不可配置
- iOS Safari后台标签页会在10–20秒内冻结
setInterval，心跳定时器直接停摆 - Android Chrome虽稍好，但在低内存或省电模式下也会暂停WebSocket发送
-
tcp_keepalive_time内核参数默认7200秒，远慢于中间设备节奏，形同虚设
前端心跳必须绕过浏览器后台冻结
单纯用setInterval(() => ws.send("PING"), 25000)在手机上基本失效。真实可用的方案要叠加多层兜底：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 使用
PageVisibility API监听visibilitychange，前台时恢复心跳，后台时改用Notification API或Background Sync（需HTTPS+Service Worker）唤醒 - 心跳间隔必须小于最短中间设备超时（建议≤25秒），且不能固定——可随机±3秒防探测同步
- 避免只发
"PING"字符串，应统一用带type: "heartbeat"的JSON对象，和服务端协议对齐 - 收到
"PONG"后必须调用clearTimeout重置本地超时计时器，否则一次丢包就会误判断线
服务端别依赖ping/pong帧，自己解析消息
浏览器WebSocket API不暴露sendPing方法，所以别指望原生Ping帧能穿透所有代理。所有心跳必须走普通message事件通道：
- Spring Boot中，用
@MessageMapping("/ws/heartbeat")接收并立即simpMessagingTemplate.convertAndSend回"PONG" - FastAPI中，在
websocket.receive_json()里判断data.get("type") == "heartbeat"，立刻websocket.send_json({"type": "pong"}) - Node.js的
ws库需禁用noServer: true和clientTracking: false，否则无法准确识别连接状态 - 务必在服务端记录每个连接的最后心跳时间戳，配合
setTimeout主动close()僵死连接，避免堆积
重连逻辑比心跳更容易出错
很多项目把重连写成“断了就立刻重试”，结果在弱网下触发雪崩式请求，压垮网关。真正健壮的重连必须满足：
- 区分关闭原因：
event.code === 1001（应用级关闭）不重连，1006（异常关闭）才启动重连 - 首次重连延迟≥1秒，后续按指数退避：1s → 2s → 4s → 8s，最大不超过30秒
- 限制总重试次数（建议≤5次），超限后降级为HTTP长轮询或提示用户手动刷新
- 重连前清空旧定时器，避免多个
setInterval并发运行导致内存泄漏
最常被忽略的一点：心跳包本身不能携带业务数据。一旦把用户消息和心跳混在一个字段里，服务端解析失败就会误判为心跳超时，引发无意义重连。保活机制必须是干净、隔离、可验证的独立通道。
