必须显式设为false：vue cli默认启用内置websocket服务用于热更新，其心跳帧格式与业务帧冲突，导致服务端报invalid frame header；需在proxy规则中设ws: false，并全局配置websocketserver: false。
devServer.proxy 的 ws 配置必须显式设为 false
Vue CLI（尤其是 4.x/5.x）在开发环境下默认启用内部 WebSocket 服务用于热更新，它会监听 ws://localhost:端口/ws 并主动发心跳帧。这些帧不是标准业务协议帧——首字节常为 0x80，payload 含非 ASCII 二进制数据，长度可能 ≥126 字节。当你的前端又通过 proxy 配置了 WebSocket 代理（比如 target: 'ws://127.0.0.1:8081'），且 ws: true 时，两个 WebSocket 流会混在一起：浏览器发的业务帧和 devServer 自己的心跳帧都经过同一连接通道，服务端只认你定义的协议格式，自然报 Invalid frame header。
解决方式就是关掉这个干扰源：
-
vue.config.js中的devServer.proxy配置里，所有带target指向ws://或wss://的规则，ws字段必须设为false - 同时，在顶层
devServer加上webSocketServer: false，彻底禁用内置 WS 服务 - 不要依赖
logLevel: 'debug'查日志——它不打印帧内容，只会让你误以为代理“看起来正常”
后端没正确处理 HTTP 升级请求也会触发该错误
WebSocket 连接本质是 HTTP 协议升级：GET /path HTTP/1.1 + 特定 header（Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key 等）。如果代理层（Nginx / http-proxy-middleware）没透传这些 header，或没返回 HTTP 101 Switching Protocols，客户端会降级走普通 HTTP 长轮询，后续发的二进制帧就会被当成非法数据解析。
检查点：
- Nginx 配置中是否漏了
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade"; - 若用
http-proxy-middleware（如 Vue CLI 内置），确认changeOrigin: true已开启，否则 Origin 头被过滤会导致服务端拒绝升级 - 抓包看 TCP 流：如果三次握手后立刻收到
HTTP/1.1 200 OK而非101，说明升级失败，此时即使readyState === 1，后续 send() 也必报Invalid frame header
socket.io 客户端版本低于 4.7.4 有已知帧解析缺陷
socket.io 4.2.0–4.6.2 在某些网络条件下（如中间设备做 TCP 分片、服务端启用了 permessage-deflate 压缩）会生成不符合 RFC 6455 的帧头：比如 mask bit 错位、payload length 编码越界。浏览器底层 WebSocket 实现（Chrome/Firefox）严格校验，直接拒收并抛 Invalid frame header，但不会给出具体哪一字节错。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
这不是你代码写错了，是库本身的 bug：
- 升级
socket.io-client到^4.7.4或更高（4.7.5已验证稳定） - 不要只改前端：确保服务端
socket.io版本也 ≥4.7.4，否则跨版本协商仍可能出帧异常 - 避免临时降级到 3.x——v3 使用不同握手机制，与现代代理兼容性更差
EasyPlayer/flv.js 类播放器报错时，先确认是不是帧错误的“连带伤害”
像 EasyPlayer-lib.min.js 报 Cannot read properties of null (reading 'flushStashedSamples')，表面是 JS 执行错误，根源往往是前面的 Invalid frame header 导致 WebSocket 连接静默断开，remuxer 没收到完整 FLV tag 就被销毁。此时再调 flushStashedSamples 必然报空引用。
别急着 patch JS：
- 先用浏览器开发者工具的 Network → WS 标签，看连接是否在 10s 内就显示
Closed，且没有onmessage收到任何数据 - 用
wscat -c ws://your-url直连后端，绕过所有前端框架和代理，确认服务端本身能稳定收发帧 - 只有排除了网络/代理/服务端问题后，才考虑在播放器初始化后手动补
player._remuxer = { flushStashedSamples() {} }这类 hack
真正难定位的是帧错误发生在代理链路中间——它不报错，只悄悄丢弃或篡改帧头。这时候必须用 wireshark 抓包比对 client 发出的帧头和 server 实际收到的帧头，一字节都不能差。
