HTTP, HTTPS, and SOCKS5 protocols

The gateway protocol controls how the client connects to ProxyRequest. It does not have to match the destination URL scheme.

Protocol decision table

Client capability	Use	DNS behavior
HTTP proxy support	http:// proxy URL	Client and proxy behavior depend on the request type
HTTPS destination through HTTP proxy	http:// proxy URL + CONNECT	Tunnel carries the encrypted destination connection
SOCKS with local DNS	socks5://	Client commonly resolves the hostname locally
SOCKS with proxy-side DNS	socks5h://	Hostname is sent through the proxy path

HTTP target

curl --proxy \
  http://USERNAME:[email protected]:8000 \
  http://example.com/

HTTPS target

curl --proxy \
  http://USERNAME:[email protected]:8000 \
  https://example.com/

SOCKS5h

curl --proxy \
  socks5h://USERNAME:[email protected]:1080 \
  https://example.com/

HTTPS through an HTTP proxy

For an HTTPS destination, the client normally sends CONNECT destination:443 to the HTTP proxy. The proxy establishes the route, then the client performs TLS directly through the tunnel. Do not change the proxy scheme to https:// unless the assigned gateway explicitly supports TLS on the proxy connection itself.

Use SOCKS5h to avoid local DNS leakage

When the tool supports it, socks5h:// makes the DNS-routing intent explicit. Confirm the client library actually recognizes the h variant.

Troubleshooting by layer

1. TCP layer: verify gateway host, port, egress firewall, and DNS resolution.
2. Proxy layer: verify protocol, username, password, and active order.
3. Targeting layer: remove optional constraints to test inventory availability.
4. Destination layer: compare multiple targets and inspect the verbose client trace.
5. Application layer: confirm the library is using the proxy for every redirect and subrequest.

For a consolidated diagnostic checklist, see common errors.