Python — SSLError: wrong version number when using HTTPS

Diagnose the SSL wrong version number error by checking whether the endpoint is actually speaking TLS or is behind a misconfigured proxy.

intermediatedebuggingpythontls

Symptoms

SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number
TLS fails against an endpoint that should support HTTPS
HTTP works but HTTPS fails on the same host
A proxy or load balancer returns plain text to a TLS handshake

Possible causes

The client speaks TLS to a port or service that serves plain HTTP
A proxy or load balancer terminates or forwards incorrectly
A corporate TLS inspection proxy uses an untrusted certificate
The URL uses the wrong scheme for the actual service

Diagnosis steps

Check whether the port speaks TLS

openssl s_client -connect host:443 -servername host < /dev/null

Interpretation

If this returns plain text or a protocol error, the port is not a TLS endpoint, so the client is handshaking against the wrong service.

Try the plain HTTP scheme to compare

curl -v http://host:80/health

Interpretation

If plain HTTP works and HTTPS fails, the service is likely HTTP on that port or terminated elsewhere in the chain.

Inspect proxy environment variables

env | grep -i proxy

Interpretation

A proxy that intercepts or forwards TLS wrongly causes this error; bypassing it for the host confirms the proxy as the culprit.

Root cause

The client began a TLS handshake but the server or an intermediary responded with something that is not TLS, so the handshake parsed the plain bytes as a bad TLS version.

Fix

Use the correct scheme and port for the service, fix the proxy or load balancer so TLS is terminated and forwarded correctly, and trust the inspection proxy certificate where it is legitimate.

Verify the fix

Repeat the request over the corrected scheme and port and confirm it succeeds, then verify the certificate chain with openssl to confirm the expected issuer.

Symptom walkthrough

An HTTPS request fails with SSLError: WRONG_VERSION_NUMBER, which means the TLS handshake received bytes that are not a valid TLS record. The usual causes are sending TLS to a plain HTTP port, a proxy that mangles or misroutes the connection, or a TLS inspection appliance whose certificate is not trusted. The message points at TLS, but the defect is usually in the address or the network path.

Fix in practice

Confirm which port actually speaks TLS with openssl s_client, use the correct scheme and port, and correct the proxy or load balancer configuration so TLS terminates and forwards properly. When a legitimate inspection proxy is in place, install its certificate in the trust store rather than disabling verification.

Verification

Reissue the request against the corrected endpoint and confirm success, then inspect the certificate chain with openssl to confirm the expected issuer and hostname. A trusted chain plus a successful response proves the path is correct.

Diagnostic commands

Check the behavior with commands like these:

openssl s_client -connect host:443 -servername host < /dev/null
curl -v http://host:80/health
env | grep -i proxy