HTTP 426 Upgrade Required — What It Means & How to Fix
HTTP 426 Upgrade Required is an HTTP response status code that indicates the server refuses to process the request using the current protocol and requires the client to upgrade to a different protocol. The response includes an Upgrade header specifying which protocol the server expects.
What It Means
Defined in RFC 7231 Section 6.5.15, the 426 status code signals that the server supports the resource but only via a different protocol. The server sends an Upgrade header listing acceptable protocols, and the client should switch protocols by sending a new request with the appropriate Upgrade header and Connection: Upgrade.
Common scenarios include upgrading from HTTP to HTTPS, or from HTTP/1.1 to HTTP/2 or WebSocket.
When It’s Sent
- HTTP to HTTPS redirect — A server that only accepts HTTPS but receives an HTTP request.
- HTTP/1.1 to HTTP/2 upgrade — A server that only supports HTTP/2 connections.
- WebSocket upgrades — An endpoint that requires the WebSocket protocol instead of plain HTTP.
- TLS negotiation — Servers that require TLS 1.2 or higher and reject older TLS versions.
- Custom protocol upgrades — APIs that require specific protocol versions or extensions.
Real Example
The following curl command attempts to connect to a server that requires HTTPS:
curl -v http://httpbin.org/status/426 2>&1 | grep -E "< HTTP|Upgrade"Expected response:
HTTP/1.1 426 Upgrade Required
Date: Sat, 20 Jun 2026 12:00:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 150
Upgrade: TLS/1.2, HTTP/1.1
Connection: Upgrade
<html>
<head><title>426 Upgrade Required</title></head>
<body><h1>Upgrade Required</h1><p>Use HTTPS instead of HTTP.</p></body>
</html>How to Debug & Fix
Client-Side
- Use HTTPS instead of HTTP — The most common fix. Change
http://tohttps://in your URL. - Check the Upgrade header — Read the
Upgradeheader to see which protocol the server requires. - Use a modern HTTP client — Ensure your HTTP library supports HTTP/2 and WebSocket upgrades.
- Implement protocol upgrade logic — In custom clients, handle 426 by reconnecting with the upgraded protocol.
- Update URL references — Fix hardcoded HTTP URLs in your code, config files, and bookmarks.
Server-Side
- Include clear Upgrade instructions — Always return an
Upgradeheader with the required protocol. - Implement automatic redirects — For HTTP-to-HTTPS, use 301 or 308 redirect instead of 426 for better compatibility.
- Log upgrade failures — Track clients that attempt to connect using outdated protocols.
- Support multiple protocols — Maintain backward compatibility where possible, especially for public APIs.
Common Causes Table
| Scenario | Likely Cause | How to Fix |
|---|---|---|
| Curl returns 426 | URL uses HTTP instead of HTTPS | Change to https:// or use -L to follow redirects |
| API client upgrade fails | Library sends HTTP/1.1 but server requires HTTP/2 | Use an HTTP/2-capable client library |
| WebSocket connection fails | Client sends plain HTTP instead of upgrade request | Use ws:// or wss:// with proper Upgrade headers |
| Old mobile app broken | App hardcoded HTTP URLs, server now requires HTTPS | Update the app to use HTTPS URLs |
| Browser shows 426 | Website disabled HTTP and does not redirect | Type https:// explicitly in the address bar |
FAQ
Related Codes
HTTP 301 Moved Permanently — Permanent redirect, commonly used for HTTP to HTTPS.
HTTP 308 Permanent Redirect — Permanent redirect that preserves the request method.
HTTP 101 Switching Protocols — The server agrees to switch protocols (the successful counterpart to 426).
HTTP 505 HTTP Version Not Supported — The server does not support the HTTP protocol version used.
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro