426 - Upgrade Required
HTTP 426 Upgrade Required means the server refuses current protocol and requires the client to switch protocols.
Last reviewed: February 12, 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
- -Server requires TLS or newer protocol version for this endpoint.
- -Client uses plain HTTP where secure transport is mandatory.
- -Upgrade negotiation headers are missing or blocked.
How to Fix Upgrade Required
- 1Read the server `Upgrade` requirement 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 `Upgrade` header.
- 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: h2c` or 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
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 426 Upgrade Required
# {"error":"Upgrade Required","code":"426"}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');
}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
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
404 Not Found vs 410 Gone: Missing vs Permanent Removal
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.
Playbook
Resource State Playbook (404 / 410 / ResourceNotFound)
Use this playbook to separate temporary missing-resource lookups from permanent removals, then fix scope, lifecycle, and identifier drift safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.