How to Use cURL With HTTP and SOCKS5 Proxies

cURL supports HTTP and SOCKS proxies, so it is a useful way to test one connection path at a time. Use the host, port, protocol and authentication method supplied for your current Proxy302 endpoint. The commands below use placeholders and an IP-check destination; they are examples to verify configuration, not measurements of speed, success rate or anonymity.

Check the route before sending a real workload

First record the endpoint details and make a direct request for comparison. If your shell has proxy environment variables, use cURL's no-proxy option for this direct check:

curl --noproxy '*' 'https://api.ipify.org?format=json'

Then make one request through the supported proxy type. A different IP reported by the test service shows the exit used for that request. It does not prove that every application or later request uses the same route.

Use an HTTP proxy

curl --proxy http://PROXY_HOST:PROXY_PORT \
  --proxy-user USER:PASS \
  'https://api.ipify.org?format=json'

The --proxy option names the proxy. The --proxy-user option supplies proxy credentials, which are different from a destination website's login. For an HTTPS destination, cURL normally asks an HTTP proxy to establish a CONNECT tunnel. The endpoint must allow that request.

Use SOCKS5 and choose where DNS is resolved

curl --proxy socks5h://PROXY_HOST:PROXY_PORT \
  --proxy-user USER:PASS \
  'https://api.ipify.org?format=json'

With socks5://, cURL resolves the destination hostname locally. With socks5h://, cURL sends the hostname to the SOCKS5 proxy for resolution. Pick the behavior your task requires and verify it in the actual environment. The server and client still need to support the selected authentication method; a SOCKS5 label alone does not guarantee UDP support or any specific IP session duration.

Keep credentials out of shared output

Only use placeholder values when copying documentation. A real password typed as a command argument can remain in shell history or be visible to local process inspection; a proxy URL containing USER:PASS@HOST creates similar exposure. Use your organization's approved secret-handling method for repeatable automation. Redact Proxy-Authorization headers, passwords, session identifiers and full endpoint URLs before sharing verbose logs.

Read the first error correctly

Observed result	What to inspect first
Cannot connect to PROXY_HOST:PROXY_PORT	Check host, port, selected protocol and network reachability.
HTTP 407 from the proxy	Check proxy credentials and the endpoint's supported authentication method.
SOCKS5 handshake or authentication failure	Check SOCKS5 endpoint support, chosen client option and credentials; it is not necessarily an HTTP 407.
Destination returns 401 or 403 after the proxy connects	Investigate the destination's own authentication or access policy. A new proxy password does not automatically resolve it.
The test succeeds but shows the direct IP	Check --noproxy, bypass environment variables and whether the requested URL actually used the chosen proxy.

When reporting a failure, include a redacted command, cURL version, protocol, timestamp and response class. See the Proxy302 connection troubleshooting document.

Frequently asked questions

Should I use socks5:// or socks5h://?

Use socks5:// when local hostname resolution is intended. Use socks5h:// when the hostname should be resolved by the SOCKS5 proxy. Test the result against your actual destination and network policy.

Does cURL through a proxy automatically encrypt data?

No. The proxy protocol and the destination's HTTPS/TLS connection solve different problems. Check the transport of the client-to-proxy leg separately if it matters to your security requirements.

Do these examples show Proxy302's current hostname or price?

No. Endpoint properties and billing terms can change by product. Copy the current values from your account and confirm them before running a production task.

References: cURL command-line manual and MDN's 407 reference.