WebSocket浏览器端无法设置任意Header，仅能通过Sec-WebSocket-Protocol传Token或URL参数传递；前者需服务端回传校验，后者需编码且存在日志泄露风险；Authorization头在浏览器原生API中不可用。
WebSocket无法直接设置任意Header，这是协议限制
浏览器原生 WebSocket 构造函数不支持传入自定义 HTTP 头（如 Authorization、X-Auth-Token），这是 WebSocket 协议在浏览器环境的硬性约束。你看到的“加 Header”操作，本质都是在利用协议握手阶段允许携带的**有限字段**做变通，不是真正意义上的任意头注入。
用 Sec-WebSocket-Protocol 传 Token 最常用也最可靠
这个字段本意是协商子协议（如 chat-v1、json），但被广泛复用为轻量级认证载体。服务端只需读取 req.headers['sec-websocket-protocol'] 并校验，前端写法极简：
const token = localStorage.getItem('token');
const ws = new WebSocket('wss://api.example.com/ws', [token]);
- 后端必须原样回传该值到
Sec-WebSocket-Protocol响应头，否则浏览器会关闭连接 - Token 长度受限（HTTP 头总长通常不超过 8KB，实际建议 ≤4KB）
- Spring Boot 中需用
HandshakeInterceptor提前拦截并校验，不能等到@OnOpen再处理
URL 参数传 Token 是最兼容的 fallback 方案
当 Token 较短（如 JWT）且服务端已支持从查询参数解析时，wss://host/ws?token=xxx 是最无脑、最易调试的方式：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 所有浏览器、Hoppscotch、curl-ws 工具都天然支持，无需额外配置
- 注意必须
encodeURIComponent(token)，否则含.或+的 JWT 会解析失败 - Token 会暴露在浏览器地址栏、服务端 access log、代理日志中，不适合高敏感场景
- Nginx 反向代理时，需确认
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade已启用
想用 Authorization 头？只能绕过浏览器直连或换库
浏览器里原生 WebSocket 真做不到。可行路径只有两条：
- 用
ReconnectingWebSocket+ 自定义 transport（仅 Node.js 环境可用），或改用ws库在服务端发起连接 - 前端走本地代理（如
http-proxy-middleware），把/ws-proxy请求转发到真实 WSS 地址，并在代理层注入Authorization头 - 某些企业内网环境可部署 WebSocket 客户端 SDK（非浏览器 JS），它能完全控制握手请求
别在浏览器里折腾 fetch + upgrade 模拟握手——既不符合规范，又容易被中间设备拦截或重置。
