sec-websocket-key必须是16字节随机二进制数据经base64编码所得的约24字符字符串，服务端须将其解码后与固定guid拼接再sha-1哈希并base64编码生成sec-websocket-accept，任一环节偏差均导致握手失败。
Sec-WebSocket-Key 不是随便生成的字符串，它必须是 16 字节随机数据经 Base64 编码后的结果；服务端若用错方式计算 Sec-WebSocket-Accept，握手必然失败。
Sec-WebSocket-Key 的生成要求
客户端必须生成真正随机的 16 字节（不是 16 个字符）二进制数据，再做 Base64 编码。常见错误包括：
- 用时间戳、递增序号或简单字符串（如
"abc123"）拼接后编码 —— 不满足随机性，易被代理缓存或重放 - 生成 16 个 ASCII 字符再 Base64 —— 实际字节数可能远小于 16，导致
Sec-WebSocket-Accept校验失败 - 重复使用同一个
Sec-WebSocket-Key—— 违反 RFC 6455，部分中间代理会拒绝或缓存响应
正确做法：调用语言原生安全随机 API，例如 Node.js 用 crypto.randomBytes(16)，Python 用 secrets.token_bytes(16)，Go 用 crypto/rand.Read()。
Sec-WebSocket-Accept 的计算公式与陷阱
服务端必须严格按 RFC 6455 计算：Sec-WebSocket-Accept = base64(sha1(<code>Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))。关键细节：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 拼接时是原始字节拼接，不是字符串拼接 ——
Sec-WebSocket-Key是 Base64 编码后的字符串，需先base64.decode成字节，再与魔数字符串的 UTF-8 字节拼接 - SHA1 输入必须是字节流，不是 hex 字符串；输出是 20 字节摘要，直接传给 Base64 编码，不能转成 hex 再编码
- 魔数
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"区分大小写，末尾无换行或空格 - 某些库（如早期
ws的旧版本）曾错误地对已编码的 key 再次编码，导致 Accept 值多一层 Base64
为什么这个计算能防缓存污染？
本质是挑战-响应机制：客户端提供不可预测的随机 nonce（Sec-WebSocket-Key），服务端用固定密钥（魔数）混合哈希，生成唯一响应值。这样即使中间 HTTP 代理缓存了响应，也无法复用于其他连接，因为每个 key 都不同。实际中要注意：
- 如果服务端硬编码了某个
Sec-WebSocket-Accept值（比如写死在代码里），所有连接都会失败 —— 它必须每次动态计算 - Nginx 等反向代理默认不转发 Upgrade 请求，需显式配置
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade，否则Sec-WebSocket-Key根本到不了后端 - 浏览器控制台 Network 面板能看到原始请求头，但无法看到服务端是否真按规范计算了 Accept —— 最快验证方式是用
curl -i手动发请求，比对响应头
调试时如何快速验证 Accept 是否正确？
不用启动完整服务，用一行命令就能验算：
echo -n "dGhlIHNhbXBsZSBub25jZQ==" | base64 -d | openssl sha1 -binary | xxd -p -c 20 | xargs -I {} echo -n {}"258EAFA5-E914-47DA-95CA-C5AB0DC85B11" | openssl sha1 -binary | base64
注意：echo -n 避免换行符混入，xxd -p -c 20 确保 SHA1 输出为连续 40 字符 hex（供后续拼接），最后再 Base64 —— 这个链路稍有错位，结果就完全不对。生产环境建议直接用成熟 WebSocket 库（如 gorilla/websocket 或 ws），它们内部已封装正确逻辑，自己手写极易出错。
