101 Switching Protocols

What 101 means

Sent in reply to an Upgrade request. After the 101 the connection stops being HTTP and speaks the negotiated protocol, typically WebSocket, on the same TCP connection.

In access logs a healthy WebSocket handshake appears as a single 101 line; a 200 or 400 where you expected 101 means a proxy stripped the Upgrade headers.

Common causes

• A WebSocket client sent Connection: Upgrade and Upgrade: websocket and the server accepted.

How to fix it

• If handshakes fail behind nginx, forward the headers: proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; and use HTTP/1.1 to the upstream.

What it looks like

A typical response:

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

The same event in an nginx access log (the status is the number after the request line):

203.0.113.7 - - [10/Sep/2026:10:12:01 +0000] "GET /socket.io/ HTTP/1.1" 101 153 "-" "Mozilla/5.0"

Check it with curl

-i prints the status line and headers, and -w '%{http_code}' prints only the number, which is handy in scripts and health checks. Replace the URL with yours:

curl -i -N -H 'Connection: Upgrade' -H 'Upgrade: websocket' -H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' https://example.com/socket

Compare what curl sees with what the browser sees. A different status from the same URL usually means a cache, a CDN edge or a cookie is in the way.

Investigating a run of 101s? Paste the log excerpt into Log Share to get line numbers, highlighting and an expiring link for whoever is on call with you.

Related status codes

• 100Continue: The server has seen the request headers and the client should send the body.
• 400Bad Request: The server could not understand the request because it is malformed.
• 426Upgrade Required: the client must switch protocols.

FAQ