101 Switching Protocols

The server agrees to switch the connection to the protocol named in the Upgrade header, most often WebSocket.

101 at a glance

Code: 101
Name: Switching Protocols
Class: 1xx Informational
Status: IANA-registered standard code
Defined in: RFC 9110, Section 15.2.2
Cacheable by default: No. Interim (1xx) responses are never stored by caches.

What 101 means

101 Switching Protocols is the server accepting a client's Upgrade request on an HTTP/1.1 connection. After the empty line that ends the 101 response, the bytes on the connection belong to the new protocol. Almost every 101 you will see is a WebSocket handshake. HTTP/2 and HTTP/3 do not use 101; WebSockets over HTTP/2 use extended CONNECT (RFC 8441).

What typically causes a 101

A browser or client opening a ws:// or wss:// connection.
An HTTP/1.1 client asking to upgrade to cleartext HTTP/2 (Upgrade: h2c), which is now rare.

Fix it on the server

Behind nginx, WebSockets need proxy_http_version 1.1;, proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade";, otherwise the backend never sees the Upgrade and returns 200, 400 or 426.
Raise proxy_read_timeout (60 s by default in nginx) or send pings, or idle WebSockets will be cut.
AWS ALB and Cloudflare pass WebSockets through without extra config; the ALB idle timeout (60 s default) still applies.

Fix it as a client or visitor

If the handshake returns 200 or 400 instead of 101, a proxy in the middle is dropping the Upgrade and Connection headers.
Check the Sec-WebSocket-Accept header matches the key you sent; libraries do this for you.

Headers that go with 101

Header	Role
`Upgrade`	Names the new protocol, e.g. `websocket`.
`Connection`	Must include `Upgrade`.
`Sec-WebSocket-Accept`	WebSocket only: hash of the client's Sec-WebSocket-Key (RFC 6455).

Example response

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