curl's --preproxy option connects to a SOCKS proxy before reaching an HTTP or HTTPS proxy. It supports this particular chain rather than an arbitrary list of proxy servers.

The path is client → SOCKS endpoint → HTTP proxy → destination. Replace both documentation endpoints in this command:

curl --preproxy socks5h://203.0.113.10:1080 --proxy http://203.0.113.20:8080 --noproxy '' --connect-timeout 5 --max-time 20 --verbose https://example.com/

The SOCKS service must be able to reach the HTTP proxy's address and port. The HTTP proxy must then accept the destination request. For a hostname-based second proxy, the first SOCKS mode determines where that name is resolved; a numeric endpoint avoids that lookup.

Finding a failed hop

First confirm a request through each endpoint separately; for the HTTP hop, use a bounded HTTP-proxy test. If both work, the combined route can still fail because the first proxy cannot reach the second.

Read the verbose trace in connection order. A SOCKS failure while reaching the second proxy comes before the HTTP proxy's decision to accept or reject CONNECT to the website. Record which handshake failed.

When the extra hop helps

This arrangement can be useful when an authorized HTTP proxy is reachable through a SOCKS path. It also adds another service and network route that can fail or add delay. Chaining endpoints from a public proxy list provides no reliability or anonymity guarantee and still requires trust in the parties handling the connection.

--preproxy requires curl 7.52.0 or newer; other applications may not support the same arrangement.

Artihkkalat mat laktásit