SSL wrong version number and SSL_ERROR_RX_RECORD_TOO_LONG usually mean the client is speaking TLS to a port or intermediary that is speaking ordinary HTTP. Check the URL scheme, destination port, proxy path, and server listener before changing certificates or disabling verification. These failures normally happen before a certificate can be validated.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The reliable fix is to make every hop agree on the protocol: use https:// on the service’s TLS port, configure the reverse proxy or web server for TLS, ensure the proxy tunnels HTTPS, and verify that client and server share a current TLS version.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →What these SSL errors actually indicate
Although the messages say SSL, modern connections generally use TLS. A TLS client begins by sending a binary handshake. If the other side answers with readable HTTP text, an HTTP proxy response, or bytes from a service that is not configured for TLS, the client cannot parse the response and reports a protocol error.
| Message | Typical point of failure | What it usually means |
|---|---|---|
wrong version number |
Before normal certificate validation | The peer, proxy, or selected port is speaking a different protocol. It is not normally proof that the certificate uses an old version. |
SSL_ERROR_RX_RECORD_TOO_LONG |
When the client expects a TLS record | Commonly an HTTP service is listening on the port selected for HTTPS, or a proxy has returned HTTP instead of tunneling the connection. |
Python WRONG_VERSION_NUMBER |
Requests/OpenSSL handshake | The Python process received non-TLS data. An intercepting application can produce the same exception. |
| curl TLS handshake failure | Connection setup | Inspect curl’s verbose trace to determine whether the failure is a wrong port, proxy response, protocol mismatch, or a later certificate problem. |
An expired, self-signed, or otherwise untrusted certificate produces a different class of error after the server has sent a certificate. Replacing a certificate cannot turn a plaintext listener into a TLS listener.
#1 Best Overall
Fast diagnostic sequence
Run these checks from the machine that experiences the failure. Record the exact hostname, port, URL, and network path; testing a different client can hide a proxy-specific problem.
- Confirm the scheme and port. Make sure the request uses
https://and that the port is the service’s TLS port. Port 443 is conventional, but deployments often use another documented TLS port. - Inspect the connection with curl. Use
curl -v https://host:443/. The trace shows proxy selection, address resolution, the start of the TLS handshake, and any response that arrives before TLS is established. - Test the TLS endpoint directly. Run
openssl s_client -connect host:443 -servername host. The-servernameoption sends SNI, which is essential when several HTTPS names share one address. - Look at the first response bytes. A line such as
HTTP/1.1 301,HTTP/1.1 400, or an HTML page where a TLS handshake should be indicates that the selected port or intermediary is returning plaintext HTTP. - Check proxy environment variables. Review
HTTP_PROXY,HTTPS_PROXY, andNO_PROXY. A proxy can be correctly reachable yet still be configured to receive HTTP while the client is attempting an HTTPS tunnel. - Compare another network or client. If the same hostname works from a second network but fails on one workstation, investigate its proxy, security appliance, or local interception software before changing the server.
A refused connection or timeout points to reachability, firewall, DNS, or routing rather than a TLS record-format mismatch. Fix that lower-layer problem first.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteHow to read curl and OpenSSL output
Readable HTTP text on an HTTPS connection
In a curl trace, an immediate HTTP status line means the peer answered in plaintext. Common causes are an HTTP-only application bound to port 443, a load balancer forwarding the wrong listener, or a proxy returning its own error page. Move the request to the documented HTTP port or enable TLS on the intended endpoint.
A successful TLS handshake followed by a certificate complaint
If OpenSSL displays a server certificate and curl reports certificate verification, protocol negotiation succeeded. The remedy is a trusted CA chain, correct hostname, or current certificate—not a port change. Keep certificate verification enabled while correcting trust.
Different results with and without SNI
Run the OpenSSL command with the real hostname in -servername. Without SNI, a multi-site server may return a default certificate or reject the handshake. A result that changes when SNI is supplied points to virtual-host selection rather than a missing certificate on the machine.
Rank #2
Handshake stops before any certificate appears
When no certificate is shown, concentrate on the port, proxy, interception layer, and protocol overlap. A server cannot prove its identity until the TLS handshake reaches certificate exchange.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Correct the URL, port, and listener
Start at the endpoint configuration rather than the client’s certificate settings.
- Use
http://only for a listener that is deliberately plaintext, and usehttps://for a listener configured for TLS. - Do not assume that every service on port 443 is encrypted. Verify the process bound to the port and the listener mode in the load balancer, container, or web-server configuration.
- For a custom port, test that exact port with both curl and OpenSSL. A service may expose HTTP on one custom port and HTTPS on another.
- If TLS terminates at a reverse proxy, send HTTPS to the proxy’s TLS listener. The proxy may then use HTTP or HTTPS on its private upstream connection; those are separate hops and must be configured independently.
- Check redirects. A redirect from an HTTPS URL to an HTTP URL is not itself a TLS error, but an application or proxy that sends an HTTP response on the TLS port is misconfigured.
After changing a listener, restart or reload the component that owns the port, then repeat the direct OpenSSL test. Testing only through a browser can retain cached proxy or redirect behavior.
Fixing an NGINX HTTPS listener
For NGINX, the intended virtual host must explicitly enable TLS and identify the certificate files. A minimal server block has the following shape:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/nginx/tls/example.com/fullchain.pem;
ssl_certificate_key /etc/nginx/tls/example.com/privkey.pem;
location / {
proxy_pass http://app_backend;
}
}The important checks are:
listen 443 ssl;is present in the server block that should answer HTTPS. A plainlisten 443;leaves NGINX expecting HTTP on that port.server_namematches the hostname clients send. A mismatch can select another virtual host and its certificate.ssl_certificatepoints to the public certificate, normally including the intermediate chain. The server certificate is public and is sent to every connecting client.ssl_certificate_keypoints to the private key. Protect it from ordinary users; NGINX’s master process must be able to read it when loading the configuration.- Validate the configuration with
nginx -tbefore reloading. Resolve any path, permission, or syntax error reported by that command.
Do not paste a private key into a support ticket or make it world-readable to solve a permission problem. Correct ownership and group permissions for the NGINX master process instead.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsCertificate-chain details
A missing intermediate certificate generally causes a trust or chain-building error after TLS starts. It does not normally create WRONG_VERSION_NUMBER. Treat chain repair as a separate task once the endpoint proves that it is speaking TLS.
Session-cache tuning is not a protocol fix
NGINX documentation gives an example that 1 MB of shared SSL session cache stores about 4,000 sessions. That capacity can reduce handshake overhead, but changing the cache cannot fix a plaintext response, wrong port, or incompatible protocol. Establish a clean handshake first, then tune performance.
Check SNI when several HTTPS sites share one address
Server Name Indication lets a client send the requested hostname during the handshake. Name-based HTTPS hosting requires SNI support on the client and server, and the client must actually send the hostname.
Use the real name in OpenSSL:
openssl s_client -connect 203.0.113.10:443 -servername example.comFor curl, test a specific address while preserving the hostname used for SNI and certificate checks:
curl -v --resolve example.com:443:203.0.113.10 https://example.com/If the address works with the expected SNI name but fails when accessed by an IP address, configure clients to use the hostname and ensure DNS points to the correct listener. If one hostname selects a plaintext virtual host, correct the NGINX server-block ordering and server_name values.
Rank #4
Verify TLS protocol overlap without downgrading security
Current NGINX guidance treats TLS 1.2 and TLS 1.3 as modern defaults. Older NGINX or OpenSSL combinations can expose different defaults, so inspect the versions actually deployed before changing protocol directives.
- Check the NGINX and OpenSSL versions on the server.
- Check the client runtime and its TLS library, especially for old operating systems or embedded devices.
- Test each supported protocol explicitly when diagnosing overlap:
openssl s_client -connect host:443 -servername host -tls1_2and, where supported,openssl s_client -connect host:443 -servername host -tls1_3. - Enable only protocol versions supported by the installed software and organizational policy. Do not re-enable obsolete SSL versions as a permanent workaround.
A genuine protocol-version mismatch can prevent a handshake, but the phrase “wrong version number” more often reflects non-TLS bytes on the connection. Confirm the first bytes and listener mode before narrowing protocol lists.
Repair proxy and interception problems
HTTPS normally reaches a forward proxy through a CONNECT tunnel. If the proxy receives a TLS handshake as though it were ordinary HTTP, or if it returns an HTTP error page directly, the client reports a record or version error.
Recommended Free Tools
Inspect and isolate environment settings
Display the proxy variables used by the failing process. Ensure HTTPS_PROXY identifies a proxy that supports HTTPS tunneling, while NO_PROXY includes internal hostnames that should be reached directly. A proxy URL with the wrong scheme or port can create the mismatch.
For a controlled test on a Unix-like shell, temporarily remove proxy variables for one command:
env -u HTTP_PROXY -u HTTPS_PROXY -u ALL_PROXY curl -v https://host:443/Do not treat a bypass as the final fix if policy requires inspection. Give the proxy administrator the hostname, destination port, timestamp, and verbose trace so the tunnel rule can be corrected.
Intercepting desktop tools
Debugging tools that intercept HTTPS must install a trusted local CA and correctly tunnel or re-encrypt traffic. A Python issue report documented WRONG_VERSION_NUMBER when Fiddler intercepted SSL traffic. If the error appears only while such a tool is enabled, test with interception disabled, then repair its HTTPS configuration and trust chain rather than weakening application security.
Free tools Windows power users keep installed
One-click scans. No signup required.
Fixing Python Requests
Requests verifies SSL certificates for HTTPS requests, like a web browser. Keep that verification active while diagnosing the endpoint.
Use the correct URL and port
import requests
response = requests.get('https://example.com:443/timeout', timeout=15)
response.raise_for_status()Replace the path and timeout with values appropriate for the service. If this raises SSLError: WRONG_VERSION_NUMBER, test the same host and port with curl and OpenSSL. A matching failure outside Python points to the endpoint or proxy, not Requests’ certificate store.
Supply a private CA bundle when the service uses an internal CA
response = requests.get(
'https://internal.example/health',
verify='/path/to/ca-bundle.pem',
timeout=15,
)The CA bundle must contain the authority that signed the server certificate. This option addresses trust; it does not make an HTTP listener speak TLS.
Use a client certificate only when the server requires mutual TLS
response = requests.get(
'https://internal.example/health',
verify='/path/to/ca-bundle.pem',
cert=('/path/to/client-cert.pem', '/path/to/client-key.pem'),
timeout=15,
)Protect the client private key and confirm that the server’s policy actually requires mutual TLS. A client certificate cannot repair a wrong port or a proxy that is not tunneling.
Why verify=False is not a fix
Setting verify=False accepts untrusted certificates and permits man-in-the-middle attacks. It does not change the protocol spoken by the server, so it will not resolve a plaintext/TLS mismatch. If disabling verification appears to change the result, investigate the underlying trust-chain problem and restore verification immediately.
Separate protocol errors from certificate-trust errors
| Observed evidence | Likely layer | Correct action |
|---|---|---|
| HTTP status line or HTML appears before a TLS certificate | Endpoint port or proxy protocol | Use the TLS listener, enable TLS, or correct CONNECT tunneling. |
| No response, timeout, or connection refusal | DNS, routing, firewall, or service availability | Restore reachability before testing TLS. |
| Certificate is presented but hostname or issuer is rejected | Certificate identity or trust chain | Install the correct chain, use the correct hostname, or configure the intended CA bundle. |
| Handshake succeeds only with a specific TLS option | Protocol overlap | Upgrade or align supported TLS 1.2/1.3 settings; avoid obsolete versions. |
| Failure occurs only on one managed network | Proxy or interception | Correct proxy variables, bypass rules, or inspection policy. |
Choose the fix by the failing layer
| Suspected layer | Confirm with | Fix |
|---|---|---|
| Hostname or port | Direct curl and OpenSSL tests; first-byte inspection | Correct the URL, port mapping, load-balancer listener, or web-server binding. |
| Proxy | Verbose proxy trace; comparison with proxy variables removed | Use an HTTPS-capable CONNECT proxy, correct its port, or update NO_PROXY. |
| Server configuration | nginx -t, bound-port inspection, NGINX server block |
Add the TLS listener, correct certificate paths, permissions, and virtual-host selection. |
| Client protocol | Explicit TLS 1.2/1.3 OpenSSL tests and runtime versions | Upgrade or align supported protocol settings. |
| Certificate trust | Certificate appears before the error | Install the correct CA chain or supply a trusted CA bundle; do not disable verification. |
Practical recovery runbooks
Case: NGINX serves HTTP on port 443
- Run
curl -v https://host:443/and confirm that an HTTP response arrives before TLS. - Find the NGINX server block bound to 443 and change the listener to
listen 443 ssl;. - Set matching
server_name,ssl_certificate, andssl_certificate_keyvalues. - Run
nginx -t, reload NGINX, and repeat the OpenSSL SNI test.
Case: a corporate proxy causes the error
- Capture curl’s verbose output and identify the proxy address it selects.
- Check
HTTPS_PROXY,HTTP_PROXY, andNO_PROXYfor the failing process. - Run one controlled direct test with proxy variables removed.
- If direct access works, have the proxy owner enable correct CONNECT handling for the destination and install the organization’s CA only where policy requires it.
Case: Python fails but a browser works
- Run curl from the same host and user account as the Python job.
- Compare proxy environment variables and trust stores; browsers often use managed settings that a Python process does not inherit.
- Point Requests at the organization’s CA bundle with
verify='/path/to/ca-bundle.pem'if the endpoint uses a private CA. - Retest without
verify=False. If the exception remains a wrong-version error, return to the URL, port, and proxy checks.
Case: one virtual host fails while others work
- Use OpenSSL with
-servernamefor the failing hostname and a working hostname. - Compare the selected certificates and NGINX server blocks.
- Correct the failing
server_name, certificate chain, or default-server ordering, then reload and retest.
Security checks before declaring success
- Keep TLS certificate verification enabled in curl, Requests, and production clients.
- Do not permanently use
verify=False, ignore hostname checks, or re-enable obsolete SSL versions. - Keep private server and client keys readable only by the processes that need them.
- Test both the public hostname and the actual TLS port after every proxy, load-balancer, or NGINX change.
- Document which component terminates TLS and which protocol is used on each upstream hop.
- Retest from a second network when an interception device is suspected, but do not bypass organizational controls in production without authorization.
Once the endpoint returns a real TLS handshake, the remaining errors become much more specific: certificate identity, chain trust, client authentication, or application behavior. That separation prevents the common mistake of trying to solve a port or proxy mismatch by changing certificates.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
