HTTP 505 HTTP Version Not Supported: Causes and Fixes

A 505 means the server refuses to process the request because of the HTTP protocol version in the request line, such as GET / HTTP/2.0 or HTTP/0.9. The server is saying it cannot or will not speak that version. Per the HTTP specification, the response should explain which versions it does support. See the HTTP 505 reference.

Browsers almost never trigger this, because they negotiate the version through TLS (ALPN) before sending the request. A 505 usually comes from a script, a proxy, a load balancer or a misconfigured server speaking the wrong dialect.

If you are a visitor

1. Reload, then try a private window to rule out extensions.
2. Switch networks. A corporate or school proxy that rewrites traffic may send a version the site rejects.
3. Update your browser. Very old clients can hit servers that dropped HTTP/1.0 support.
4. Report it to the site owner with the URL and the time if it persists.

If you run the site: reproduce with each version

Force a version with curl and see which fail:

curl -sI --http1.0 https://example.com/ | head -n 1
curl -sI --http1.1 https://example.com/ | head -n 1
curl -sI --http2   https://example.com/ | head -n 1
curl -sI --http3   https://example.com/ | head -n 1

The --http3 flag only works if your curl build supports it. The HTTP/2 and HTTP/3 Checker shows what your server advertises from the outside. If every version fails, the problem is likely not the version at all; look at the proxy in front or the server's error log.

Causes, most likely first

1. A proxy talks HTTP/1.0 to a backend that needs HTTP/1.1

nginx's proxy_pass uses HTTP/1.0 to upstreams by default. Backends that require 1.1 features (chunked requests, Host-based routing without a header, WebSocket upgrades, keep-alive) may reply with an error. Set 1.1 explicitly:

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
}

For WebSockets, also pass Upgrade and Connection: upgrade. See nginx 502 and 504 timeout tuning for other proxy settings.

2. HTTP/2 spoken to a server that only has HTTP/1.1

Clients that use HTTP/2 over cleartext with prior knowledge (curl --http2-prior-knowledge, some gRPC and internal tools) send the h2 connection preface directly. A server or port that only expects HTTP/1.x may answer 505 or 400. The fix is to point the client at a port that serves h2c, or to use TLS so the version is negotiated by ALPN. On nginx, enable HTTP/2 on the TLS listener; the syntax depends on the version, so check the current nginx documentation for the listen ... http2 and http2 on; forms.

3. The server is configured with a limited protocol list

Apache can restrict protocols with the Protocols directive:

Protocols h2 http/1.1

If a load balancer or CDN is set to talk a version the origin does not offer (for example, forcing HTTP/2 to the origin), the origin may reject it. Match the origin protocol setting in your CDN or load balancer to what the origin supports, or enable the protocol on the origin.

4. Malformed or invented request lines

Hand-built requests with a typo (HTTP/1.2, HTTP 1.1, HTTP/2.0 over a text connection) are rejected. This also happens with raw sockets, test tools, and some old embedded devices. Fix the client to send HTTP/1.1. When debugging with netcat or telnet, send:

GET / HTTP/1.1
Host: example.com
Connection: close

5. Security devices that block old or unusual versions

Some WAF rules and appliances intentionally refuse HTTP/0.9 and HTTP/1.0, since scanners and bots often use them. If legitimate old clients are blocked, relax the rule; if only bots are blocked, leave it. Check the response headers to find which device answered, using the HTTP Header Checker or CDN Detector.

How to verify

Re-run the four curl commands above and confirm each supported version returns a normal status line. Confirm the page status with the HTTP Status Checker, and check the error log for the same request path after your change. In nginx, sudo nginx -t && sudo systemctl reload nginx applies a config edit; in Apache use sudo apachectl configtest followed by a graceful restart.

Keep an Uptime Monitor on the endpoint, since protocol changes at a CDN or load balancer can quietly break one path.

Next steps

• Check protocol support with the HTTP/2 and HTTP/3 Checker.
• Read HTTP/2 and HTTP/3 explained for how version negotiation works.
• Identify the replying layer with the CDN Detector.
• See load balancer health checks if the origin is behind one.
• Review the HTTP 505 reference.

FAQ

Can a normal browser cause a 505?

Rarely. Browsers negotiate the protocol version through TLS before sending requests, so a 505 almost always comes from a script, proxy or server configuration.

Is a 505 the same as a 400?

No. A 400 means the request is malformed in general. A 505 specifically rejects the protocol version, though some servers return 400 for the same problem, so look at the log message.

Should I disable HTTP/1.0 on my server?

Only if you know your clients. Old tools and some health checkers still use 1.0, so test with your monitoring and load balancers first.

Does a 505 affect SEO?

Crawlers use modern HTTP versions, so a 505 for them means a real fault in your stack. Fix it quickly if it appears for normal GET requests.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.