websocket连接open但onmessage不触发，主因是消息类型不匹配、php未解帧、心跳与业务混判、nginx未透传upgrade头。需检查收发类型一致性、用成熟库解析帧、维护lastmessageat判断真实连通性。
websocket连接显示 open，但 onmessage 完全不触发——这不是网络问题，大概率是协议层或框架层的逻辑错配。真正卡住你的，往往不是“连不上”，而是“连上了却收不到”。
WebSocket消息类型不匹配导致onMessage静默失效
Java（如Tomcat WebSocket实现）或部分Go/Python服务端默认只注册了 @OnMessage 处理 TextMessage，而前端调用 socket.send(new ArrayBuffer(...)) 发送的是二进制帧，服务端根本不会分发到该方法。
- 检查前端发送逻辑：
socket.send()传入的是字符串、ArrayBuffer还是Blob - 服务端必须显式声明对应类型的处理方法：Java中需同时写
@OnMessage接收String和byte[]；Go的gorilla/websocket需用conn.ReadMessage()或conn.ReadJSON()区分 - 浏览器开发者工具的
Frames标签页里，看每条帧的Type列：是text还是binary
PHP原生socket未解帧，socket_read() 拿不到明文
PHP用原生 socket_* 函数手写WebSocket服务时，握手成功后直接 socket_read()，得到的永远是带掩码、含帧头的原始字节流，不是你想要的JSON字符串。
- WebSocket协议强制要求客户端帧必须
masked，服务端必须解包才能读取有效载荷 - 不能跳过帧解析直接当HTTP body处理；必须按 RFC6455 解析
FIN、opcode、masking-key、payload length等字段 - 建议改用成熟库如
ratchet/pawl或workerman，避免手动实现帧解析——99%的PHP WebSocket通信故障源于此
心跳保活与业务数据混为一谈，误判连接健康
很多系统用 ping/pong 帧判断连接存活，但交易所、IoT平台等场景下，服务端根本不响应客户端 ping；或者 pong 虽然收到，但业务消息早已停止推送。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
readyState === 'open'和socket.ping()成功，都不等于业务数据在流动 - 必须单独维护一个
lastMessageAt时间戳，在每次收到业务帧（非ping/pong）时更新 - 启动一个定时器，比如每30秒检查一次：
if (Date.now() - lastMessageAt > 60_000) { reconnect(); } - Nginx 默认 60 秒关闭空闲连接，若业务消息间隔 >60s，又没发
ping，连接会被中间件静默断开
反向代理未透传Upgrade头，连接假成功
客户端发起 ws:// 请求，Nginx 返回 101，浏览器显示已连接，但后续所有 message 都无法到达后端——因为 Nginx 把 WebSocket 升级请求当普通 HTTP 转发了，没透传关键头部。
- 确认 Nginx 配置中包含：
proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade"; - 缺任意一项，握手响应虽能返回，但后续帧会被当成普通 HTTP 请求丢弃或 400
- 用
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" http://your-domain/ws手动模拟握手，观察响应头是否含Sec-WebSocket-Accept
最危险的坑，是你以为连接“活着”，其实数据流早就断了。TCP 层的 ESTABLISHED 和应用层的“消息持续抵达”，完全是两件事。盯住 lastMessageAt，比盯 readyState 可靠十倍。
