WRONG_VERSION_NUMBER with a Proxy: Check HTTP vs. HTTPS

The error says “wrong version,” so it is tempting to start switching TLS versions. With a proxy, check an earlier possibility: did the client send a TLS handshake to a port that was waiting for plain HTTP?

A destination such as https://example.com/ and a proxy such as http://proxy.example:8080 are an ordinary pair. Changing the second URL to HTTPS tells the client to encrypt its conversation with the proxy itself. It is not an instruction to allow HTTPS websites.

Locate the first TLS conversation

For an HTTP proxy, the client can first send CONNECT and receive an HTTP reply. Only then does it start destination TLS inside the tunnel. For an HTTPS proxy, a separate TLS connection to the proxy comes first.

A TLS parser receiving an HTTP error page or other plaintext can report a protocol error. The wording does not establish which TLS versions the website supports, or even that the website was contacted.

1. Record the proxy URL, including its scheme, and the endpoint's documented protocol.
2. Find whether the failure happened before a CONNECT reply, during destination TLS, or while verifying the proxy's own certificate.
3. Check the actual client and dependency versions when comparing an old workaround. Earlier proxy implementations sometimes treated a scheme differently.

Several fixes can be wrong for different reasons. The HTTP proxy list offers ordinary HTTP endpoint candidates for public requests permitted through such a route. A plain HTTP endpoint needs the HTTP proxy scheme; a genuinely TLS-enabled endpoint should retain HTTPS and its certificate verification. A proxy rejecting CONNECT needs a supported service or policy, not an arbitrary library downgrade.

Keep the first observable failure. Disabling certificate verification cannot make an HTTP-only listener speak TLS, and selecting an old cipher policy cannot explain an HTTP rejection sent before the website handshake.