
HTTP 426 Upgrade Required means the server refuses to process the request using the current protocol and is requiring the client to switch to a different one. The server specifies which protocol to use via the Upgrade header field in its response. It is a 4xx client error, meaning the problem originates on the client side.
A server returns 426 when it has determined that the protocol the client is using is inadequate or insecure for the requested resource. This commonly happens when a server enforces a more secure protocol version, such as requiring TLS, and the client's request arrives over an older or unacceptable protocol. The server will not fulfill the request until the client reconnects using the specified protocol.
To resolve a 426 error, read the Upgrade header in the server's response to identify which protocol is required, then reconnect and resend the request using that protocol. If you are working with a client library or SDK, ensure it is up to date and capable of supporting the protocol the server specifies. Once the connection is re-established with the correct protocol, the server should process the request normally.
The Upgrade header is mandatory in a 426 response — the server must include it to tell the client exactly which protocol to switch to. Without this header, the client has no way of knowing what upgrade is required. The header typically specifies a protocol such as TLS/1.3 or WebSocket, and the client must use that protocol when retrying the request.
HTTP 426 and 101 are two sides of the same protocol-upgrade exchange. A 426 response is the server's rejection of the current protocol, instructing the client to upgrade. Once the client reconnects using the required protocol and the server accepts the switch, the server responds with 101 Switching Protocols to confirm the upgrade was successful.
HTTP 426 is classified as a 4xx client error, so the issue lies with the client's request rather than a server malfunction. The client is using a protocol that the server cannot or will not accept for the given resource. The server itself is functioning correctly — it is simply enforcing a protocol requirement that the client must meet before the request can be fulfilled.