426 Upgrade Required
The server refuses the request on the current protocol and names the protocol the client must switch to.
Status
HTTP/1.1 426 Upgrade Required
Details
- Category: 4xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.5.22
- Cacheable: Only with explicit cache headers
- Response body: Allowed
- Retry: Retry only after changing the request
426 is a refusal with instructions. The server will not serve this resource over the protocol in use, and the Upgrade header names what it wants instead. The classic case is a WebSocket endpoint answering a plain GET, telling the client to upgrade rather than poll.
It can also be used to force a newer version of a protocol, for example refusing an obsolete TLS version at the application layer.
Headers
- Upgrade: Required. Names the protocol the client must use, e.g. websocket or HTTP/2.0.
- Connection: Must be Upgrade.
Common causes
- A plain HTTP GET against a WebSocket-only endpoint.
- A missing Sec-WebSocket-Key or version header on an upgrade attempt.
- A server requiring a newer protocol version than the client offered.
How to fix it
As the client
- Send the upgrade handshake with the headers the server named.
- Verify that every proxy in the path forwards Upgrade and Connection, since stripping them turns a successful handshake into a 426 loop.
As the server
- Always name the required protocol in Upgrade. A 426 without it tells the client nothing.
- Return a short explanatory body for developers hitting the endpoint from a browser.
Examples
GET /socket HTTP/1.1 Host: realtime.example.com HTTP/1.1 426 Upgrade Required Upgrade: websocket Connection: Upgrade