HTTP 505 HTTP version not supported

What 505 means

HTTP 505 HTTP Version Not Supported is a server error response that says the HTTP version named in the request is not supported by the server. In HTTP/1.1 the request line carries the version, so a 505 most often appears when that version token is wrong or when the surrounding request cannot be interpreted as a supported protocol. It is the version-specific member of the family of rejection codes, distinct from a 501 Not Implemented, which is about an unimplemented method for a resource the server otherwise understands; the 501 article draws the contrast.

The practical reality is that 505 is rarely seen on a busy site, because modern browsers negotiate versions up front. It tends to surface in three specific situations, covered next.

The main causes

1. A malformed request line. If a proxy, load balancer or hand-built client produces a request line with a broken version token or a space in the URL, the origin can read the mismatch as an unsupported version and answer 505. An example is a percent-encoding mishandled by an intermediary so that the origin sees part of the URL where it expects the version.
2. An HTTP/2 preface arriving at an HTTP/1.1-only server. When a client speaks HTTP/2 with prior knowledge and sends the h2 connection preface (PRI * HTTP/2.0 ...) to a server that only speaks HTTP/1.1, the server treats the bytes as an unsupported version. Most such servers reply with 400 or simply close the connection rather than 505, but 505 is the spec-applicable response in some implementations. See the ALPN / HTTP/2 negotiation article for how versions are supposed to be negotiated over TLS before this can happen.
3. An old client or server pair. An archaic client pinning an ancient version, or a server whose HTTP/2 support is disabled while a client insists on it, produces an irreconcilable mismatch. The fix is almost always to let the client fall back to the version the server supports, not to force the option.

Fix the version mismatch

Work out where the version is being clamped. Check the request in the access or error log for the version token the server rejected, and compare with the version the browser is trying to speak. If the site is behind a load balancer or reverse proxy, confirm the proxy is not rewriting the request line or forcing a specific version for the origin; a misconfigured proxy is the classic source of otherwise inexplicable 505s.

Because modern browsers fall back automatically when a connection fails, most regular visitors will never see the error unless the mismatch is hard-blocked at the edge. When you do see it, verify HTTP/2 and HTTP/1.1 are both available via curl --http2 and curl --http1.1 against the site, then fix whichever path is broken rather than describing the failure as a general site problem. For cases where HTTP/2 is disabled at the server while the client insists, re-enable the negotiated upgrade path per the ALPN negotiation guide or accept the HTTP/1.1 fallback. Treat a truly unsupported version as the rare technical case in the wider status code list rather than a routine failure to optimise for.