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

−+×

RequestGET http://api.ipify.org?format=json

curl 'http://api.ipify.org?format=json' \
  --proxy 'http://{proxy_username}:{proxy_password}@{proxy_host}:{proxy_port}'

−+×

Response200 OK

{
  "ip": "203.0.113.42"
}

Replace placeholders in braces with your values. Responses use synthetic example data.

HTTPS target

−+×

RequestGET https://api.ipify.org?format=json

curl 'https://api.ipify.org?format=json' \
  --proxy 'http://{proxy_username}:{proxy_password}@{proxy_host}:{proxy_port}'

−+×

Response200 OK

{
  "ip": "203.0.113.42"
}

Replace placeholders in braces with your values. Responses use synthetic example data.

SOCKS5h

−+×

RequestGET https://api.ipify.org?format=json

curl 'https://api.ipify.org?format=json' \
  --proxy 'socks5h://{proxy_username}:{proxy_password}@{proxy_host}:{proxy_port}'

−+×

Response200 OK

{
  "ip": "203.0.113.42"
}

Replace placeholders in braces with your values. Responses use synthetic example data.

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.

Native handling and ports

The gateway accepts SOCKS5 natively rather than wrapping the client connection in HTTP. It can still bridge a client protocol to a compatible upstream protocol when the configured provider requires it. The selected provider must support any capability the route cannot translate, including SOCKS5 UDP behavior.

Deployments can expose separate HTTP and SOCKS5 ports or an auto-detect port that accepts both protocols. Use the host and port assigned during onboarding instead of assuming the examples are universal.

HTTP and SOCKS5 have similar gateway performance for ordinary TCP proxying. Protocol framing can add small differences, but the platform does not publish a separate performance guarantee by client protocol; benchmark the actual upstream mix and workload.

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 proxy errors and troubleshooting. For route selection and failures that remain client-side, see routing and failure behavior.