HTTP 505 HTTP Version Not Supported: What It Means and How to Fix It

What this error means & how to recognize it

• A browser, API client, monitoring system, or command-line tool receives 505 HTTP Version Not Supported.
• The response may include a message indicating that the requested HTTP version is unsupported.
• DNS can resolve successfully and TLS can complete successfully because the client received an HTTP response afterward.
• The error may occur only with a particular client, protocol negotiation path, URL, HTTP method, or intermediary.
• Response headers can reveal whether the response came from a proxy, CDN, load balancer, or origin server and may show caching or connection details.

Root causes, ordered by likelihood

1. Unsupported HTTP protocol version: The endpoint does not support the major HTTP version used by the request. This is the defining cause of status 505.
2. Protocol mismatch between an intermediary and its upstream: A reverse proxy, CDN, load balancer, or gateway may use a protocol version that the next server does not accept, or may return its own 505 response.
3. Incorrect or incomplete HTTP protocol configuration: A recent server, proxy, or application change may have enabled or required a protocol version that is not supported across the full request path.
4. Client-specific negotiation or request behavior: One client or monitoring tool may select a different HTTP protocol than browsers or other clients, exposing a compatibility problem.
5. Unexpected response from a non-origin layer: The status may be produced by a gateway or security intermediary rather than the application that owns the URL. Headers and logs are needed to distinguish this from an origin-server response.

Authentication, rate limits, DNS, and TLS can affect a request, but they do not by themselves explain an HTTP 505 response. Treat them as separate investigation paths unless the response headers or logs connect them to the protocol-version failure.

How to fix it

For visitors and API users

1. Retry the exact URL once and check that the client is current and configured to make a normal HTTP request.
2. If the problem occurs in an API client or monitoring tool, compare the result with another supported client. Record whether the failure is client-specific.
3. Note the URL, HTTP method, approximate time, response status, and response headers. Do not include passwords, cookies, authorization tokens, or other secrets.
4. If the error persists, send those sanitized details to the site or API owner. A visitor generally cannot correct a server-side protocol compatibility problem.

For developers and site owners

1. Capture the exact request. Record the hostname, path, method, request protocol, client, timestamp, and final status. Confirm that the response is actually 505 rather than a redirect or a status displayed by a client after another failure.
2. Check protocol negotiation. Determine which HTTP version the client used or attempted to use and which version the endpoint, proxy, load balancer, or CDN supports. For encrypted connections, review the negotiated application protocol where your tooling exposes it.
3. Identify the response layer. Use response headers, server signatures where available, request identifiers, and access logs to determine whether the 505 came from the CDN, WAF, gateway, reverse proxy, web server, or application.
4. Correlate logs. Search the identified layer and the upstream layer for the same timestamp, route, method, client, and request ID. A missing origin log can indicate that an intermediary rejected the request before forwarding it.
5. Review recent protocol changes. Check recent deployments and configuration changes affecting HTTP version support, proxy-to-origin connections, load-balancer listeners, gateway routing, and client or monitoring configuration.
6. Apply the narrowest authorized correction. Align the affected client, intermediary, and origin with a protocol version supported by the complete request path. Do not disable TLS validation, authentication, or security controls as a workaround.
7. Retest the same request. Verify the original URL and method, then test representative routes and protocol paths. Confirm that the correction has not changed unrelated status codes or routing behavior.
8. Use a controlled rollout for shared infrastructure. If the affected setting serves many sites or routes, test it in an approved staging or limited-scope change before applying it broadly. Follow the environment’s change and rollback procedures.

Prevention & how to verify the fix

• Document the HTTP versions supported by clients, gateways, proxies, load balancers, and origins in each request path.
• Test important browser routes and API methods through the real production-like proxy and CDN path after protocol or infrastructure changes.
• Monitor status codes by route, client type, protocol, and deployment so client-specific 505 responses are visible.
• Keep proxy, load-balancer, web-server, and application configuration version controlled with a tested rollback path.
• Retain correlated access and gateway logs long enough to identify which layer generated an unexpected response.
• Keep monitoring tools and API clients maintained, and validate their protocol settings during onboarding or configuration changes.

Frequently asked questions