Runs in your browser. Your files and text never leave your device - nothing is uploaded.
1xx Informational
What it means
The server agrees to switch protocols as requested by the client, e.g. from HTTP to WebSocket.
| Property | Detail |
|---|---|
| Status class | 1xx Informational |
| Defined in | RFC 9110, Section 15.2.2 |
| Cacheable by default | No. 1xx responses are interim, and RFC 9111 only lets a cache store a final response. |
| Who needs to act | Nobody when it succeeds. A failed upgrade is fixed on the server or a proxy in front of it. |
What does HTTP 101 Switching Protocols mean?
HTTP 101 Switching Protocols means the server accepted the client's Upgrade request and the connection now speaks a different protocol. In practice it almost always marks a successful WebSocket handshake over HTTP/1.1. After the 101, the connection carries WebSocket frames instead of HTTP messages until one side closes it.
How 101 Switching Protocols works
A client asks to change protocol with two headers: Upgrade, naming the new protocol, and Connection: Upgrade. If the server agrees it replies 101 and, as RFC 9110 requires, includes its own Upgrade header naming the protocol now in effect. For WebSocket (RFC 6455) the server also proves it understood the handshake by returning Sec-WebSocket-Accept, a hash derived from the client's Sec-WebSocket-Key. The code exists only in HTTP/1.1. RFC 9113 states that HTTP/2 does not support 101, because a multiplexed connection cannot be handed over to another protocol; WebSockets over HTTP/2 use extended CONNECT (RFC 8441) and succeed with a 200 instead.
Example 101 request and response
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=The key and accept values are the worked example from RFC 6455. Any other status here, such as 200, 400 or 426, means the WebSocket was not opened.
When servers send 101 Switching Protocols
- A browser opening a WebSocket with new WebSocket('wss://...') over HTTP/1.1.
- Libraries such as Socket.IO upgrading from HTTP long-polling to a WebSocket transport.
- Older clients requesting an upgrade to h2c (cleartext HTTP/2), a mechanism RFC 9113 now deprecates.
How to handle 101 Switching Protocols
If a WebSocket will not connect
- Open the browser's Network tab, filter by WS, and check the status of the handshake request; no 101 means the upgrade never happened.
- Confirm the URL uses ws:// or wss:// and that the path matches the server's WebSocket route.
If you run the server or proxy
- Make sure every proxy forwards the Upgrade and Connection headers. nginx needs proxy_http_version 1.1, proxy_set_header Upgrade $http_upgrade and proxy_set_header Connection "upgrade".
- Raise proxy read timeouts for idle sockets, or send periodic pings, so long-lived connections are not cut off; nginx closes a proxied connection that is silent for 60 seconds by default.
- On load balancers, enable WebSocket support and sticky sessions if the application keeps per-connection state.
Related status codes
- 426 Upgrade Required: The reverse situation: the server refuses to continue until the client switches to the protocol named in its Upgrade header.
- 200 OK: What a successful WebSocket over HTTP/2 returns, because extended CONNECT replaces the 101 handshake.
- 400 Bad Request: The reply RFC 6455 suggests for a malformed handshake, such as a missing Sec-WebSocket-Key.
Frequently asked questions
The server agrees to switch protocols as requested by the client, e.g. from HTTP to WebSocket.
Returned when a client sends an "Upgrade" header requesting a protocol change, typically for WebSocket connections.
Informational only - expected during a WebSocket handshake or protocol upgrade.
Over HTTP/1.1, a 200 usually means a proxy or the application treated the handshake as an ordinary GET and served a page. Check that the request reaches the WebSocket handler and that every proxy forwards the Upgrade and Connection headers.
No. It is the success signal for a protocol upgrade. It only looks unusual in browser developer tools because the request never completes in the normal way: the connection stays open for WebSocket traffic.
Sources
- RFC 9110, Section 15.2.2
- RFC 6455, Section 1.3 (WebSocket opening handshake)
- RFC 9113, Section 8.6 (no 101 in HTTP/2)
Other 1xx Informational codes
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026