An HTTPS service on port 8443 can be reached through an HTTP proxy on port 8080. Those numbers describe different connections:

$handle = curl_init('https://api.example:8443/status');
curl_setopt($handle, CURLOPT_PROXY, 'http://proxy.example:8080');
curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);

The application still owns execution, error handling and the handle’s lifecycle. The snippet keeps the routing inputs together without changing certificate verification.

cURL first connects to proxy.example:8080. For this HTTPS destination, the tunnel request names api.example:8443, and the TLS identity remains api.example.

CURLOPT_PORT is a destination-port override, not the proxy’s port. Setting it to 443 whenever a URL begins with https can override a service deliberately hosted on 8443. libcurl recommends selecting the port in the URL rather than using that option.

When reusing a handle, account for any earlier explicit port override too. A new URL does not make contradictory retained options easier to interpret.

The intermediary must permit CONNECT to the selected destination port. A refusal for 8443 is not a reason to move the proxy listener or disable TLS validation.

Erthyglow kevrennek