SSL routines: wrong version number. The Other End Is Not Speaking TLS

OpenSSL reason 267, SSL_R_WRONG_VERSION_NUMBER, string wrong version number. Every TLS record starts with a type byte and a protocol version; when the first bytes the client receives do not look like a TLS record header, OpenSSL stops with this reason. The answer it got was not a TLS ServerHello at all. The most common thing on the other end is a plain HTTP server, whose HTTP/1.1 400 or HTTP/1.1 200 starts with bytes that OpenSSL tries to read as a version.

The packed error code tells you the OpenSSL generation. OpenSSL 3 prints error:0A00010B:SSL routines::wrong version number (library 20 shifted into the top bits, reason 0x10B); OpenSSL 1.1.1 printed error:1408F10B:SSL routines:ssl3_get_record:wrong version number (sslerr.h, ssl_err.c). You meet it as:

• curl: exit 35, curl: (35) ... wrong version number
• Python: ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number
• Node.js: code: 'ERR_SSL_WRONG_VERSION_NUMBER'

Despite the name, it is almost never about TLS 1.2 versus 1.3. A real version disagreement produces tlsv1 alert protocol version or a handshake failure instead.

The proxy case catches many people because the variable is called https_proxy. It names the proxy used for HTTPS requests, and the scheme in its value describes how to talk to the proxy. curl treats an https:// proxy as an HTTPS proxy and starts TLS to it (curl manual, --proxy); a Squid listening in plain HTTP on 3128 answers with HTTP, and you get wrong version number before the request even leaves for the real site.

The mail case follows RFC 8314: port 465 carries mail submission over implicit TLS, while 587 starts in clear text and upgrades with STARTTLS (RFC 8314). Python's smtplib.SMTP_SSL on 587 fails with exactly this error.

curl -v http://example.com:443/
# < HTTP/1.1 200 OK   -> the "TLS" port is answering in plain HTTP
openssl s_client -connect example.com:443 -servername example.com </dev/null
# ... SSL routines::wrong version number

If plain HTTP to the TLS port works, the server is misconfigured. If the server is fine from your laptop but not from a CI runner or office machine, look at the environment of the failing one:

env | grep -i _proxy
curl -v --noproxy '*' https://example.com/

Success with --noproxy '*' means the proxy setting is the cause. For mail servers, test both modes explicitly:

openssl s_client -connect mail.example.com:465 -brief </dev/null
openssl s_client -connect mail.example.com:587 -starttls smtp -brief </dev/null

1. Client URL: use https:// only on ports where TLS is configured. An app server on 8080 or 3000 usually expects http:// unless you set up TLS on it.
2. Proxy variables: set http_proxy and https_proxy to http://proxy.example.com:3128 unless your proxy really accepts TLS on that port. Check /etc/environment, CI variables, Docker daemon proxy settings and ~/.npmrc as well as the shell.
3. nginx: every TLS port needs the ssl parameter: listen 443 ssl; (and listen [::]:443 ssl;). Run nginx -T | grep -n 'listen' to find a 443 listener without it, often a second server block that wins for some names.
4. Load balancers: if TLS is terminated at the balancer, the backend speaks HTTP. A client that bypasses the balancer and calls the backend with https:// gets this error.
5. SMTP clients: pair 465 with implicit TLS (SMTP_SSL, secure: true) and 587 with STARTTLS (starttls(), secure: false).

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
# Protocol version: TLSv1.3
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
# 200

The SSL/TLS checker connects to port 443 of your host and reports the negotiated protocol and certificate, so a plain-HTTP listener on 443 shows up immediately.

• SSL_ERROR_RX_RECORD_TOO_LONG — Firefox's report of the same plain-HTTP-on-443 mistake
• ERR_SSL_PROTOCOL_ERROR — Chrome's broad TLS failure
• curl error 35 — the exit code curl uses for this reason
• SSL handshake failed — when TLS is spoken but the sides do not agree
• How to install SSL on nginx — listen directives done right