Does 505 mean my server needs HTTP/2 or HTTP/3?

No. 505 is about the version in the request the server received. Servers that do not support HTTP/2 or HTTP/3 negotiate down to HTTP/1.1 during connection setup instead of returning 505.

Can an unencoded space in a URL cause a 505?

It can. In HTTP/1.1 the request line is method, target and version separated by spaces. A raw space in the path can make a strict server read the wrong token as the version and reject it.

Is 505 a problem with the server or the client?

Usually the client or something between it and the server. The server is working; it is refusing a protocol version, so the fix is often in the client, a proxy or a load balancer setting.

505 HTTP Version Not Supported — HTTP Status Code

What 505 means

505 HTTP Version Not Supported means "I will not process this request in the HTTP version you used." It is defined in RFC 9110, Section 15.6.6. The RFC is specific that it concerns the major version, the first digit, such as the 1 in HTTP/1.1. The server is saying it cannot or will not complete the request in the same major version as the client, and it should describe in the response why that version is not supported and which protocols it does support.

The code dates from a time when HTTP/1.0 and HTTP/1.1 clients coexisted with experiments toward newer versions. Today, version choice is mostly settled before any request is sent: HTTP/2 is negotiated during the TLS handshake through ALPN, and HTTP/3 is discovered through the Alt-Svc header or DNS. A server that does not support a newer version simply does not offer it, so clients fall back without ever seeing a 505.

When you see it

You see 505 when a request reaches a server with a version string it does not accept:

An HTTP/1.x server receives a request line claiming HTTP/2.0 or HTTP/3.0, usually from a hand-written client or test tool.
A server configured to refuse HTTP/1.0 rejects an old client.
A proxy or load balancer forwards requests upstream using a version the backend does not support.
A malformed request line, often with an unencoded space in the URL, makes the server read a bogus version token.

It is sent by the origin server or by an intermediary that parses the request, such as a reverse proxy.

Common causes

Custom HTTP clients that build request lines by hand and send an invalid or unexpected version string.
Embedded devices and old software speaking HTTP/1.0 to a server set to require HTTP/1.1.
Proxy misconfiguration, such as a load balancer told to speak HTTP/2 in cleartext (h2c) to a backend that only speaks HTTP/1.1.
Bad URL encoding, where GET /my file.pdf HTTP/1.1 makes the server see file.pdf where the version should be.
Security or protocol filters that block old versions deliberately.

How to fix it

Find out what version was sent. Use curl -v or server access logs, which usually record the protocol of each request.
Encode URLs correctly. Spaces must be %20, and other reserved characters must be percent-encoded.
Align proxies and backends. If nginx or a cloud load balancer talks to your app, make sure the upstream protocol matches what the app supports. In nginx, proxy_http_version 1.1; is the usual setting for HTTP/1.1 backends.
Update old clients or, if you must support them, allow HTTP/1.0 on the endpoints they use.
Fix hand-written clients to use a mature HTTP library instead of composing request lines manually.

How to check it

Test the server against each version explicitly:

curl -s -o /dev/null -w "HTTP/1.0: %{http_code}\n" --http1.0 https://www.example.com/
curl -s -o /dev/null -w "HTTP/1.1: %{http_code}\n" --http1.1 https://www.example.com/
curl -s -o /dev/null -w "HTTP/2: %{http_code} (used %{http_version})\n" --http2 https://www.example.com/

The %{http_version} output shows which version was actually negotiated, which matters because --http2 falls back to HTTP/1.1 if the server does not offer HTTP/2. A 505 on one line and 200 on another tells you which version the server refuses.

What it means for uptime monitoring

PingRobot's checker sends a GET with the user agent PingRobot/1.0 (+https://pingrobot.io/bot), follows redirects, and treats the final response as up only if its status is 200–399. A 505 counts as down and is re-checked from a second region before alerting.

The checker uses a standard HTTP client that negotiates the version with your server, so a 505 is unlikely to be caused by the monitor itself. When it appears, look at what sits in front of the app. A changed upstream protocol setting on a proxy or load balancer, or a backend upgraded to reject older versions, can break the site for real visitors too. A 505 on a URL with unusual characters is worth checking for encoding problems in the monitored URL itself.

501 Not Implemented – the server lacks a feature, such as a method.
400 Bad Request – what many servers return for a malformed request line instead.
421 Misdirected Request – a connection-level mismatch, common with HTTP/2.
502 Bad Gateway – often what a proxy shows when the backend rejects its protocol.
511 Network Authentication Required – another rare 5xx code.

Start monitoring free — 10 monitors, no credit card.