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|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
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')Seen in Production
Client library upgrade defaults to unsupported protocol mode
Frequency: common
Example: SDK update forces HTTP/2 on a route where gateway-origin path only supports HTTP/1.1, causing 505.
Fix: Pin supported protocol for that endpoint or upgrade ingress/origin stack to consistent protocol capability.
Regional ingress policy drifts after network change
Frequency: rare
Example: One region disables required protocol fallback and starts returning 505 while others remain healthy.
Fix: Enforce protocol-policy parity checks and promote ingress config through one audited pipeline.
Debugging Tools
- -ALPN/protocol negotiation logs at ingress and gateway
- -curl protocol forcing (
--http1.1,--http2) for reproduction - -Ingress policy/config diff history
- -TLS handshake inspection tools
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.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.