Diagnose an HTTPS CONNECT proxy failure

Identify the failed stage

Start with the client’s sanitized error description and the destination scheme. An HTTP proxy carrying HTTPS still uses http://IP:PORT as its proxy URI. Changing it to https:// asks for an encrypted proxy endpoint, which is a separate capability.

Dropstride supports destination ports 80 and 443 and blocks private networks and cloud metadata. An unsupported destination can be refused before a tunnel exists.

Compare one small, permitted public request

Run a bounded request to a simple public HTTPS page, then compare the failing destination. If one succeeds, that demonstrates a working path for that request only. Avoid using repeated attempts to force a denied destination.

Do not turn off TLS verification or install an unfamiliar certificate to silence an error. Destination TLS is designed to verify whom your client is communicating with.

Run the curl HTTPS diagnostic →

Two different 403 results in our fixture

The local test proxy refused CONNECT to a synthetic blocked hostname. curl exited with code 56, and the origin saw zero requests. In a separate case, the proxy established the tunnel and the test origin returned 403; curl reported destination status 403.

The downloadable curl setup example also uses --fail-with-body, which makes destination error responses fail the command. Compare the reported HTTP status and stage instead of relying on an exit code alone.

Read the controlled CONNECT test results →

Give support the stage, not your secrets

Record the exact destination hostname, whether a simple public test worked, the timestamp and timezone, client version, order number, and sanitized status message.

Redact Proxy-Authorization, Authorization, proxy URLs containing credentials, cookies and account identifiers. No retailer compatibility claim follows from a successful local or generic connectivity test.