HTTP
426 - Upgrade Required
HTTP 426 Upgrade Required means the server refuses current protocol and requires the client to switch protocols.
Last reviewed: March 10, 2026|Editorial standard: source-backed technical guidance
What Does Upgrade Required Mean?
The server intentionally refuses the current protocol and requires a protocol upgrade before the request can be processed.
Common Causes
- -WebSocket endpoint requires TLS and Upgrade headers, but client sends plain HTTP request without upgrade semantics.
- -Service disables older TLS versions and client stack negotiates deprecated protocol that server no longer accepts.
- -gRPC endpoint expects HTTP/2 framing, but integration calls same path with HTTP/1.1 JSON request.
How to Fix Upgrade Required
- 1Read the server
Upgraderequirement and switch client transport/protocol accordingly. - 2Ensure intermediaries preserve upgrade negotiation headers and do not downgrade connections unexpectedly.
- 3Retest with explicit secure/protocol settings on the same route and authority.
Step-by-Step Diagnosis for Upgrade Required
- 1Capture full response headers and confirm required protocol listed in
Upgradeheader. - 2Trace protocol negotiation across client, edge, and origin to locate downgrade/strip points.
- 3Validate route policies that enforce secure transport or newer HTTP versions.
- 4Retest with compliant protocol stack and verify no 426 responses remain.
Upgrade Header and Negotiation Path Audit
- -Verify server advertises required protocol explicitly (example:
Upgrade: h2cor service-specific upgrade requirement). - -Check client capability mismatch (example: legacy runtime cannot negotiate required TLS/protocol combo).
Intermediary Transport Policy Consistency
- -Inspect proxies for upgrade-header stripping or forced downgrades (example: edge rewrites HTTPS requests to HTTP backend path).
- -Compare transport enforcement policies by environment (example: production requires TLS 1.2+, staging still allows older mode).
Implementation Examples
Reproduce HTTP 426 Upgrade Requiredcurl
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 426 Upgrade Required
# {"error":"Upgrade Required","code":"426"}Handle 426 in JavaScriptjavascript
const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 426) {
console.error('Handle 426 Upgrade Required');
}Handle 426 in Pythonpython
import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 426:
print('Handle 426 Upgrade Required')How to Verify the Fix
- -Re-run requests from representative clients and confirm protocol upgrade requirements are satisfied.
- -Validate negotiated protocol and transport policy are consistent across all ingress tiers.
- -Confirm upgrade-required telemetry drops to baseline after client and gateway fixes.
How to Prevent Recurrence
- -Standardize protocol support policy and authority routing configuration across environments.
- -Add pre-deploy tests for Host/SNI alignment, upgrade behavior, and version negotiation.
- -Continuously audit proxy and load-balancer protocol settings for drift.
Pro Tip
- -publish minimum protocol policy as machine-readable config consumed by both clients and gateways to prevent silent transport mismatches.
Decision Support
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.