< Sec-Websocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

TL;DR: Sec-WebSocket-Accept is the server’s answer to the client’s Sec-WebSocket-Key: base64(SHA-1(key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11)). If it’s missing or wrong, the client drops the HTTP/1.1 upgrade. It proves the server understood the handshake, not who anyone is.

Why This Header Exists

A 101 status on its own isn’t enough to open a WebSocket. Some server or proxy that knows nothing about WebSockets could send one. So the client also checks that the response contains a value computed from the key it just sent. RFC 6455 §4.1 defines that check.

What The Exchange Looks Like

Using the RFC’s sample key dGhlIHNhbXBsZSBub25jZQ==, the server’s response looks like this:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

A blank line ends the HTTP headers. Everything after that on the connection is WebSocket frames.

Because the value depends on the request’s random key, a stale or unrelated HTTP response can’t pass the check by accident. But there’s no secret involved: anyone who sees the key can compute the answer. It isn’t a signature, and it doesn’t mean the server authenticated the client.

How The Server Computes It

Here it is in Node. Run it with node --input-type=module, or save it as an .mjs file:

import { createHash } from 'node:crypto'

const key = 'dGhlIHNhbXBsZSBub25jZQ=='
const guid = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'
const accept = createHash('sha1').update(key + guid, 'ascii').digest('base64')
console.log(accept)
// RFC 6455 example result: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Hash the base64 key string as sent, not the bytes it decodes to. That’s the most common bug. Also trim surrounding whitespace when you parse the header. RFC 6455 §4.2.2 defines the server side. This snippet only computes the header; a real server has a lot more to do.

What To Check When Handshakes Fail

Start by recomputing the accept value from the key the client actually sent. If your result differs from the server’s, compare the request headers on both sides of any proxy to see whether something changed the key along the way.

If the value matches but the connection still fails, check the rest of the response: status 101, Upgrade: websocket (case-insensitive), and Upgrade in the Connection header. The client also fails the handshake if the server picks a subprotocol or extension it never offered. Keep Content-Length and Transfer-Encoding off a 101; RFC 9110 forbids Content-Length on 1xx responses, and RFC 9112 §6.1 forbids Transfer-Encoding.

The key is just a nonce and the accept value is a fixed transformation of it. For security, you still need TLS (wss://) and your own authentication.

Behind nginx, send the same request straight to the backend and through the proxy. If the backend answers 101 and the edge answers 200 or 502, the hash is fine; look at whether Upgrade and Connection are being forwarded. They’re hop-by-hop headers, so nginx’s WebSocket instructions have you pass them on explicitly.

Related Headers

• Sec-WebSocket-Key
• Upgrade
• 101 Switching Protocols