Technology · PRACTICAL GUIDE
curl error 35 “wrong version number”? Prove which hop spoke plaintext before changing TLS
The message often means a protocol mismatch, not an obsolete TLS version. Trace the proxy and origin hops, fix the exact contract, and keep verification enabled.
The message often means a protocol mismatch, not an obsolete TLS version. Trace the proxy and origin hops, fix the exact contract, and keep verification enabled.
The phrase can be misleading: protocol bytes were wrong for the handshake at one boundary; that does not prove the TLS version itself is obsolete.
1. Freeze the failing route
Save the exact curl command, URL, curl -V output, exit code and a redacted curl -v or --trace-time transcript before retrying. Record the shell and host because proxy variables and .curlrc are contextual.
List http_proxy, HTTPS_PROXY, ALL_PROXY and NO_PROXY without publishing credentials. A clean direct test with --noproxy "*" is valid only when policy and routing actually permit direct access.
2. Name every network hop
Write the route as client to proxy, proxy CONNECT, tunnel, then origin. An http:// proxy URL means plaintext to the proxy; an https:// proxy URL means TLS to the proxy first.
Also verify the target scheme and service port. HTTPS sent to a port serving plain HTTP can yield “wrong version number” even when both client and server support modern TLS.
3. Read the verbose boundary
In verbose output, locate the last successful socket connection and the first TLS record failure. Decide whether it happens before CONNECT, in the CONNECT response, or after a successful tunnel while greeting the origin.
A proxy banner, HTTP status line or readable plaintext where a ServerHello is expected is route evidence. Save it, but redact authorization headers, cookies and query secrets.
4. Correct one protocol contract
Fix only the proved mismatch: the proxy URL scheme, proxy port, target scheme, service listener or stale environment variable. Do not begin with -k or a forced TLS version.
If interception is expected, install and scope the approved trust chain after proving the route. If it is not expected, treat an unexpected proxy or certificate as a security and configuration incident.
5. Prove the repaired outcome
Repeat one verbose request through the intended path. Require the expected proxy/tunnel sequence, completed TLS, hostname verification, and a real HTTP status from the target.
Save the corrected command, redacted trace and configuration diff. Then test the original application or installer, because its environment may differ from the shell used for curl.
