HTTP 505 HTTP Version Not Supported

Quick reference

What it means

Every HTTP request begins with a request line that includes the protocol version: GET /path HTTP/1.1 or GET /path HTTP/1.0. When a server receives a request with a version it does not support, it returns 505 rather than attempting to parse and respond to the request under potentially incompatible semantics.

RFC 9110 describes the intent clearly: a server may refuse to service a request that requires protocol features it does not implement. This is most practically relevant when a client sends HTTP/1.0 to a server that requires HTTP/1.1's Host header for virtual host routing, or when HTTP/2 or HTTP/3 negotiation fails at the transport layer and falls back to an unsupported path.

In practice, 505 is rare on the public web because most modern HTTP stacks negotiate versions transparently through ALPN (Application-Layer Protocol Negotiation) during the TLS handshake. Where 505 appears most often is in internal infrastructure: legacy clients, misconfigured proxies, or custom HTTP implementations that hard-code a version number.

Common causes

HTTP/1.0 client missing the Host header

HTTP/1.0 did not require a Host header. HTTP/1.1 made it mandatory. Servers that host multiple virtual hosts depend on the Host header to route requests to the correct site. When a client sends an HTTP/1.0 request without Host, the server may return 505 (or 400) because it cannot process the request under HTTP/1.1 requirements. Legacy clients, shell scripts using telnet, or old automation tools are the typical culprits.

Proxy or load balancer rewriting the protocol version

Some proxy configurations downgrade requests from HTTP/1.1 to HTTP/1.0 when forwarding upstream. If the upstream server requires HTTP/1.1, it returns 505 to the proxy, which may surface the error to the client. This is a proxy misconfiguration. In Nginx, check the proxy_http_version directive; in Apache, check ProxyHTTP11.

HTTP/2 configuration mismatch at TLS negotiation

HTTP/2 is negotiated over TLS using ALPN. If a client advertises only HTTP/2 (h2) support but the server's TLS stack does not advertise h2 in its ALPN extension, the connection may fail. In some edge cases, the failure produces a 505 at the application layer after the connection falls back unexpectedly. Verify TLS configuration with openssl s_client -alpn h2 -connect host:443.

HTTP/3 / QUIC fallback issues

HTTP/3 runs over QUIC (UDP) rather than TCP. If a client has cached an Alt-Svc: h3 header from a previous response but the server's QUIC endpoint is misconfigured or temporarily disabled, connection failures can manifest as 505 in some implementations. Clear the QUIC cache in your browser (chrome://net-internals/#quic) and retry over TCP.

Custom HTTP client hard-coding an unsupported version

Internal tooling, monitoring agents, or legacy API clients sometimes hard-code a specific HTTP version string in their request line. If the server has been updated to require a newer version, these clients start receiving 505. The fix is to update the client to send a version string the server accepts, or configure the server to support the older version.

Test or debugging tool sending malformed version strings

Tools that manually construct HTTP requests (Postman, curl with --http1.0, custom scripts) can accidentally send unsupported version strings. A request line like GET / HTTP/2.0 is invalid — HTTP/2 does not use a version string in the request line in the same way. Servers that strictly validate the request line will return 505.

How to diagnose HTTP 505

1. Capture the exact request line. Use Wireshark, tcpdump, or server access logs to see exactly what version string the client is sending. The request line is the first line of the HTTP request.
2. Check server configuration. In Nginx, look for listen directives and http2 flags. In Apache, check the Protocols directive (e.g., Protocols h2 http/1.1). Confirm which versions the server is configured to accept.
3. Test with curl. curl --http1.0 https://example.com sends HTTP/1.0. curl --http1.1 forces HTTP/1.1. curl --http2 attempts HTTP/2. Identify which version the server accepts.
4. Inspect proxy configuration. If a proxy sits between client and server, log what version the proxy forwards upstream. Many Nginx proxy configs default to HTTP/1.0 for upstream requests unless explicitly set to HTTP/1.1.
5. Check ALPN negotiation. Run openssl s_client -connect host:443 -alpn h2,http/1.1 and inspect the server's selected protocol in the output.
6. Review server logs. Access logs often record the protocol version alongside the status code. Correlate 505s with specific client IPs or user-agent strings to isolate the source.

HTTP/1.0 vs HTTP/1.1 vs HTTP/2 — what servers accept

505 vs other 5xx codes

See also: 426 vs 505 comparison

FAQ

What does HTTP 505 mean?

HTTP 505 means the server does not support the HTTP protocol version the client used in the request. The server refuses to process the request rather than attempt to respond under an incompatible protocol version.

What HTTP versions can trigger a 505?

Any version the server does not accept: HTTP/1.0 on servers requiring HTTP/1.1, malformed HTTP/2 connections that fall back incorrectly, or custom version strings that no server recognizes. HTTP/1.1 is nearly universally supported and rarely triggers 505.

Is HTTP 505 a server or client error?

It is classified as a 5xx server error, but the mismatch is often caused by the client or a proxy sending an unsupported version. Both sides should be examined during diagnosis.

How do I fix HTTP 505?

Identify which HTTP version the client is sending (check access logs or capture the request), then update the client to use a version the server supports, or configure the server to accept the version the client sends. For proxy-induced 505s, set proxy_http_version 1.1 in Nginx or the equivalent in your proxy software.

Related resources

On this site: HTTP 505 troubleshooting guide · HTTP 426 Upgrade Required · HTTP 500 Internal Server Error · HTTP 502 Bad Gateway · All 5xx server errors

Comparisons: 426 vs 505

Standards: RFC 9110 §15.6.6 · IANA HTTP Status Code Registry · MDN Web Docs: 505