505 - HTTP Version Not Supported
HTTP 505 HTTP Version Not Supported means the server does not support the major HTTP version used in the request.
Last reviewed: February 17, 2026|Editorial standard: source-backed technical guidance
What Does HTTP Version Not Supported Mean?
Requests are rejected at protocol negotiation time because this server path does not support the major HTTP version the client is attempting to use.
Common Causes
- -Legacy client forces HTTP/1.0 while server requires HTTP/1.1 semantics including Host header processing.
- -Misconfigured intermediary sends HTTP/2 prior knowledge preface to endpoint expecting HTTP/1.1 request line.
- -TLS terminator negotiates h2 but upstream plain listener cannot translate negotiated protocol version correctly.
How to Fix HTTP Version Not Supported
- 1Force clients to a server-supported HTTP version for the affected route and transport path.
- 2Align proxy/load-balancer protocol negotiation and ALPN settings with origin capabilities.
- 3Retest with explicit protocol flags and confirm successful end-to-end version agreement.
Step-by-Step Diagnosis for HTTP Version Not Supported
- 1Capture negotiated protocol details (ALPN, request version, upstream protocol policy) on failing requests.
- 2Verify which hop rejects the major version: edge, gateway, or origin.
- 3Check route-level protocol constraints and virtual-host mappings for mismatch with client expectations.
- 4Retest using explicit protocol settings against a known-good endpoint to isolate config drift.
Protocol Negotiation and ALPN Trace
- -Inspect negotiated transport protocol per hop (example: client attempts HTTP/2 while upstream listener only allows HTTP/1.1).
- -Audit TLS ALPN settings and fallback behavior (example: gateway disables h2 fallback and emits 505 on legacy clients).
Route Capability and Proxy Policy Validation
- -Verify route-specific protocol support (example: legacy admin route bound to HTTP/1.0-incompatible backend).
- -Compare proxy protocol policies across environments (example: staging accepts upgrade path, production policy blocks it).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 505 HTTP Version Not Supported
# {"error":"HTTP Version Not Supported","code":"505"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 505) {
console.error('Handle 505 HTTP Version Not Supported');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 505:
print('Handle 505 HTTP Version Not Supported')How to Verify the Fix
- -Re-run requests from representative clients and confirm protocol negotiation succeeds without 505.
- -Validate protocol/version compatibility across edge, proxy, and origin in all environments.
- -Confirm canary monitoring detects and blocks unsupported protocol config changes.
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
- -codify protocol support matrix in contract tests that run against every ingress tier to catch version-policy drift before rollout.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.